Anything better than UIWindows for GUI?

[SpuTTer]

Hello. I’m almost at the point to where I want to release the first version of my game. I got my gui’s looking good and I finally got a workaround for the picking issues associated with standard picking + the UIWindow system.

However, I went to have a couple of my buddies test the game out on Linux and OSX. Both experienced problems with the UIWindow text being out of its box, double windowed, or similar results.

For me, it was kind of the straw that broke the camels back. I don’t have much Swing nohow so it could be something I’m doing on my side, but it works correctly on Windows.

What I’m wondering is, does anyone have a replacement GUI system that would allow Windows and such for Xith? I’m considering making my own system, but if someone has already done so and is willing to share it, I would appreciate it. Otherwise I’ll see what I can come up with.

I know survivor has support for it, sans mouse support. I would really like normal windows with mouse support.

Thanks!

[kevglass]

You want to talk to Blah^3, he’s working on the replacement for Survivor as we speak.

Kev

[blahblahblahh]

…and you should have a look at the conversation that accidentally sprouted in the JOGL boards. I think it would probably be a good idea to split off the Xith-parts of it to a thread here (perhaps Yuri could start it off?). Basically, for survivor-2, I’m hoping to write an OpenGL GUI and just run it from within Xith. If not, I’ll be porting my OGL GUI to Xith (just takes longer, and means 2 codebases to support, etc etc). I have no idea how good the results will be yet :).

http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=jogl;action=display;num=1090257869

[SpuTTer]

excellent

/me goes off and reads that thread.

put me down as a tester if you need some

[blahblahblahh]

Quote:
PS if anyone’s got experience trying to marry JOGL with Xith by hand, please msg me.

What exactly do you mean by this? I believe I can help a lot in all the points realted to Xith3D, but prefer to answer exact questions.

Quote:
IIRC Xith doesn’t support dropping down to JOGL at the moment

That’s true for a moment, but what I can do easily is I can add a special shader (Custom Shader) where you can put your raw OpenGL code. But this is to be separated for two major parts - streaming vertex data to OpenGL is more complicated part to extend, while setting of rendering attributes is much easier.

Or, say, another option: if you have an idea of how this “dropping down to JOGL” may look from the user side, post an example and we will try to find a way how to do this.

Yuri

Quote:
“OK, I’m doing something where I just want to chuck some OGL at the screen, and completely bypass SG’s etc”

I am thinking about this from another direction: it would (may) simplify for some OpenGL devs to play around some very custom code that may become potential candidate to integration into SG.

[if moderators will decide this discussion is irrelevant here we can move this discussion to Xith3D forum]

There are possible ways of plain OpenGL integration into Xith3D are:
a). Adding custom appearance attribute, so letting SG to perform state sorting and geometry streaming;
b). Adding custom “Plain GL” leaf node of the same style as Shape3D, so it can perform geometry streaming by itself (SG will set up appearance for it anyway, but node can override it by itself if needed).
c). Extra pre- and post-rendering passes.

The problems with plain OpenGL integration are:
1). Rendering order. One who uses plain OpenGL should either be aware that SG may change the rendering order, or use one of mechanisms to ensure correct rendering order (i.e. turn sorting off, or use OrderedGroups).
2). State save/restore. In order to allow smooth interaction of custom OpenGL code with SG renderer, custom code should save and restore the state it modifies before return, otherwise this will affect the rest, potentially producing completely wrong results.

I can relatively easy to come with preliminary implementation of b) and c), while a) should be designed with a great care, because of it should (?) allow multiple custom appearance attrs to be set on single shape.

Yuri

Quote:
OK, I’m doing something where I just want to chuck some OGL at the screen, and completely bypass SG’s etc". I don’t know if that’s feasible - or even sensible - in Xith, and it may be I’m barking up the wrong tree here

The way Aviatrix3D deals with this is it has a separate interface called RenderEffectsProcessor. This is set as one of the attributes of the Scene and gives you two methods - preDraw() and postDraw() which allow you to insert arbitrary OGL code into the rendering loop before and after AV3D has finished it’s processing. We designed it for exactly this sort of situation where the user wants to do some external drawing such as 2D layers or compositing work. I’m sure a similar concept could work in Xith3D as all you do is just pass this down to the rendering loop and it just makes the calls to the two methods at the start and end of it’s rendering loop.

[blahblahblahh]

So, some more use-case details for Yuri:

I have split the various elements of the JOGL callbacks into separate interfaces (from a java POV it was a stupid idea to put them all in one interface!). e.g.

initialiser: init( GLDrawable ) …
renderer: display( GLDrawable, … ) …
reshapelistener: reshape( GLDrawable, width, height … ) …
etc

This has huge benefits in that you now have pluggable init code etc - you neither have to write everything N times for N scenes, nor do you have to manage garbled massive monolithic methods that “do everything”.

With this modular system, to make it useful for GUI’s, I also need to layer multiple renderers on top of each other in one frame - e.g. you have the “drawQuakeLevel” renderer and a “HUDrenderer” and you want to do both every frame. So, the renderer interface is a bit more complex, pulling out the per-frame setup stuff so that you can configure renderers how you like to e.g. not clear the buffers and overwrite the previous renderers’ work - without having to modify the individual renderers’ source.

So, the next question is how to integrate this into Xith. It seems with my current use cases that all I need to do is have a simple way of wrapping these interfaces. E.g. a special “raw OpenGL” interface that contained callbacks for all the different parts of OGL rendering, so that I could implement it and use it to wrap my rendering system.

At the moment, my use cases are such that I’m happy to merely shove all my OGL in a single node in the Xith tree - I’m primarily using it to do menus, HUDs, and other “flat” GUIs that will be rendered atomically on top of everything else, so that render order compared to the rest of the scene is irrelevant - just as long as the opengl node is correctly positioned right in front of the camera and hence always renders on top of everything else.

I am concerned that I may be doing something stupid here - in Xith, I should be building an SG-based GUI and an SG-based menu etc. So, for clarification, my reasons for doing this (or attempting to) are:

• the UI overlay stuff in Xith simply doesn’t work beyond “toy” examples. It’s full of bugs and has some major performance problems. If it worked, I would probably not have bothered doing any of this - not even the JOGL stuff.

• I’m building this for JOGL anyway, and if it could work transparently in Xith (with some “write-once” wrapper that doesn’t need recompiling) then Xith would get it “for free” without extra support effort for me. (and there may be other OGL stuff that would easily be ported to Xith again without the need to alter the source, so that Xith could just always plug-in the latest version without alteration)

• My GUI framework is (or will be) a heck of a lot better than Swing in several key areas - e.g. I’m going to merge in my custom layout system that works much better than Swing’s. But it won’t come with lots of widgets. It is aimed specifically at making in-game GUI’s for games, rather than being a direct competitor for swing. Personally, I think it was a misteak to make Swing/AWT merge widgets with layout and everything else - they should have been separated into different layers. If I provide people with a layout framework, I’d expect someone else would probably implement widgets within that framework, as a separate project.

PS it’ll be open-sourced once working. Although I wouldn’t recommend anyone waiting for it :).

[blahblahblahh]

I’m primarily using it to do menus, HUDs, and other “flat” GUIs

Of course, not actually “flat”: e.g. use small icosahedra for buttons, or rotating cuboids for rollover displays / animated menu items etc.

But…all kept within a shallow bounding region, usually just the frustrum’s projection area clipped between two very close planes.

[SpuTTer]

PS it’ll be open-sourced once working. Although I wouldn’t recommend anyone waiting for it :).

So, when do you expect to have some kind of alpha that we can test

[blahblahblahh]

Wait until the next release of survivor, by which time I should know that it works reasonably well.

It will be one of approximately 5 things going in the JGF source-code area (all of which are under a true free license - you can do anything you want with the code, so long as you preserve attribution) which are just little snippets people have written that are handy to most of us.

So, might have to wait until the later of survivor-v2 and JGF-v3 :).