calculate relative position of object from jit.gl.camera perspective

fraction's icon

Hi , happy new year to everyone!

hope Rob or someone else would have time to help me here.

I can't solve a problem and probably don't approach it from the right angle.

I have some basic mesh rendering in jit.gl.node. Then i have a camera in that node.

I would like to get the position of the objects in the camera's reference frame/axis. I use anim.drive+anime.node to move and rotate camera, and i 'd like to be able to retrieve position as i move the camera.

I followed a first lead by calculating the position with vexpr, but if that's ok for xyz, i can't manage to retrieve values when camera is rotating. I don't know how to manage this (maybe with quat?), and maybe there's a right way to do it with a better anim.node hierarchy?

Here's a basic patch

Max Patch
Copy patch and select New From Clipboard in Max.

Thanks a lot in advance for the help!
-e

fraction's icon

Kinda go around
if i skip the camera (so it's fixed), and directly connect the anim.node to the top level jit.gl.node. It seems tricky. So the whole context is moving instead of the camera.
Was it that easy?

Max Patch
Copy patch and select New From Clipboard in Max.

Well, no it s not. Rotatexyz from anim.node makes only the context to rotate. It's not like when rotating camera on it's axis.

Anyone?

fraction's icon

Update with a jit.gen found on the forum.

Max Patch
Copy patch and select New From Clipboard in Max.


Still would there be another solution maybe more straight fwd to retrieve an object position from a camera perspective? I m not sure if it's the most efficient way

Pedro Santos's icon

Is it just for a single object? I did it for multiple coordinates/points in another thread.
Here's a revised and simplified solution for a single object, with the same jit.gen code:

Max Patch
Copy patch and select New From Clipboard in Max.

fraction's icon

hi pedro,
thx yes!
i m surprised there's not another solution than recalculate the position itself, since jitter has already calculated the position to display in the context.
For the same reason we have "getworldposition" for a gl object, i was wondering if we could have a "getcameraposition" attribute for an object. I know the attribute doesn't exist, but if the value exists already, it's not efficient to calculate it a second time, is it?

Mathieu Chamagne's icon

Hey

Here is a solution with jit.anim.node using worldtolocal message :

Max Patch
Copy patch and select New From Clipboard in Max.

note that jit.anim.node needs to be banged to update its output when rotatexyz changes...

I hope this helps

Mathieu

fraction's icon

thx you mathieu. I never used the worldtolocal message so far!
It's a different approach, because in your case the camera is fixed and instead objects are moved around, which can also work. I will investigate which one makes the more sens to use in my project.
Your solution is actually the one i was kinda looking for as it's using the data already calculated by jitter objects. So might be more efficient at the end.

in my case, your solution implementation :

Max Patch
Copy patch and select New From Clipboard in Max.

I would be curious to Rob's advice/opinion as well,
thx!

Mathieu Chamagne's icon

In the patch I posted above, you can freely move and rotate the camera, the position of the object is relative the the anim.node which has same position & rotatexyz than camera.

here is another version using several anim.node that clarities hierarchical transformation :

Max Patch
Copy patch and select New From Clipboard in Max.

fraction's icon

my patch above wasn't really working out.
Here is a new version, using the camera position

Max Patch
Copy patch and select New From Clipboard in Max.

Would u guys confirm that this worldtolocal value corresponds well to the object position relatively to the camera perspective?

thx!

fraction's icon

@mathieu ! ha sorry didnt see you posted something as well. Yeah sounds like that for me as well :)

thx!!

Mathieu Chamagne's icon

Would u guys confirm that this worldtolocal value corresponds well to the object position relatively to the camera perspective?

sounds good to me :-)