Forums > Jitter

jit.gl.picker + jit.gl.node


Vincent Goudard
June 3, 2013 | 6:49 am

Hi,

I have been trying to use both jit.gl.picker and jit.gl.node, to be able to pick objects rendered in various subcontext, but I failed to do so.

Is it inherently impossible to get this or is there a way to do it that I missed ?

Right now, I think i am doomed to render all my layers in a same unique context to be able to achieve this… and this gets me sooooo sick.

thanks in advance for any hint !

 

 
<code>

– Pasted Max Patch, click to expand. –

</code>


Rob Ramirez
June 3, 2013 | 11:13 am

hi vincent.
thanks for the clear example patch.
i’ve captured this as a feature request, and we’ll see what we can do to improve this for a future version.


Vincent Goudard
June 3, 2013 | 1:08 pm

This would be utterly great.

I am in the process of making classic GUI element (buttons, sliders, etc) for a wide audience application, and being able to process the GUI elements at the same level as the rest of the graphics is a a real enhancement of the application. I first thought using the native max buttons, pict slider, etc… and customizing them but the limits of this solution come soon. Especially : the jit.window always gets on foreground when the jit.gl.render is active. There are many other arguments to using jitter’s OpenGL as the application GUI, but this exeeds this post’s topic.

Anyway, I was just trying to get you implement this feature in *the* next release… :)

best

 


Rob Ramirez
June 19, 2013 | 12:35 pm

this should be working as of 6.1.3.
please give it a look.


Vincent Goudard
June 20, 2013 | 1:32 am

Hi Rob,

thanks for the fix.
However, I think it is not working the way it should… or there is something I do not understand.

I cleaned the patch (see below), put names and colors to make the point clearer. Here, I get both sub-node pickers returning only the torus named "t1". And the picker attached to the main node does not returns any videoplane (plane1 and plane2).

Can you confirm the wrong behaviour ?

System info :
{
"version" : "Version 6.1.3 (c65b953)",
"platform" : "mac",
"arch" : "x86",
"osversion" : "Mac OS X Version 10.7.4 x86_64",
"samplerate" : 44100,
"iovs" : 256,
"sigvs" : 256,
"scheduler_in_audio_interrupt" : "off",
"audio_drivername" : "Core Audio",
"audio_driver_subname" : "",
"eventinterval" : 2,
"overdrive" : "off",
"mixerparallel" : "on",
"mixercrossfade" : 0,
"mixerlatency" : 30.0,
"mixerramptime" : 10.0
}

<code>

– Pasted Max Patch, click to expand. –

</code>


Vincent Goudard
June 24, 2013 | 2:19 pm

… isnt’it ?


Rob Ramirez
June 25, 2013 | 11:36 am

sorry, i missed your reply.
your patch has a few typos, but fixing those are still not going to give you what you want.
you are not going to be able use jit.gl.picker in this way (capturing to a texture, and then picking objects on that texture). the gl.picker is picking the actual geometry, not the image on the texture.

additionally, jit.gl.picker uses bounding-boxes to do it’s picking. so you will be unable to pick a sphere inside of a torus, because the bounding box of the torus encloses the sphere.

if you want more accurate, mesh-based picking, you will have to set up a collisions only physics context (jit.phys.world @dynamics 0) and create a jit.phys.body for each of your shapes, and use jit.phys.picker to do the picking.

however, this will still not help the issue of picking on a capture-to-texture.

Viewing 7 posts - 1 through 7 (of 7 total)