Have fun with it :-)It contains many application core-stuff - may be useful for you, too....The event-handling is a little bit heavy and designed for non-game use (e.g. CAVEs, Medical Environments) - may be replacing makes sense...

Currently i'm redesigning/experimenting the whole stuff to be 3D-Components (XComponent, XContainer ;-) - so you can for example rotate your controls or mix it with other Scenegraph-Nodes (e.g. Shape3D) within a LayoutGroup, which contains a LayoutManager to arrange its children. (Yes, BoxLayout or BorderLayout in 3D!).But currently i have some problems with:- clipping (how to clip e.g. a Shape3D - ClippingBounds?!?)- intersecting (the mouseover should react if the mousepointer is within the bounds, but a boundingsphere is a bad choice for a button)

We too are working on a GUI system for our application. What we've done is made a hierarchy of Shape3D's, under a FG node with a scaling matrix that translates 3D FG coords into the exact matching 2D screen pixels, and vice versa. The different widget flavors (Buttons, Text, etc) are responsive to our application's custom event notification of cursor positioning, but naturally that's assuming the widget is flat-on to the camera, etc.

We had a real problem with the Text and clipping. We determined that due to UV floating, the only way a Text texture map would render correctly was if the texture AND the Shape3D was a power-of-2 size. However, that left a dilemma about how to clip the text when the window itself wasn't a power-of-2 sized. We ended up discovering the Graphics2D.setClip() function... now we create power-of-2 sized textures and quads, but call Graphics2D.setClip() with the actual window size, such that the text drawn onto the texture doesn't go outside of the bounds of the actual window. The rest of the texture is filled in with a 100% transparent color, and nobody ever knows...

The System window can be moved and resized correctly. The buttons work correctly. The Text windows can be dynamically modified during runtime, and they can be resized correctly. The red box indicates the actual size of the Shape3D and texture on the bottom window, although the drawing of the text onto the texture is clipped to within the widget boundary. If the text widget is resized to the point of needing a different power-of-2 size, it automatically recreates the texture/quad.

The hierarchy for this example looks like this. Note that "quads" are Shape3Ds, while "widgets" are our own custom objects that extend BranchGroup (thereby containing quads or more widgets):

Note that isn't a Swing window. It's a stack of Shape3Ds that's simply designed to look like one.

We don't use layout managers at all. We define the top, bottom, left, and right of each widget as being measured from the parent top/left, parent bottom/right, as a distance from the parent middle (vertical or horizonal), or as a position/size combo. It makes for a radically cleaner and more predictable design, avoids the headache of layout manager implementation and usage, and does everything we need to do.

but theres one thing that bugs me: if the mouse is above these dialogs the speed decreases extremely. (it looks still ok, but this thingi thats rotating there gets pretty slow)(im running the one from run.cmd)i don't think, that a framerate decrease in this rate would be too good

I got a very simple way of drawing swing above the Canvas3D. It only has one little take back: you cannot have transparent or semi transparent ui. I just simply use a JLayeredPane and add to the parts where I want to have my UI java.awt.Panels, which draw above the Canvas3D. To these Panels I can then add normal Swing-Components.

Arne

* I don't know any reason why this should decrease the framerate in any way.

well i starting looking into this as noted here. and foundthat i soon started making 3d objects and texturingthem as others have here. then using Picking for clickevents. this is not so cool because its just not good forany complex controls (popups, drag and drop). it getsvery messy. but it was worth a try. real downer is textinput- u need to add text highlighting when selectingwords, along with copy and paste. if u need all that sortof controls then you end up making a 3d awt. this is finejust takes time. layout managers of X, Y and Z is also atop thing we can do in xith so i'm looking at that also.skinning is a must have. i dont think eveyone wouldwant the same look and feel for there buttons as me Davids was very cool when he posted the code for thegame he was making- maybe we should look at that.wonder if he would mind if we ported it into xith thesedays?

oh to note- thats why im looking into making a newfile loader. you can then name the objects with thereactioncommands . maybe also a wast of time but onehas to keep trying and learning the hard way i guess

I don't think copy/paste is that important at the moment. What is really needed though are just text fields that can accept user info, text boxes that can store chat conversation with a transparent background, etc.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org