0.8 rendering changes proposal

[Kulik]

Currently, CEGUI renders via GeometryBuffer and only supports quads.

GB holds translation, rotation, clipping and list of textures that are used when rendering. This is IMO the biggest problem of it. One geometry buffer can mean many many batches because it has numerous texture changes. You also can only change the texture, no other state settings. And to top it all, it's actually harder to implement renderers with this approach.

What I propose is to split this into 2 classes - RenderBatch (one batch only) and RenderState (holds state settings). RenderBatch knows which RenderState it wants to use. I am not sure about the names yet because RenderState could (for example) render the batch multipass and that doesn't play well with the name, I would appreciate ideas in this area. With this approach, we can easily get a hash of each of the state settings and if it's the same between 2 batches, we don't have to set it. Furthermore it gets easier to implement some sort of batching/merging in the future (this is not the point of this though).

RenderState will only support primitive type (triangles, quads, lines, perhaps points), translation, rotation (or matrix4x4 to be more generic?), clipping rect and at least one texture by default - this is what all render systems have to support. The RenderState classes will get created by the Renderer itself so they can be subclasses into something like OpenGLRenderState, OgreRenderState, etc... They will be PropertySets so you can define them via XML. And this is where all the power and fun lies in this. Ogre can for example add "VertexShader" as a property and you can put a shader source there. This is all very complicated, so it will need several iterations before the API is just right. Right now I don't feel that RenderState should allow multiple passes, I think there should be a class surrounding that all but there are concerns about CEGUI becoming a rendering engine and that certainly is something to avoid.

In the end will allow RenderEffects to be defined via XML.

If there is some interest in this, I will branch out and try to hack something together. Widgets will of course be able to queue more than one batch in their render method, so no rendering power is lost but a lot of it is gained.

Idea that incorporates rendering too much into CEGUI (I don't like this) - CEGUI::RenderMethod, inside it are CEGUI::RenderPass. CEGUI::RenderBatch has RenderMethod set in it. This is pretty realtime 3D centric and allows a lot of stuff and could even obsolete current RenderEffects.

Things that this will enable: vector graphics drawing (with triangles), making effects more convenient and possibly even portable across renderers, future rendering optimisations - batching.

feedback please..

[Mikademus]

The separation of state and batches brings on further possibility I'd like to suggest: delta state stacks. Usually, most state sets only twiddle a few parameters from the last set, and it would be very beneficial that the state stack handles this so only the changed settings need to be updated.

[uelkfr]

And maybe make choice to refuse to support fixed function pipeline and move towards unified shader model!?
But its too early because Mesa supports only OpenGL 2.1

[*]OpenGL12Renderer[/*]
[*]OpenGL41Renderer[/*]
consider this please too

[Kulik]

uelkfr: By all means, anyone is free and encouraged to make a patch to support GL3/4 rendering but it probably won't be me (I could review it and commit if it turns up though ). You can do this with CEGUI 0.7 the same way DX10/11 renderer is done.

[Mikademus]

Tying in with what you said here, is this the time to reintroduce the idea of 3D coordinates everywhere? If that means we can have arbitrarily rotated windows, and widgets mapped to arbitrary geometry, then it should be done. Also, the 3rd coordinate can just be hidden from sight for all but the calls where it is of relevance.

[Kulik]

By nobody liked that I meant CrazyEddie didn't like it, he actually removed all the Z coordinates everywhere a while back.

Lets start a rebellion group! We want 3D in CEGUI

[Mikademus]

Of course we do! Say we want to make some kind of Metroid-like interface, then the "window" can't be flat. I suppose it could be fixed in other ways like making the texture that CEGUI goes to a render target which is mapped to a piece of geometry, but I see no need to remove the possibility of using the third dimension natively.