## Efficient distance calculation between the cam and a very long OB3D element ?

Jun 12, 2012 at 4:34pm

# Efficient distance calculation between the cam and a very long OB3D element ?

Hi there,
I have now my distance calculation system made using jit.gen & genexpr.
I have a global matrix which contains ALL my center points position of all my spherical objects.

BUT, I’ll have some more cylindrical/line-like objects.

I’d probably need to split my matrix into 2 different matrix to fire the calculation differently :-/
Afraid of decrease of performances, but I have to try.

How would you calculate the azimut/elevation/distance of a point on a line relatively to my cam (another point) ?

It is “like” measuring a distance (and azimut/elevation) between two moving point:
- the cam itself
- a moving point corresponding to the projection of the cam on the line.

Anyone would wizard me here …?

#46643
Jun 12, 2012 at 5:24pm

I'm ashamed, but I don't see the relation between my question and the concept frustum-culling.
digging that.

I probably wasn't precise enough.

Basically I need to calculate AED of the black point relatively to the white one.
Just wanted to know if there was something native in Max, and if I had to dig quaternions instead of x,y,z or aed ..

[attachment=196430,4029]

###### Attachments:
#167793
Jun 12, 2012 at 6:47pm

I got it.
I absolutely cannot imagine (at least, right now) how to do that with jitter/matrices considering my implementation.
I understand that following that way, I would ONLY process object visible by the camera view.
Did I understand correctly ?

Anyway, I’d need distance, azimut & elevation for sound purpose.
And indeed, the projection point & the AED relatively to cam are the need (at least) for sound stuff.
Would you bring me some tricky formulas ..?

#167795
Jun 12, 2012 at 7:18pm

(before to calculate distance for sound purpose, I’m trying currently to implement that frustum things because I think it answers to my first essential question at the beginning of my project: how to only send to the opengl pipeline object that worth to ?)

probably, I should do all my calculation (that view-frustum culling, the AED stuff for all my sounds source) in one pass (I mean in one jit.gen)

So.
I need all my object positions (and eventually diameter) …. got it.
I need my cam parameters (position + orientation) …. got it.
And I’ll push the result into a pretty jitter matrix with 4 planes like: state, azimut, elevation, distance
Each frame, each object extract its state and react according to that (activate or inactivate itself)

does it make sense ?

#167796
Jun 17, 2012 at 9:47am

Trying to group the whole stuff I put a bit here and there on the forum about my view rendering here in that thread (total apologize to have disturbed some people here. it wasn’t absolutely my intentions :-/ )

so
finally, and of course, view frustum culling does make sense (I wouldn’t have expected bad advices from Robert… for sure =)
but I’m not sure about benefits in my case.

my case isn’t a very unusual one but if I am almost okay with the implementation (still not but soon), I’m doubtful about “what can I do ?” with the list of object position relatively to the view.

Indeed, I read around this topic.
The list of object and their state is almost every time used to activate/inactivate objects which are not in the volume between the 6 planes of the frustum.

The whole calculation has a cost. And even if I don’t totally appreciate it, I guess there is a benefit IF you use that list to effectively inactivate ALL object outside of that part.
ils
BUT what if you have a very big distance between near & far clip planes ? My idea would be to have a great distance in order to be able to show object in far background.
what if you want to make glowing objects ? In that case, those objects, even if they aren’t directly visible, SHOULD influence the global light, diffusing nice effect.

Considering those 2 remarks, this would mean:
- I’d have a HUGE view volume
- I’d probably open a bit more the view angle in order to inactivate only objects … saying … behind the cam (not on the side for instance)

Would I have benefits considering that ?
any opinions would be very appreciate.

#167797

You must be logged in to reply to this topic.