Leveraging renderer-specific capabilities (like 3D)

[baxissimo]

What are the major obstacles to overcome to allow widgets to be drawn using specific functionality available only on certain renderers?

For instance, a rotation ball widget like GLUI's would be neat to have. (http://www.cs.unc.edu/~rademach/glui/)

It there some obvious way to make the problem tractable? Right now it seems everything renderer and every widget has to conform to a lowest-common denominator of supporting/requiring only texturing and alphablending. But many of the supported renderers can do much much more than that. It would be great to be able to take advantage of the 3D capabilities of the most popular renderers somehow.

(And mostly I don't want to have to give up on my arc-ball widget! It's too handy. )

[Dalfy]

I would say yes it's greate to add some new widget but no it's not a good thing to use renderer specific code at the moment. I think CEGUI is not yet ready for some optimisation because of the following:

• 0.5 (due to april 1st or 2nd) introduce some new way to describe widgets. That's new and requires some feed back from the user.
• 0.6 Will introduce some change whitin the very kernel of CEGUI also to allow skin switching for example.
• Fonts handling complete rewrite (sometime after 0.5 or sooner)

At the moment we do not know the amount of change that going to appear soon and we don't have the human power needed to do the work several time. We will work on optimization (and by the way taking in account the various renderer capabilities) when we reach a stability in the feature/widget/customization.

Hope I explain well

[lindquist]

there is nothing keep you from rendering stuff to a texture and putting that in your gui...

[baxissimo]

there is nothing keep you from rendering stuff to a texture and putting that in your gui...

That's a good point. For GL or DX renderers one could use render-to-texture functionality. It would induce some overhead, but the GUI is hopefully never going to be so complicated that that would be a bottleneck. That should be good enough for the arc-ball widget at least. (For that matter the arc ball is simple enough that you could probably get away with rendering it in software)

The idea is similar to the discussion on the other thread about making GUIs with a vector-graphics engine like AGG. If there were hooks to be able to provide a custom image at any point when a widget might need to change its appearance this kind of thing should be very doable. Maybe that's doable already? I need to educate myself on how imagery is currently handled...

But this would make the renderer-specific functionality more of a skin or look and feel thing than a renderer thing. Might even be possible to have OpenGL widgets under a DirectX renderer. That would be wacky. But I don't see any technical reason why it wouldn't work if the OpenGL is just doing off-screen render-to-texture operations.