CEGUI (Crazy Eddie's GUI) Forums

Well i'll tried to integrate CEGUI into my application , and it was kinda hard, at first it was really confusing to destroy CEGUI cleanly, but after couple of hours studying the samples(and those samples has lots of lots leaks) i wrote the correct code.

For finding leaks i use Numega Devpartner .

But the second problem was very strange , i've spent all day searching, why nothing is showing up on screen.

I am using an OpenGL Renderer, in my program i've used Vertex Buffer Object and i suspect that CEGUI does the same, so



didnt draw anything until i wrote like this


Can someone give me a hint, what was wrong ??? Doesnt CEGUI binds VBO buffer for its self????

Sorry for bumping this post. But I encountered the same problem and "glBindBufferARB(GL_ARRAY_BUFFER_ARB, 0);" helped me.

So I wonder, is the CEGUI OpenGL renderer using VBOs?
And is it expecting GL_ARRAY_BUFFER_ARB to be bound to zero before it starts its rendering pass?

Hi,

I didn't see this when it was originally posted, otherwise I would have fixed it already

The current implementation does not use glBindBuffer itself, the issue is that if somebody else has used this function then this state then differs from the default which is why CEGUI rendering then fails.

So in any case, this is basically a bug in the renderer. There are probably lots of others too, the issue is that if we want to be totally bulletproof here we would have to set every GL state, including every possible extension, every frame. As it is we just 'fix' the missing states as they get reported.

CE.

Or just require that users restore opengl to the 'default' state before calling renderGUI()? This way cegui only needs to worry about non-default state changes. Why anyone would manipulate the gl state, call renderGUI() without having restored the previous state first, and then wonder why something is wrong is mind boggling...

Adding a billion different state changes into cegui's renderer is just going to add additional overhead to other users who /never/ manipulate that state to begin with, or who already clean up their state changes.

And since it was not clarified, the opengl render uses vertex arrays not vertex buffers. VBOs require opengl v1.5+ and the opengl renderer has not really been updated to make use of extensions *or rather, newer language features.

Yeah, thanks for that, I should have been explicit about our non-use of VBOs.

I think I might add this idea of relying on the default state to exist as an option in the rewrite.

CE.

I agree that completely safeguarding the OpenGL state is not something CEGUI should do from a practical and performance point of view.
I just wanted the "workaround" to be confirmed.

Perhaps the faq should be updated with it?


By the way, are VBOs considered for the new renderer? If it already uses vertex arrays then adding support for VBOs shouldn't be that much of a problem. Perhaps added as a subclass?

Nimos wrote:By the way, are VBOs considered for the new renderer? If it already uses vertex arrays then adding support for VBOs shouldn't be that much of a problem. Perhaps added as a subclass?

The OpenGL renderer rewrite is somewhere around 70% completed. It's still using arrays rather than VBOs at the moment. The whole approach to geometry has now changed, and I believe it would be very easy to offer VBOs as an alternative (or even mix and match). Once the rewrite is done, I may revisit this idea and see how it goes

CE.

CrazyEddie wrote:offer VBOs as an alternative (or even mix and match).

I would prefer you to make a simple test and check if VBO is more performant (as I think) and then make VBO be the default! VBO is the only performant drawing method in OpenGL. Or do you have a special reason not taking VBO as default?

Yeah, I'll definitely run a test of VBOs within the context of the way CEGUI will be using geometry (which is nothing remotely like what the existing OpenGL renderer is doing, this will be a large surprise to many I think) and then make a decision - obviously that decision will be to favour whichever solution is faster.

When the codebase featuring the new GL renderer gets put into a SVN branch (which will probably be over the coming weekend), there will still be the opportunity to polish and refine things somewhat (though there will be no intention of making large architectural changes).

The new implementation is doing pretty much the absolute minimum work possible in order to get things to the screen - the results are quite impressive, even without using the facilities based on rendering to textures

CE.

It doesn't have to be either or, I'm sure CE will set it up to be backwards compatible. You can easily check opengl specs of the system the code is running on, if it supports v1.5+ use VBOs, otherwise fall back to vertex arrays/etc.. There are quite a few areas where this tactic could be implemented to increase performance for newer systems.

But aside from that, the implementation of the renderer itself can be significantly improved. I could already tell the renderTargets-devel branch that CE was experimenting with would be a huge improvement, and he says this new approach will be even better. Personally, I can't wait to see it ^_^

Nimos wrote:I agree that completely safeguarding the OpenGL state is not something CEGUI should do from a practical and performance point of view.
I just wanted the "workaround" to be confirmed.

Perhaps the faq should be updated with it?

I would disagree if the library disables something then it should enable it again once it has finished and vice versa. I mentioned this sometime ago:

Mesh culling was fixed by enabling the z buffer on every render call in the app. I really think the gui library needs to look at this you set options before rendering in "initPerFramStates" yet do not store and reset the states, this is bad form I feel and would question why you do it?

http://www.cegui.org.uk/phpBB2/viewtopi ... highlight=

Sorry, bad choice of words on my part. I meant that CEGUI should not be responsible for restoring the OpenGL state to standard state before it does its rendering.

If it changes the OpenGL state itself during rendering, for example activating something with glEnableClientState, it should of course restore it afterwards.

dmail you misinterpreted the post, but you have the right idea - just as CEGUI should be responsible for manage its state changes, users should be responsible for managing their own state changes; CEGUI should not be accountable for every possible state that a user might change before calling CEGUI::System::getSingleton().renderGUI().

stop skimming

I think we all agree what the correct action should be here with regards to GL states. Yes, there are a couple of issues where CEGUI messes with things without saving the previous state, I'll work to fix these (I'm still doing it in the rewrite too ).

With regards to the other conversation in this thread, yes, of course if a VBO implementation is provided, we would fall back to arrays where the hardware is unable to offer VBOs.

@Jamarr:
The rewrite is coming along. Some of the RenderTarget facilities out of rendertarget-devel are used in this version also, although in a slightly different arrangement. There are some issues to be resolved, but ignoring those for the moment, I'm really quite happy with things the way things are going. There are only a couple of bits left to implement, which should get done tomorrow, Friday and Saturday, it should only be a short wait then until the code is available from SVN (if there are no disasters, sometime on Sunday).

CE.

Just to update with regards to VBOs. I ran a test and there is some level of additional improvement over arrays. I will add this support, though it may not be in the initial commit, but follow a couple of days later or something

CE.