What is the exact drawing order of scene nodes. Lets say I have a root node that has five children, will it be drawn like this
root,child1,child2,child3,child4,child5 or
root,child5,child4,child3,child2,child1 or
child1,child2,child3,child4,child5, root
or
child5,child4,child3,child2,child1, root
and what happens when you switch on transparency. I noticed the drawing order seems to suddenly change (probably because of some transparency sorting) when you enable all transparency even though all the nodes are fully opaque.
Drawing order of scene nodes?
The addChild(..) method always appends the child to the components child list. For rendering (and all other things that traverse the scene graph) the following Depth-first search is done:
1. Render the geometry of the current component (before, transformation and appearance are handled).
2. Visit all child components, as they are in the child-list.
In the case of your flat graph, I assume it will be: root, child1, child2, child3, ... When child1 has also children, child1.1, child1.2 then they will be rendered between child1 and child2: root, child1, child1.1, child1.2, child2, child3, ...
The strange behavior with transparency comes from _no sorting_. Usually (transparency not enabled), we use the z-Buffer, that means that for each pixel, the distance to the camera of the closest geometry already rendered is stored. Geometry that is further away will be ignored then. Since we do no transparency sorting, we turn off z-buffer and render all layers, but this results in wrong images when the different layers are rendered in wrong order. For fully opaque geometry it is completely wrong, for very transparent geometry it is almost correct.
Using reflectionmaps and transparency values close to 1 improves images.
1. Render the geometry of the current component (before, transformation and appearance are handled).
2. Visit all child components, as they are in the child-list.
In the case of your flat graph, I assume it will be: root, child1, child2, child3, ... When child1 has also children, child1.1, child1.2 then they will be rendered between child1 and child2: root, child1, child1.1, child1.2, child2, child3, ...
The strange behavior with transparency comes from _no sorting_. Usually (transparency not enabled), we use the z-Buffer, that means that for each pixel, the distance to the camera of the closest geometry already rendered is stored. Geometry that is further away will be ignored then. Since we do no transparency sorting, we turn off z-buffer and render all layers, but this results in wrong images when the different layers are rendered in wrong order. For fully opaque geometry it is completely wrong, for very transparent geometry it is almost correct.
Using reflectionmaps and transparency values close to 1 improves images.
Thanks steffen that helps a lot in understanding what is going on
Thanks!
Yep I noticed that but that's okay since now I know the drawing order I can correct it manually to ensure always the right order.sorting, we turn off z-buffer and render all layers, but this results in wrong images when the different layers are rendered in wrong order. For fully
opaque geometry it is completely wrong, for very transparent geometry it is almost correct.
Thanks!
Just to reiterate, for best results using transparency in the JOGL backend:
1. Put all transparent objects at the end of the list of children of the root SceneGraphComponent.
2. Only enable transparency for the nodes which have transparency.
Here's a couple of other points which belong in the yet-unwritten transparency tutorial:
1. Use CommonAttributes.OPAQUE_TUBES_AND_SPHERES to force points and lines (when drawn as spheres and tubes, resp) to be drawn opaque. This can improve the readability of the transparency of a surface dramatically.
2 If transparency is enabled, the default behavior is that the z-buffer is disabled. You can force the z-buffer to be enabled by using CommonAttributes.Z_BUFFER_ENABLED to true. This can in certain special situations help to obtain better results. (When transparency is not enabled this attribute has no effect).
3. Finally, there is a kind of transparency you can get which doesn't require that you enable transparency at all. It uses textures, and takes advantage of the OpenGL feature GL_ALPHA_TEST. This has the effect that those fragments in the OpenGL pipeline whose alpha value are less than or equal to a given value, are rejected. For the JOGL backend, that's right now fixed to be zero.
For a picture showing the result of using such a texture see this tutorial page. You can disable this feature by setting CommonAttribute.IGNORE_ALPHA0 to false.
You can also use this features without textures, by setting the transparency value to 1.0. But then of course the whole object disappears. It can be useful to have "hidden" objects in the scene since they will still be picked, etc.
(All the above attributes also have corresponding methods in the RenderingHintsShader interface, in case you use shader interfaces instead of Appearance attributes directly.)
1. Put all transparent objects at the end of the list of children of the root SceneGraphComponent.
2. Only enable transparency for the nodes which have transparency.
Here's a couple of other points which belong in the yet-unwritten transparency tutorial:
1. Use CommonAttributes.OPAQUE_TUBES_AND_SPHERES to force points and lines (when drawn as spheres and tubes, resp) to be drawn opaque. This can improve the readability of the transparency of a surface dramatically.
2 If transparency is enabled, the default behavior is that the z-buffer is disabled. You can force the z-buffer to be enabled by using CommonAttributes.Z_BUFFER_ENABLED to true. This can in certain special situations help to obtain better results. (When transparency is not enabled this attribute has no effect).
3. Finally, there is a kind of transparency you can get which doesn't require that you enable transparency at all. It uses textures, and takes advantage of the OpenGL feature GL_ALPHA_TEST. This has the effect that those fragments in the OpenGL pipeline whose alpha value are less than or equal to a given value, are rejected. For the JOGL backend, that's right now fixed to be zero.
For a picture showing the result of using such a texture see this tutorial page. You can disable this feature by setting CommonAttribute.IGNORE_ALPHA0 to false.
You can also use this features without textures, by setting the transparency value to 1.0. But then of course the whole object disappears. It can be useful to have "hidden" objects in the scene since they will still be picked, etc.
(All the above attributes also have corresponding methods in the RenderingHintsShader interface, in case you use shader interfaces instead of Appearance attributes directly.)
jReality core developer