RenderTargets - CEGUI's latest development

[Pompei2]

I'm happy with the fact that the OpenGL updater is being the first updated

The new model for the renderers is much more efficient

What interests me most: will a "lot" (just a paragraph) of text being displayed still slow down the whole app like a turtle in debug mode? That's the only performance issue I have encountered yet (besides resizing windows).

[CrazyEddie]

@ErikHjortsberg:
Thanks a lot for the recommendation of GLC - my previous attempts at capturing videos had been less than great, hence the use of the video camera for the Demo7 video

Now I should hopefully be able to upload something that's a bit higher quality.

@Pompei2:
With regards to the text, as with all things, it depends

If you back the window containing the text (or even some parent, if they're fairly static also) with a CEGUI::RenderingWindow (which caches the content to texture), then rendering this will be really fast, since it's just a single quad as opposed to a quad for each letter. Having said that, even without the texture backing you'll definitely see an improvement in performance.

Resizing - especially if you have lots of relative co-ords in the content - is maybe the one place will still take a bit of a hit (I don't think it's anywhere near as bad, though). There's no real way around this because resizing causes all the geometry for all affected windows to be regenerated.

CE.

[Pompei2]

Sounds cool

[gring]

Great, this will be really tasteful when being used out there, this rendering to textures is it done to predefined textures that the Z order can be maintained with other 3d objects or is it still in it's own z plane on top of applications?

Awesome if the rendering speed will improve on text. Looking forward to test the new stuff, will probably beat 1 texture per letter by a mile....

/G

[Jamarr]

What interests me most: will a "lot" (just a paragraph) of text being displayed still slow down the whole app like a turtle in debug mode? That's the only performance issue I have encountered yet (besides resizing windows).

I haven't looked into how CEGUI handles fonts/characters at all; does it actually use the 1 texture/character approach? Do you know if it loads all characters from a font into memory automatically?

It should not be too much trouble extending the backend to use a single texture for all characters and just store texture coordinates and character-extents per character - that way CEGUI only needs to bind a single texture when rendering characters.

It may also be worth adding in functionality to only load a small set of codepoints when loading a font; this way, say if you only want to load the numeric characters from a specific font CEGUI does not have to load all of the codepoints from that font.

And while we are on this subject, add built-in support for loading font files directly (the xml-thing is highly annoying).

Thank you. ^_^

[CrazyEddie]

@gring:
We're still rendering basically as an overlay to whatever has already been rendered - and we have no interaction with what's already been drawn (except maybe for one possible requirement, which will be decided tomorrow, probably).

The main reason for rendering to textures is partly for performance gains and to make the various effects simpler to pull off (I will demonstrate, however, why even this is not required for some effects). Rendering to texture is entirely optional and can be enabled/disabled on a per-window basis, this allows you to fine tune things to get the absolute maximum performance out of CEGUI. If you're not looking for fancy effects, and have only a simple GUI layout, then not using rendering to texture can now be even faster in many cases.

@Jamarr (and gring, I guess!)
We never have had one letter per texture - it is/was one quad, i.e. two triangles of geometry. The glyphs were always put on as few textures as possible.

Currently the font will automatically load glyphs in 'pages' - upon the first use of a glyph various glyphs surrounding the one used will also be rendered. This has good and bad points, especially when talking about asian languages. The older font had a mechanism where you could specify ranges of glyphs up front, this was a good thing to have but unfortunately was removed - this was a mistake in my opinion.

I agree there is much improvement to be had in the font department, though it's one thing at a time my friends

With regards to needing XML for fonts, it is already possible to load a font directly from a .ttf file in code without the need for any XML - not sure if you meant that, or the ability to specify the .ttf file in a scheme?

Quick update on the renderer rewrite work: I have one remaining broken-feature issue that must be fixed before I can commit any code. Once that's done, there a lots of other little issues but most of those can be worked though after the initial commit, I think.

CE.

[CrazyEddie]

Update time.

I have most things working or half-working now. I have to run tests on Win32 and Mac tomorrow, and maybe fix a few other things. Having said this, I'll definitely be committing some code late tomorrow - no guarantees as to what state the code will be in, or how many issues there will be (there are still a lot of smallish things to be addressed), but the code will be committed nonetheless.



CE.

[CrazyEddie]

Ok. The initial code was committed last night in:
cegui_mk2/branches/renderer-rewrite-devel

Note that this is definitely not supposed to represent a finished version of the rewrite in any way, shape or form. The code in this branch, as with the original rendertarget-devel, is to be considered highly unstable and experimental. Basically, until the code gets merged into trunk and represents the 'current development code', I'm really not that interested in hearing about any issues you might have, so there's not a lot of point coming here and reporting 'obvious' issues and bugs, or moaning about other things because you will either be ignored or perhaps verbally abused - depending on the way I feel at the time

I have successfully built and run things on all three supported platforms, though today I see a 'fix' for Windows flaky GL support actually broke things on the Mac I'll address this sometime soon.

I did not commit the wobbly effect code yet. I may get that in tomorrow or Monday.

Currently there is only support in for FBO based TextureTargets - so if your hardware / GL version does not support this you can forget about trying this out for the time being. The same thing applies if you do not have NPOT texture support.

Some of the issues in this first attempt:
Currently we're writing all over the main rendering depth buffer and need the results untouched - this is ok for demos as they stand at the moment, but might not be good in your own apps We're using this for hit-detection on rotated window content, in the final version it will be more selective and will function correctly on the TextureTargets for nested rotations, and also alleviating the need to touch the main depth buffer.

Some imagery is drawn in the wrong order - text selections and such are not functioning correctly.

'Dragging' certain content (like in the Drag & Drop demo) you can see the "dragee" gets clipped at the boundary of the containing window (this might only be when texture backed, I can't recall off hand).

Some initial corruption of some imagery on Mac.

Various items use the display size (i.e. like the old Renderer Area rectangle), this is incorrect, as these items should be using the size of the rendering 'root' instead.

Framewindow Rollup is not working correctly.

Plus lots of other stuff I know about but can't recall without looking it up(!). Additionally, there will be lots of other issues as well.

Oh, and I added a funky looking spinning CEGUI logo to the demo app

CE.

[CrazyEddie]

Ok, I've made a few fixes today:
- Tree rendering working (still not 100%).
- Editboxes text selection now drawn correctly.
- The inner-rect / client area fix is functional in this branch, though the layouts need updating to de-compensate.

I've also added the wobbly-window effect code I used for the earlier Demo7 video.

Here's a new video that shows Demo7 again: http://www.youtube.com/watch?v=46FZ21O4Ixk (higher quality available on this video) this is running from the code that's in the svn branch discussed above.

CE.

[Jamarr]

With regards to needing XML for fonts, it is already possible to load a font directly from a .ttf file in code without the need for any XML - not sure if you meant that, or the ability to specify the .ttf file in a scheme?

I did mean directly. The impression I got from the beginner tutorials was that you had to use the xml-files to load fonts, so I did not bother looking any further into it. Now that you mention this, though the information is a bit sparse, I figured out how to load them directly: createFont() -> setProperty() -> load(); this will be helpful later on.

Also briefly looked at the OpenGLRenderer in the new branch; looking good, but I have not downloaded/played with it yet...also, let us know when it is ok to comment on things without being verbally abused!

[CrazyEddie]

also, let us know when it is ok to comment on things without being verbally abused!

Verbal abuse is not guaranteed, you may just get ignored

People are of course always free to comment, especially as regards to the general state of things. I would like to avoid lots of "bug" reports, build issues, complaints, and such with regards to this early code because for me - at least at this stage - this would be counter-productive and a waste of time that could have been better spent actually working on the code

So: Comments? Yes. General queries? Yes. Whinging and moaning? No!

CE.

[CrazyEddie]

A quick update, since things have gone quiet for a couple of weeks

The core interfaces for the new rendering subsystem are now 99.9% stabilised. One thing I need to change is to extend the ImageCodec facilities so they're available to all renderers rather than just the OpenGL and DirectFB ones. Once this is done (tomorrow, probably) that should pretty much be the core interface and system changes complete.

Except for any issues related to the above change, and aside from needing to go through and ensure we save / restore state where needed (which should be completed by the middle of next week), the OpenGL renderer is also basically done (with regards to VBO use, discussed elsewhere, I have a patch for that, though I'm not entirely convinced using it is the way to go. There is an increase in standing performance, but a larger performance decrease when interacting with the elements. It's probably an implementation issue, but in either case I'll make the patch available after the merge, and depending on feedback, will decide whether to use it or not).

The next task will be to write compatible renderers for the other supported APIs and engines; I don't foresee this taking very long (most of the time so far has been spent patching up other areas of CEGUI), and depending upon how that actually turns out, I intend to have this branch merged back in to the unstable trunk by the end of this month.

There are still many smaller issues within CEGUI that need to be addressed; once the merge is done I'm hoping you guys will be able to assist in identifying and fixing some of those

CE.

[Pompei2]

99.9%

Hehehe, you say this very often the few last weeks But I know what you mean, I have the same problem

Anyway, good news, that will be a good reason to upgrade my game to use the newest trunk and I will be glad to report any annoying bug I will find

[Jabberwocky]

Thanks for the update. This is an exciting development for CEGUI.

[CrazyEddie]

99.9%

Hehehe, you say this very often the few last weeks

Yeah, I know This is one reason I'm expediting the merge - and eventual release - otherwise we're likely to stay at that 99.9% state indefinitely, while I try and achieve perfection

This is an exciting development for CEGUI.

Definitely This has been a long time coming (too long), though hopefully it will have been worth the wait.

CE.