Design: GUICore and new Render related classes

With the new rendering scheme I want to implement, quads will be put into "QuadGroup" objects, which are a zOrder sorted list of Quads that all share the same material.

Currently the SkinSet class makes use of a material, and each SkinSet will have a material for it. But what about fonts? Currently I am just grabbing the font texture from the material created by the Ogre::Font class. What I'd like to do is make a QuickGUI::Font class, along with a QuickGUI::FontManager class, to be used by Text objects. The reason for doing so is because Text will because its own QuadGroup, and also because I want displayed text to support Ogre material functionality.

Since the FontManager class will be using the Font class which makes use of Ogre::FontPtr, Ogre::TexturePtr, etc., it can't easily adapt to the static singleton creation that the SkinSetManager or ConfigParser does. What I'm considering is to make a GUICore class, similar to what RBGUI has. (alternative names are welcome..) Although this won't register the ConfigScriptParser for you, it can be used to manage creation and destruction of SkinSetManager and FontManager, as well as GUIManagers.

The way QuickGUI will be used in apps is mostly the same:
[start setting up Ogre]
- register config script parser
[end setting up Ogre]
- create GUICore
- load Skins
- load Fonts
- setup GUIManager
- build GUI

Just to make it more clear, the reason for Fonts is because I would like to allow users to make use of fonts that can have Ogre material functionality. For example, you could have some fonts like:

"myFont.10"
"myFont.10.bold"
"myFont.10.GlassCompositor"
etc.

Every QuickGUI::Font will have its own material that you can modify, and eventually serialize to script.

Please post any concerns or questions, I know I haven't really went into depth regarding the Render System.

As far as i am concerned i think this approach for fonts would be very good, another elements brought up in my team was the lack of texture manipulations. The way i see it right now the textures do not use material, and this is not a good thing, UI textures should be textures declared in material, this will cause a lot of head ache if we want to add special effects on them, or if it does not use material we have to find a way to explicitly load effects on widgets. I do not know the state of the gui on this regards, but yesterday, our artist asked if it was possible to directly add the functionality of layer effects in photoshop and it could if we used material. Anyway give me a buzz on this one.

A while back I loaded up the demo without a skinset loaded, and was able to manually load each texture for each GUI widget (and components). The result of this is no batching optimization at all. In debug mode, the performance was significantly worse than normal.

In order to maintain texture batching while including use of materials, I have limited 1 material per SkinSet. As you know, a SkinSet combines all textures into one texture atlas, which can be used to skin various widgets, in combination with UV positioning. This also maintains texture batching, since a large portion of widgets are using the same material.

On the plus side, this limitation can be somewhat overcome by creating other SkinSets. You could create a separate SkinSet for just 1 widget if you wanted, there is no limit in this regard.

You could make several skins if you wanted:
"qgui"
"qgui.myShader1"
"button.unique1"

The SkinSet implementation will need to be updated soon, so that the textures do not have to match the skin name, which could even extend to the skin component naming. This is the current direction.

Something like this:

MySkin.skin:


name MySkin
{
ImageType IMAGE_TYPE_PNG

SkinComponent .button
{
some_texture
}
SkinComponent .button.down
{
some_other_texture
}
etc..
}


I have no objections (besides the fact, that another API change won't make me happy). I probably would be worried about performance, but it seems you are already addressing this problem.

It would be nice to allow multiple texture to overlay one another on a widget, and be able to specify how the transparency will be handled for each, you think we can go there at some point ? Also i am pretty sure at some point in the future, people will like to have meshes instead of simple quads for advanced 3d widgets, cause if you cannot add bumpmap, normal maps, specular maps and all the fun tools of advanced 3d, this UI will stay at a basic level (my two cents, and we will probably need this at some point )

Every component within a GUI should be specified by a particular texture. If no texture is specified, it will not be rendered. I don't understand what is meant by textures overlaying each other, maybe a screenshot would help there.

Widget appearances are defined in a Skin. (SkinSet) A skin doesn't have to define all widgets, you could make 5 skins, each describing how a combobox and its components appear. I think this is the most flexible, organized, and customizable way to go about skinning widgets.

3d GUI is currently a dream, I wouldn't begin to think about that until the 2d aspect is a lot more mature. And also, 3d GUI could be done by ray casting and custom meshes, I'm not even sure this fits into QuickGUI's scope. Movable text and progress bars would be desirable at some point, but there is no point to jump that far ahead, planning for it would be a waste of resources.

Games are never great because of their GUI, but a game could totally suck because of it. You'll never hear something like "Did you see the shader effects on that scroll bar, it was amazing!" Most likely you'll get something like: "Cool. Now how do I play?" (not intended to be offending, but don't focus toooo much on GUI, just make it unique, make it elegant, make it do its job. )

You'll never hear something like "Did you see the shader effects on that scroll bar, it was amazing!"

LOL

ok have a nice week end

I agree mostly with the whole idea. As far as "shaders on that scrollbar" go - well, I'd say keep GUI 2d base, but have a special case for a GUI on a 3d object - just give an example look at Fallout 3 and how they are doing Pip-Boy (really nice IMO, that's the future of "real GUIs")

I'll have to do a google image search and see what it looks like.

I do want to enable and allow fancy GUI effects, I just want to make sure we have a solid base and widget set before tackling those areas. (not to mention a skinset editor and layout editor maybe, and these are not trivial tasks!)

Damn, they removed it from the main site...

Oh, found it again, click here.

So, you see, what I like is that this is normally a 3D object, but at the same time it is a piece of GUI. So, basically you can interact with it in the environment, it gets reflected, you can use shaders, and so on, and so forth.

Actually, as far as editors are concerned - I'd say don't worry about them. It does not matter if all we need is Photoshop or Gimp, and just make the skinset to a template.

Wow, that is sweet! I gotta run now, but thanks for linking it!

pip boy has more shaders on it than all of oblivion

thats next gen

yep. well, QuickGUI then has to offer next-next-gen (or something)