weird behaviour of layer / depth_enable / jit.gl.picking

Vincent Goudard's icon

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.

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

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...

Rob Ramirez's icon

hi 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.

Vincent Goudard's icon

hi 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.

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

Do you see any workaround to this issue without having to add small z-axis offsets to all the (many) objects of my scene ?

Vincent Goudard's icon

Apart 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 ?