Hello all,
I have a very strange problem in rendering order. I have several textured polygons in render orders from 11-35 and a big textured polygon on top with a higher number gemhead, but for some reason it doesn't show on top. I have tried it in a big fat patch (where it fails) and in a simple patch where it succeeds. I also tried in the big fat patch, having everything with positive numbers and the one i want on top with negative rendering numbers, but still doesn't work.
What could be causing this?:
I suspect one possibility is that I am using many abstractions and/or subpatches, could this corrupt somehow the rendering order?
I have tried this in:
- quadcore machine running Windows XP - Pd Extended 0.39.3 - GeForce 8600GT
- powerbook G4 OSX, GEM 0.91 from cvs
best,
J
Jaime Oliver wrote:
Hello all,
I have a very strange problem in rendering order. I have several textured polygons in render orders from 11-35 and a big textured polygon on top with a higher number gemhead, but for some reason it doesn't show on top. I have tried it in a big fat patch (where it fails) and in a simple patch where it succeeds. I also tried in the big fat patch, having everything with positive numbers and the one i want on top with negative rendering numbers, but still doesn't work.
What could be causing this?:
luckily rendering later does not guarantee that things are drawn on top of others. imagine a cube and behind (that is: hidden by) the cube there is a teapot. if drawing the teapot later would always draw it on top of the cube, it would be significantly more complicated (than it is now) to make more complex 3D-scenes. just think models that mutually occlude parts of each other....
the way this is solved in openGL is to use depth maps. whenever a fragment is drawn, it's depth value (position at the Z-axis) is stored in a separate buffer. when a new fragment is to be drawn it is first checked, whether there is already a fragment drawn at the same x/y position that is closer to the camera (and thus should occlude the newly generated fragment). if so, the new fragment is discarded.
since your "top polygon" is obviously *not* in front of the other polygons, it will be occluded by them so you don't see it. (if they are actually at the same depth, you might get weird artefacts).
this is probably crucial information if you want to mess with render-order.
anyhow, there are 2 solutions for your problem:
- just make sure that the "top polygon" is in front of all the rest
(e.g. using [translateXYZ]) this might work ok for flat shapes without penetration. 2. disable the depth-test before drawing your polygon. this can be done with the [depth] object (which _disables_ depth-test by default)
which solution is preferrably depends on the situation. if you want to make sure something is rendered to the screen (like an on-screen-display), the 2nd solution is the one to go.
fgkasdr IOhannes
-
IOhannes m zmoelnig -
Jaime Oliver