ok where are we with this?
i was planing to start looking into it monday- so just
asking for a heads up :)… Will you have made a
forground and background node- is that cool for adding
ui components to? i also take it we dont want to use
Swing or AWT? whats everyones thoughts on this?
xith3d needs ui components badly in my opinion… or did
someone get all this rocking and i missed a build?
think its still hanging…I wasn’t sure the existing UI stuff was all that bad until my UI based buttons started following my mouse around …yikes!!!
If you are going to approach this I would spend a day or two gathering ideas/wants/etc. For me I would need
think its still hanging…I wasn’t sure the existing UI stuff was all that bad until my UI based buttons started following my mouse around …yikes!!!
If you are going to approach this I would spend a day or two gathering ideas/wants/etc. For me I would need
0 some kinda HUD
0 a display panel that I could dump text/images too
o working button,
by working they could be a pickable beastie with some kinda of callback mechanism or whatever. I am getting into all kindas of problems with AWT and or Swing gui events occuring async to my rendering loop.
While I can’t help with dev I would be willing to integrate alpha releases into my game and test.
Soory for the double post…actually dropped coffee cup on my 'puter…what a morning
Hi there, my other thread about the graphics context painting into a textures image aims at the same goal.
I have written a small UI based on simple drawing primitives. So I can use this by simply painting it to textures. It has some nice features like a text renderer which can include animated images (icons) using escape sequences and so on. Of course all components are interactive. Unfortunately it is very personal cough undocumented cough code but I have some experience in writing a UI from scratch.
I think what everyone will need is
a type of paintable hud and mouse pointing on this hud (e.g. returning a position on the hud).
PS: A UI from scratch can be very complex once you go beyond just a few buttons. Soon one will run into problems like coding a simple scroll pane or some basic layout managers.
Ca$cade
[quote]by working they could be a pickable beastie with some kinda of callback mechanism or whatever. I am getting into all kindas of problems with AWT and or Swing gui events occuring async to my rendering loop.
[/quote]
Slightly off topic but I have solved this problem (async input events) for my game and am willing to share the solution - interested?
Will.
The com.xith3d.userinterface package should be considered unmaintained and highly experimental. I avoid it for this reason plus I don’t like the large dependancy on Swing.
Xith3D HUD support is a step in the right direction but I totally agree, we need some kind of UI badly.
I think any sort of UI should be built using the Foreground node, be uncoupled from the rest of the API, and not depend on the AWT or Swing libraries, nor need to use OpenGL picking.
There is a text2d solution already which uses AWT here: http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=xith3d;action=display;num=1084652728;start=7#7
(and https://xith-tk.dev.java.net/servlets/ProjectDocumentList?folderID=1341&expandFolder=1341&folderID=0)
For superior compatibility across all operating environments and with all renderers such as LWJGL, a solution not dependant on AWT is needed. Some sort of OpenGl based Xith3D widget toolkit (XWT?).
Alien Flux has a great UI setup and I believe Cas has open sourced it. Perhaps we could port it to Xith3D as a starting point?
Another option - does a light weight alternative to the AWT Graphics object exist that we could use to draw strings and shapes? Perhaps we should ask in the 2D forum.
Will.
I would not limit it completely to the foreground node. Imagine you would want a UI as an ingame part. A player pressing some buttons mounted on some object in the game world.
I would not just rule this possibility out by default.
What do you mean by AWT independence ? If you go down to drawing primitives below the AWT graphics context then you will end up drawing your own lines, polygons, do the filling, read and render fonts etc.
[quote]think its still hanging…I wasn’t sure the existing UI stuff was all that bad until my UI based buttons started following my mouse around …yikes!!!
[/quote]
That’s actually a feature. ;D If you click your overlay at its border it will follow your mouse until you click once more. Long time ago I posted in this forum how this can be disabled. Nevertheless the userinterface package has serious drawbacks (event handling, artefacts in text display, …).
[quote]Soory for the double post…actually dropped coffee cup on my 'puter…what a morning
[/quote]
There’s a delete button for your own posts. 
I would assume any 3D buttons in the scene would use picking and any clickables would need to be Foreground node only. Who would want a text input box on a 45 degree angle? Text could be applied to any type of node however.
AWT seperation is important otherwise the Xith3D/LWJGL users lose many benifits of using LWJGL. This also reduces the portability of the platform. I’m not suggesting we code that library but maybe find some light weight low level drawing library.
Alien Flux has a rich GUI without needing AWT.
Will.
with ingame UI I meant the possibility of having something like a virtual screen based control panel of a machine that can be used by the player. In other words the high-tech version of the dungeon lever.
For example: I coded a small app in C for openGL where you can have live camera feed on a texture. Applying this to a tv-shaped model you have a working tv in your game.
The only work on a 2d library of java I know of is this port of java2d to OpenGL. But this is most probably not lightweight.
we are chatting about Buttons and Popup windows
on an overlay here write? just to keep on topic 
i am looking at the uiwindow stuff at the moment.
also seems the events etc need abstracting so they
dont update the worlds events. click a button and
the orbiting camera doesnt spin around.
popup and scollpanes seem to be a tricky area- who
gets focus and all that. nock nock
who’s there?
doctor
Hi!
I’ve started an UI as part of a Java3D Project. The whole UI stuff is rendered into a BufferedImage and then put onto the scene as overlay.
In Java3D i used the getGraphics2D() method, which is really slow for only doing a drawAndFlushImage(…).
The advantage is the portability, so i’m trying to use it with Xith3D, but the UIWindowManager in combination with UIOverlay (extended to implement UIOverlayInterface) is slower than Java3D and i think it’s far from the optimal way. So i would be happy about some help, how to get a BufferedImage (or s.th. with Graphics2D for painting) as fast as possible to the ViewPlate. (What about the Frontend-Node, anybody any coding examples?)
I’ve ported the Swing-BoxLayout and the UI contains basic controls like Button, Label, TextField, RadioButton, Checkbox, PasswordField. The baseclass is a container, so you can build complex dialogs (using BoxLayout). You can use various styles for mouseover, border.
Scrolling was implemented but due to redesign currently doesn’t work anymore… i’m more the network-guy than GUI-expert.
Like BoxLayout any other Swing-/AWT-LayoutManager should be possible to port…
The whole stuff uses a separate Eventhandling which has an abstraction layer, so e.g. you can map Keyboard-buttons for moving the (virtual) Mouse or use the Joystick-Buttons to enter text in a text-field.
Maybe someone interested…
Cioa,
hasait
Example code for Foreground node:
BranchGroup aimGraphBG = new BranchGroup();
aimGraphBG.addChild(myHUDQuadShape);
Foreground aimGraphForeground = new Foreground(aimGraphBG, View.VIEW_FIXED);
scene.addChild(aimGraphForeground);
VIEW_FIXED means it doesn’t matter where your camera is, it will always be rendered in the same place. Foreground can take any type of geometry - not just flat quads incidently, although they are commonly used for HUDs.
Your project sounds interesting. Definitally see if you can get it to work with the Foreground node instead of the userinterface package. Hopefully you will see a large speed increase.
Will.
I’m highly interested. I was starting to work on porting our own in-house GUI system to texture -> Foreground, but I’m currently hung on coming up with a way to guarantee a quad drawn in a Foreground node exactly matches the screen size down to the pixel. I was going to make a tiled texture system, because the float UV is too coarse to work with a single screen-sized texture with per-pixel accuracy, but I was getting stumped with screen coords -> Foreground coords conversion.
What I was planning on doing was casting screen coords to Foreground coords at a distance of -0.5f, which would be the GUI plate. Then doing 32x32 screen-pixel tiles, which doing the same pickray would give me what size quads to put on the GUI plate, with individual 32x32 textures. Then just a matter of wrapping a single Graphics interface around the tile mosaic, so that it appears as a singular drawing surface. I figure the smaller the tiles, the better update resolution when only a small region is dirtied.
If somebody could give me a hint on screen coords -> Foreground coords, I could churn all that out. Would give him a singular drawing surface that covers the entire screen, but with per-pixel accuracy.
Slightly off topic but I have solved this problem (async input events) for my game and am willing to share the solution - interested?
Will.
very
That's actually a feature. Grin If you click your overlay at its border it will follow your mouse until you click once more.
I clicked that puppy to oblivion without affect…
with ingame UI I meant the possibility of having something like a virtual screen based control panel of a machine that can be used by the player. In other words the high-tech version of the dungeon lever.
exactly where I am cascade, I am basically trying to do the Murder Mystery in a Mansion thing and lever, button, switched etc will be needed
I would assume any 3D buttons in the scene would use picking and any clickables would need to be Foreground node only. Who would want a text input box on a 45 degree angle? Text could be applied to any type of node however.
/code]
William, this is how I currently do it, but It is substantially easier to do some thing with a button set, with callbacks, than writing a scenegraph addon. . In my game a player needs to solve various puzzles. For example suppose the user needs to solve a puzzle, consisting of three buttons with associated colored labels. Press a button and the label randomly changes color, get all three colors correct win a prize. I banged that out as a Jwindow beastie using NetBeans GUI editor in 3 mins. Unfortunately I would prefer to have the controls for the game in the scene tilted and rotated however the user moves a mouse.
Maybe someone interested…
Cioa,
hasait
sounds interesting..tell us more
Final Note: I like williams foreground work, a foreground HUD with nice artwork can make a game, it is a necessary piece of Xith. I would also want embeded, in the scene UI components that had some knid of event handling callback mechanism in it. Having a mechanism, affected by lighting that reacts to mouse/ket presses would be way cool.Here then is an article I have written for you (and others who are interested) about the approach I took:
http://tankammo.com/article/eventpoll
I see.
I’m not sure if this would belong in a UI library. Perhaps you could petition to have some callback feature added to the current picking code? I don’t use picking myself so I am just stabbing in the dark, but my understanding is that it is the best method for detecting clicks on 3D objects in the scene.
Thank you :). I’m sure there is a good solution to your problem but I’m not convinced it is a UI package.
Cheers,
Will.
3AM in the morning!!! I hope your in a different time zone and not at work…youch.
I agree, I was thinking UI in terms of swing/AWT pieces/parts, so…
With a Foreground UI, painting a set of pickable Nodes I would have most likely some underlying image/texture to border my game or act as a HUD.
o Since full screen is not in 2^n dimensions how should/would I size a base texture???
o Would the Foreground texture obscure/mask non-foreground pickable shapes that where not visible due to the “background texture” of the Foreground node? Imagine a game border, say an inch in screen width, with embedded pickable-node-buttons, I would want nodes in the game scene graph to be non-pickable if the node was completed obscured. Does this make sense. I modify the mouse cursur based on what it is over and would not want the user to see mouse indications of an object when what is painted on the foreground of the screen is just some pretty texture
o Even a simple UI should have
- some kind of progress bar (power, life, bullets etc.
- dynamic areas (efficiently updatable) for dialogd etc.
I’ve a problem with the Foreground:
I’m rendering my UI to a single textured Quad (i put this into a util class ImageOverlay). My SG looks like: VU-BG-Foreground-BG-Shape3D-Quad-Texture. The screen stays black???
Ok because i’m in a hurry with this UI, i temporarly used the UiWindowManager - this means my ImageOverlay implements UiOverlayInterface and returns the Shape3D in the getRoot() and it works (Canvas3D-UIWinMan-Shape3D-Quad-Texture).
What’s wrong? Why is UiWindowManager working and Foreground not? Do i need to add any transformations? Or use a different version of Xith3D - i use 2004-09-18?
The good thing is, that it is faster compared with the provided UIWindow…
Downloadable at:
http://user.cs.tu-berlin.de/~clain/stuff/ImageOverlay.java
and
http://user.cs.tu-berlin.de/~clain/stuff/ImageOverlayForeground.java
P.S.: hah… i ported Swing-BorderLayout to the UI 