weird behaviour of layer / depth_enable / jit.gl.picking
Feb 02 2016 | 4:20 pm
Hi,
I noticed the following strange (and annoying) behaviour for jit.gl.picking, when using it without depth_enable but using layers.
The first thing is that display order of overlapping shapes located at same z-distance gets reversed when switching from @depth_enable 0 to 1.
Then jit.gl.picking behaves fine with @depth_enable 1, but do not match shapes' boundaries anymore when using @depth_enable 0,
which basically makes it unusable.
It is not so easy to explain with words, but I guess the patcher below makes the issue more explicit.
FWIW, it is happening here with Max7.0.6 on macbook pro early 2011, OSX 10.10.5 retina.
Maybe I missed something here... if anyone has a solution or explanation for this (seemingly buggy) behaviour, I'm interested to know!
I can see a workaround using @depth_enable and @ortho 1 on jit.gl.render but I still hope for something less ugly...
- Feb 02 2016 | 7:25 pmhi vincent. thanks for the patch. jit.gl.picker requires depth_enable for proper functioning. i've logged a feature request to support picking without depth.
- Feb 02 2016 | 8:47 pmhi Rob,thanks for the clear answer. :) It would be good to be able to keep consistency through layer indeed.While talking about this, here is another patch which may boil down to the same issue, when using [depth_enable 1] + [automatic 0]. Picking is then inconsistent with the actual display, as shown in the patcher below.Do you see any workaround to this issue without having to add small z-axis offsets to all the (many) objects of my scene ?
- Feb 03 2016 | 12:22 amApart from the picking, it seems to me that the reversed display order happening when enabling depth_mode is just what prevents users from using blending when objects are at exact same position. If one shifts a little bit the plane that gets behind when switching to mode [depth_enable 1], it magically gets it transparency. Is it something hardcoded in OpenGL or could this change in a future release ?
