fraction

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?

comment

vexpr

route

jit.gl.gridshape

jit.anim.drive

jit.gl.node

print

message

jit.anim.node

jit.gl.camera

flonum

toggle

jit.world

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? 

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 app

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

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.

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.

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?

Update with a jit.gen found on the forum.

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

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:

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:


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?

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?


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

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

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

I hope this helps

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 :

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

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 :


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

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 :

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.

my patch above wasn't really working out. 

Here is a new version, using the camera position

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

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

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

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

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