0.8 rendering changes proposal
Posted: Tue Jan 04, 2011 00:52
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..
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..
). You can do this with CEGUI 0.7 the same way DX10/11 renderer is done.