A word about rendering

Engines, Libraries and Tools Xith3D Forums
#1

When I implemented glScissors into the rendering process I got a deeper look into the rendering code. Does anyone know what these RenderBins are actually good for? To me they seem to me just performance killers. The only purpose they seem to fulfill is this strange sorting. I cannot see what this is good for, but causing the transparency problems we encountered in HUD development. I don’t think the nodes will have to be sorted in any way. They just have to be rendered as the scenegraph defines it.

We could easily waste the RenderBins and get a much faster and more slim rendering code. Well, at least if nobody points out an importance of them. I could do this change.

Marvin

#2

Arn’t the RenderBins what’s used for OpenGL state sorting?

(from Xith’s own site: http://www.xith.org/articles/render_pipeline_explanation.html)

Kev

#3

What is OpenGL state sorting?

#4

OpenGL doesn’t like changing state (state being one of things that you enable in OpenGL, e.g. transparency, lighting) - everytime the state if changed there’s a potential for the implementation to have to do a bunch of work. So, for optimum performance you have all objects with a similar state sorted into buckets/bins/caches/lists (names vary quite alot) to be rendered together and hence minise OpenGL state changes and the assocaited performance impact. This is one of the reasons you’d want to use a rendering engine like Xith at all, it provides the state sorting for free by allowing you to defined the scene in non-immediate mode (other than the spatial checking/culling provided by the scenegraph bounds work).

More details from the wonderful folks here:

http://opengl.j3d.org/tutorials/statesorting.html

Kev

#5

State changes (e.g. switching to another texture, polygon mode, shader etc.) are expensive, so you want to minimize them as much as possible. The RenderBins sort the scene graph depending on the state changes required to draw the different Nodes.

Loosing the RenderBins will most probably lead to worse instead of better performance…

#6

Ah, now I see it. Thanks for the lesson :wink:

#7

Qudus, we seems to have much in common : we have time, motivation, but our knowledge sometimes lag behind. I would suggest us to read through the entire Xith3D code and to find doc for each GL function used so our Xith3D knowledge would be greatly improved. I/you already know some parts very well but the rendering layer is still dark.

Really that’s a thing to do.

#8

[quote="<MagicSpark.org [ BlueSky ]>,post:7,topic:28332"]
Qudus, we seems to have much in common : we have time, motivation, but our knowledge sometimes lag behind. I would suggest us to read through the entire Xith3D code and to find doc for each GL function used so our Xith3D knowledge would be greatly improved. I/you already know some parts very well but the rendering layer is still dark.

Really that’s a thing to do.
[/quote]
Totally agreed. :slight_smile:

When I’ll work on point (#5) on dev-plan-1, I’ll anyway have to look deeper into the rendering thing.