CEGUI (Crazy Eddie's GUI) Forums

I've been quietly working on the renderer module for Direct3D 9. Things are taking shape, though there are some annoying little bugs and other issues. I'm also undecided about the final approach to be used - currently it's using DrawPrimitiveUP, which is far from ideal (as you can imagine!), though raw speed without TextureTargets in the FirstWindow demo exceeds performance of the OpenGL version.

Another issue with this implementation at the moment is that in a debug build, it crawls when you interact with the UI - which is really odd, because the OpenGL version does not suffer the same issue.

Anyway, this weekend will see the OpenGL and D3D9 implementations pretty much done (aside from bugs and possible last minutes snagging). Monday I'll start the renderer for Ogre3D.

CE.

Quick update time

I'm about half-way through the Ogre renderer rewrite at the moment; the renderer class itself and the texture class are basically done, which just leaves the core RenderTarget based classes. This is going to take a little longer than the week that the D3D version did, since I am not as experienced, comfortable, or confident when it comes to Ogre as what I am with OpenGL or Direct3D

I also did further analysis of the D3D9 renderer and there is definitely improvements to be made there. This further optimisation will be done for the D3D and GL renderers after the Ogre renderer is up and running - one reason for this is that the Ogre renderer is kind of 'hinting' at certain implementation possibilities that will be beneficial if subsequently ported to the other renderers also. Nothing more concrete to add at the moment, since I'm letting some of the ideas rattle around my head for a couple of days.

Anyway, I'm probably not going to be working on this today - all work and no play makes CE a dull boy

CE.

Really, really looking forward to what this brings!

Currently it brings a nice blank screen

Not sure what I've messed up at the moment, but it's almost certainly something silly

CE.

I've now fixed the blank screen issue and have the Ogre implementation up and running.

Currently it's not ideal, since each GeometryBuffer is using it's own HW vertex buffer, which is probably not what we want. I'll try an alternative approach where hardware buffers are used on a per RenderTarget level instead. This presents a "granularity" issue, and ultimately there will need to be a trade off between the number of hardware buffers and limiting what needs to be redrawn (this holds true for all of the renderer modules). Overall I'm looking for a balanced approach - input on this issue is very welcome

Anyhow, there are still some issues (as always ), although I should get something committed around the weekend. This will leave Irrlicht, D3D10 and DirectFB renderers to do (this is getting a bit tiresome, in case you were wondering!).

CE

I'll be committing the Ogre renderer later today. In the end I did not change from having vertex buffers on each CEGUI::GeometryBuffer; I'll guess I'll keep an eye on the whingemeter once this is released

Yesterday I had the Ogre Gui demo running using the new renderer, and there were lots and lots of issues - not sure what was going on, since our CEGUI demos ran fine under Ogre. Since then I've added a bit more 'support' stuff, so will try the other Ogre demos that use CEGUI and see what issues they have.

Tomorrow I'll probably spend the day working through some of the items that are building up on mantis rather than work on the renderer rewrite

CE.

The Ogre renderer is functional, but with a few issues that have yet to be looked into.

Today I'll start the Irrlicht renderer. Overall progress is oh-so-slow and something of a grind. I look forwards to the day when the basic functionality for all the renderers done and I can get things merged back into trunk; at that stage I'll start worrying more about the outstanding issues, additional tuning and such.

CE

Re: Ogre Renderer

Was there any noticeable improvement in FPS? I know people bitched about CEGUI under Ogre a lot but we never had a real issue with CEGUI's rendering speed.

I didn't do a before and after comparison using Ogre yet, though the frame rates coming from the CEGUI samples are largely comparable between the OpenGL and Ogre, where Ogre rates are very slightly lower than plain OpenGL rates, but this was always the case and is to be expected when considering the additional overhead of using the engine[1]. So having said this, the conclusion is that when using the texture caching with the Ogre renderer, yes there is a definite improvement in FPS (for example from around 2000 FPS before to 3000 FPS now when running Demo7 - hardware dependant, obviously). As indicated, I don't have reliable figures for different permutations at this time, and it's probably not a great idea to do that until some of the remaining issues have been addressed, since that may affect performance also.

One thing to note about the existing Ogre renderer (the one before the rewrite) is that, at least when talking about flat-out rendering performance (when not interacting with the UI), it is very nearly optimal - I do have a minor fix for it that will save a few FPS but otherwise it's very, very good. The main hits come from two places; first is when people render pages of text - which equates to tens of thousands of triangles - and expect to get that for free, and second, when interacting with the UI - which causes the cached quads to get completely regenerated. Both of these issues have been addressed at some level in the rewrite. The cost of rendering large amounts of text can be lessened by caching the text to a texture (so you only render two triangles instead of thousands). The cost of regenerating UI geometry has been lessened in very many cases by having each window cache it's own geometry locally instead of everything in one big buffer - this means that only those windows that change will be causing any work to be done, as opposed to the previous situation where any change would cause every window to have to resubmit it's geometry (quads). Once the renderer rewrites are done, we may look further at text rendering and see where additional improvements can be made.

In reference to people bitching, I think in many cases people expected too much.

CE


[1] For our samples where we're currently only rendering CEGUI, the overhead of using engines as opposed to straight APIs does come into play. This is not a sleight on rendering engines, obviously in real-world scenarios that overhead would be incurred whether coming from the ready made engine or from custom alternatives and so need not be considered important when looking at FPS. We have to consider it here in order to explain the 50 or so FPS difference.

Those sound like some fantastic areas for performance optimization. Looking forward to see the changes in action!

Aside from glitches galore and the possibility of needing a patched version of Irrlicht, the rewrites should be initially done and ready for merging back into trunk around next weekend or thereabouts (so that will be around the 14th March).

Some people may be concerned at my haste in wanting to get this merged back into trunk. My priority here is the advancement of the code base and the project (anyone wanting 'stable' should definitely remain on the v0-6 branch!), and I do not think this can be achieved without pushing this rewrite hard - so for a while it will exist in a kind of warts-and-all state, though being in trunk should get some additional people using it quicker. There's also the possibility of 'unstable' releases, though I might have more news on that in a few weeks.

CE.

Update time again

The Irrlicht renderer is now pretty much done. Currently we're not blending the alpha from the vertex colours, since Irrlicht does not support this along side alpha in textures (yea! really!). They have a patch that enables this support in Irrlicht, and once the last two renderers are up and running I'll add a conditional that will use that support where it's available - you should nag them to get that patch incorporated into their code base

I am now working on the D3D10 renderer and that should be done tomorrow, this will just leave the directFB renderer. I do believe I see light at the end of the tunnel...

CE.

I wasn't able to work on the renderers yesterday due to teetering on the edge of migraine all day, but after a grinding away on it hard all day today, the D3D 10 renderer has been rewritten and comitted to SVN. As with all the others there are areas that will need to be revisited, although the basic functionality is there.

Tomorrow I'll start the DirectFB rewrite, which is thankfully the last one (and will likely take a lot longer than the others, since I've never even looked at the API before ).

CE.

The DirectFB rewrite is not going so well

Basically I've always had issues with testing the DirectFB renderer (my system appears to be unaccelerated as far as DirectFB goes), and so now I end up with nothing working due to certain functions not being implemented at all (like TextureTriangles).

The rewritten renderer code I have at the moment is semi-done. Much of the 'common' parts are operational, the Texture class should be ok, it's just the main rendering parts that are either incomplete and/or untested. What I'm going to have to do is commit this as-is and leave it in it's current unfinished state until either I can get DirectFB working on my system in a way that allows me to use it properly, or someone else steps up to complete the work for us . (This holds true for the distant future too; no releases will be additionally delayed due to a non-working DirectFB renderer module).

Tomorrow and Friday I shall clean a few things up and the merge into svn trunk shall proceed as planned on Saturday

CE.

Ok.

After a fashion, a few aborted attempts, and much hair pulling, this code has now been merged back into trunk (what a nightmare that was!). As such no further development will take place in the renderer-rewrite-devel branch. Be aware that svn trunk is now very unstable as-per my post yesterday.

Today I will move the renderer files around a little, basically to shorten include paths a bit. There is no point in having "RendererModules/OpenGLGUIRenderer/CEGUIOpenGLRenderer.h", the second level directory name is far too verbose and just gives information we already knew. This is to be shortened to "RendererModules/OpenGL/CEGUIOpenGLRenderer.h" (and the same for the other modules, obviously).

The second job today is to change the renderer module names produced under MSVC++ to more closely match those produced under other systems and compilers (everything else is already using the correct convention, it's just the renderer modules that are not).

Lastly, I hope to at least get a start on the new Xcode project, since that's been missing, and on the TODO list for a while now!

CE.