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 ...?
hi julien. i think what you want to be implementing is view-frustum culling.
http://www.lighthouse3d.com/tutorials/view-frustum-culling/
not sure if that's already what you are trying or not.
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 ..
because you shouldn't decide whether or not to draw an object based on distance from the camera, you should decide based on whether or not cameras viewing frustum intersects with some simple bounding shape that encloses your object.
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 ..?
(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 ?
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.
Hi Julien,
I know it's been i while, but could you be persuaded to post the calculation system using gen and genexpr. Right now, I'm calculating distance with the pythogoerean theorem;
d = √((x2-x1)^2+(y2-y1)^2+(z2-z1)^2)
In my patch I'm doing the following for every object;
expr sqrt(pow($f1-$f2 , 2) + pow($f3-$f4, 2) + pow($f5 -$f6, 2))
I would love to see how you did it!
/Lasse