Clean Up OO of Overlays, Elements, Panels

[AntonTheManton]

From my experience with building my own GUI, I think a lot of developer time could be saved with a few small tweaks to the panel/overlay/element system in the OGRE engine (as they are quite handy actually).

1. Inheritance and Polymorphism could be better as, at the moment a lot of very messy casts are required to create new objects, and I also find myself having to keep hold of pointers to each of the different casts from the same object to perform different functions, which is a bit messy also.

2. The ability to copy Overlays loaded from the .overlay files. To build my different widgets I had to write a whole lot of code. It would have been much quicker if I could just duplicate and modify a generic widget defined in a .overlay file. At the moment this is very hard to do, mainly due to unique name clashes.

With both of these improvements, you could knock together a custom GUI in about 2 hours, with hardly any code, and all visual adjustments made without the need to recompile. (Therefore almost eliminating the need to use a GUI library altogether).

Hope that helps!

[xavier]

You don't get hit-testing with Ogre overlays, so that alone makes it not a viable option for an actual usable UI solution. And since Ogre has no concept of HID input, it's not really feasible to make it do hit-testing (nor is it needed -- there are tons of perfectly usable UI solutions available).

[AntonTheManton]

I've used OGRE Overlays with Hit Testing in my project. It's only a couple of lines of code. I found making a GUI based on the OGRE overlays quite easy (I'm sure that's what they were built for), but it could be even easier for other developers wanting to do the same thing if they were a bit tidier and you could copy them.



(sorry, not sure why that image doesn't display but the url works)

[syedhs]

Well I am of the opinion that the Ogre's Overlay is actually meant for prototype and quick GUI (not QuickGUI ) because of inefficient batching number and a few others eg no direct way to hide/show certain overlays in one viewport.

In other words, it is better to have a separate GUI library for some serious GUI uses.

In a slight OT tone, my vote is to for the overlay to be separated from Ogre core and implemented as addon or something like that.

[xavier]

The only reason they are still around is specifically that -- they are simple to use (not to mention already done) for the purpose of the UI in the samples.

[AntonTheManton]

Ah OK, thanks for that information. In that case I I'll back off my GUI development so that I don't become too dependent on the Overlays.

This could be a good excuse to build that fully 3D GUI that I've always wanted...