Philosophical Tail Chasing

Forum for general chit-chat or off-topic discussion.

Moderators: CEGUI MVP, CEGUI Team

User avatar
Malkyne
Just popping in
Just popping in
Posts: 9
Joined: Wed Jan 12, 2005 12:06
Location: Sydney, Australia

Philosophical Tail Chasing

Postby Malkyne » Mon Sep 13, 2004 07:50

Okay, so as I've mentioned before, I'm working on a Gamebryo renderer for Crazy Eddie's GUI. Trouble is, well, there's a bit of a philosophical problem. In Gamebryo, screen polygons are objects that get attached to the scene graph, like other objects. Thus, you don't have to request that the renderer redraw them every frame. There's really no need to maintain a render list, or to treat a cursor as a special type of immediate. In Gamebryo, it doesn't make sense to tear down the quad list and rebuild it when one gets deleted; it makes more sense just to delete the one that was removed from the scene graph.

I have found that due to the differences in philosophy, I'm not sure that it's entirely possible to get this working in a sensible way simply by building a renderer. I wanted to believe that it was possible (I'm a big fan of implementation agnosticism!), but things just aren't working out.

I'm not sure I want to go into a massive retinkering of CEGUI to get it to cooperate, and then have to maintain an independent branch of the source code that will hardly be useful to anyone else. Meh. Does anyone have any thoughts or ideas on this matter?

Tess

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

Philosophical Tail Chasing

Postby CrazyEddie » Mon Sep 13, 2004 08:58

Hi Tess,

From what you describe, it definately seems like the two systems are very different and seemingly incompatible. Although in some ways it also sounds similar to some problems I initially had with the way Ogre is structured, although I was able to get around that by hooking into that system at a much lower level; I have no experience with Gamebryo though, so I have no idea if a similar thing could be achieved here.

Within the 'Renderer' system, I went for an approach that was as 'raw' as possible, which mostly works out okay with the base APIs (D3D/OpenGL etc), although when you go up a level or two and start dealing with scene orientatied engines and such, the same approach does not fit so well.

To deal in higher level entities, such as a 'window' (or whatever), at the rendering level was not part of the design for the system, so when removing a window from the display, it would not be that you remove a single quad from the scene graph, as there would likely be many quads that make up that window. Event more complexity may be found in widgets that are built out of other widgets, as at the renderer level, the nice window hierarchy we have higher up in the system, no longer exists.

There probably are thing you could do to get the system working, although they're probably not the most elegant solutions (one would be to keep internal copies of the quad list from this draw and the previous draw, and make changes to the scene graph based upon the differences between the two lists. Though this doesn't really solve the problem, but rather adds another layer to interface with the engine).

So, I've probably not said much that helps in this post; I do have a tendancy to just ramble on about nothing in general :roll:

CE.

User avatar
Malkyne
Just popping in
Just popping in
Posts: 9
Joined: Wed Jan 12, 2005 12:06
Location: Sydney, Australia

Philosophical Tail Chasing

Postby Malkyne » Wed Sep 15, 2004 01:48

Thanks for the detailed response!

Hi Tess,

From what you describe, it definately seems like the two systems are very different and seemingly incompatible. Although in some ways it also sounds similar to some problems I initially had with the way Ogre is structured, although I was able to get around that by hooking into that system at a much lower level; I have no experience with Gamebryo though, so I have no idea if a similar thing could be achieved here.


I have full source access to Gamebryo, so I could probably do pretty much anything I wanted to get things to work. However, I don't want to go digging around in the guts of things too much, because I'm in a rapid prototyping phase, right now.

Within the 'Renderer' system, I went for an approach that was as 'raw' as possible, which mostly works out okay with the base APIs (D3D/OpenGL etc), although when you go up a level or two and start dealing with scene orientatied engines and such, the same approach does not fit so well.


Noticed! :lol:

To deal in higher level entities, such as a 'window' (or whatever), at the rendering level was not part of the design for the system, so when removing a window from the display, it would not be that you remove a single quad from the scene graph, as there would likely be many quads that make up that window. Event more complexity may be found in widgets that are built out of other widgets, as at the renderer level, the nice window hierarchy we have higher up in the system, no longer exists.


Yeah, and I think that the design is perfectly good and valid. I'm just dealing with a mismatched problem, I think.

There probably are thing you could do to get the system working, although they're probably not the most elegant solutions (one would be to keep internal copies of the quad list from this draw and the previous draw, and make changes to the scene graph based upon the differences between the two lists. Though this doesn't really solve the problem, but rather adds another layer to interface with the engine).


The first implementation ripped things in and out of the scene graph on the fly, and as you might imagine, the performance was downright painful. So my stopgap solution was to do something similar to what you describe. In effect, it works a bit like mark-and-sweep garbage colleciton. I use an STL map to track quads that have been built and added to the scene graph. Whenever the rendering queue is to be cleared, it turns off the render flag on each quad, and turns on a flag indicating that we need to check for deletes. When addQuad is called on a quad already in the map, it turns the render flag back on. If it is called on a quad not in the map, the new quad is built, attached to the scene graph, and added to the map. When the next render happens, it checks for the delete-check flag, and if it's on, it detaches any unmarked quads from the scene graph, and removes them from the map.

The performance is still slightly less than desireable, but I see this as a stopgap solution, until I have time to do something better.

So, I've probably not said much that helps in this post; I do have a tendancy to just ramble on about nothing in general :roll:


Aw, don't put yourself down. You're actually super-helpful. I appreciate all the work you've put into this, and all the help that you give people on the forums!


Return to “Offtopic Discussion”

Who is online

Users browsing this forum: No registered users and 10 guests