As far as I know there’s only one way until now to perform a pick in xith: a pick that goes through the whole scene. :-/ But, if (as said earlier) we could perform a pick only in a part of the scene (eg only in the foreground node), it would probably save very much time.
Or even better: couldn’t we just convert the edges and stuff from the ui to screen coordinates, because then we never have to convert the mouse pos every time the mouse moves!! 
Arne
[quote]Right, and I don’t think Billboards work with the foreground node, not at least not in my tests with Text2D, I had to convert it to a regular shape3d using quad geometry.
[/quote]
That would be because Billboards and Foregrounds serve mutually exclusive purposes and are not designed to work together.
Will.
I think we can assume a linear relationship. I think that using picking for a 2D UI is overkill.
Will.
Will; indeed its overkill- but thats what the kids want
plus you can aways make a flat branchgroup UI.
we also need ray intersection (an example would help)
so i can look at ‘text’ area highlighting. i’m back on it.
hows the rest of u dudes doing?
Heya!!
ray intersection is what we need, but also with the ability to do it only in a part of the scenegraph (e.g. the foreground node) then it wouldn’t be overkill
too bad i’m not very interested in this kind of ui yet - so i probably wouldn’t do very much else then checking from time to time this forum and speaking my ideas out aloud. 8)
Hopefully anybody works something out, until I’m back at this ui stuff.
arne
What I’d love to see is simple label and input text boxes and basic buttons with nice alpha transparency and using the Foreground node.
Everything else can be build on later. We just something that people can use.
Will.
I’d like to see … ANYTHING! 
I’ve had a game almost ready for at least 6 months now and I haven’t wanted to continue development or show anyone because the UIWindow GUI is all messed up on non windows platforms, etc…
It doesn’t appear that anyone is actively working on a GUI system for Xith.
I know I’ve brought it up in the past and I’ve been told that Xith isnt dead, but it doesnt really seem that anyone is using it for any games. I think I’ll start a subthread labeled that
Would you like to do it? Perhaps the two of us should join forces and come up with something. I was really hoping not to have to but maybe nothing will happen unless we do.
What are your needs?
Currently, all I really need is a text display and input boxes. My game does not have a mouse cursor, so I have no need for a clickable UI (this reduceses the complexity of the UI substantially, but I don’t know what your needs are).
I will be using AWT/Swing for my pre-game dialog’s for now – I can’t see any reason not to until Java makes it onto a console.
I have actually resigned from my day job, effective 11 February 2005. From that date, I am intending to dedicate about half my working week to my game (and related technologies such as Xith3D), and the other half trying to get some $$$. Until then however I am extreemly busy, so I can really only guarantee my efforts after that date (I’ll still try and do a bit before then, but my plate is quite full).
Cheers,
Will.
Is anyone doing anything with this? Has hasait given up?
I am entirely new to this whole discussion, but after reading the threads I’ve found on xith3d ui issues it seems that there are three problems preventing the development of a decent xith3d ui:
UI seems to be the issue facing all the rendering engines that are freely available, and in every case that I’ve looked at it seems to be because of the reasons listed above.
I would be interested in participating in an attempt to construct a UI framework for Xith3D, but I certainly am not inclined to do it alone. Are there any such efforts that would be reasonable for me to join? If not, why don’t those of us who are interested in this issue team up and give it a go? I can’t do it all myself - I lack the expertise and the time - but if I could get some help I’d be interested in trying.
I have not “fixed” the ui stuff currently built into Xith but think I have used if pretty extensively in my game (currently beta). I use quite a bit of the functionality that is descirbed as lacking in thread. Have a look at http://zplax.alistairdickie.com
Semi Transparant buttons that react to MouseOver (see the six buttons at the top). I had to slightly modify UI window manager for this. Essentially these buttons are each UIWindows with a single JButton in them.
Text output to a semi transparent ui window (press c to see the frame rate thing). This is a JText area on a UIWindow.
JLabel output to a semi transpared UI Window (The score and time windows).
2D graphics in a semi tranparant UI Window (the water level window).
A custom component made up of a JTextField two JButtons and a JLabel (see the JSpinner like thing in the game settings window).
Text written onto the graphics object of a BufferedImage (actually a DirectBufferedImage) that is placed as a texture on some geometry (see the banner by pressing b)
-I pop another frame over the top of the main one for my About dialog.
A few tips that I ended up applying.
Don’t get me wrong. I think the UI stuff that currently exists can go a long way. I think when David Yazel made it he was very focused on being able to drag UIWindows around - that is whey they move if you click in the top left 15 pixels or so (I also changed UIWindow to customize or disable this)
Regards,
Alistair
I’m working on a UI system. That’s the reason why I recently implemented render to texture.
The fact is that I need a full 3d UI system. I used to use the Swing integration from David Yazel (which worked perfectly for me) but I had to move to a system that will allow me to have a unique system for UI widgets as well as game objects. Therefore I made a 3D UI system.
It does work but is very preliminary.
For the moment it has the following features ;
It only works with JOGL for the moment. I’m thinking of adapting the base framework to be able to use LWJGL as well.
Anyway, it’s nothing near finished so I don’t expect to release it anytime soon.
I will post a preview when I will have something ready.
By the way, I think that any UI system that we will develop will need an abstract frame system (a bit like OpenProducer of OpenSceneGraph) to abstract the event system and make it single threaded. Has anyone created and released this ?
Vincent
Here is a screen shot showing a Frame (composed from other widgets) with the game board beneath. One of the board square is a bit lighter (next to the duck) ; this is because the mouse is over it. It shows as well 2 text labels (bottom of the screen and title of frame).
I don’t think there is anything inherently wrong with the David’s user interface package, in fact it is a pretty amazing feature (Swing rendered to OpenGL). However, it has had some “bad press” recently. The main problem is that nobody is supporting it.
What we need is someone who has used it extensively, and has looked at the source code and understands what’s going on to take on the maintenance of it. A number of Issues have recently been closed as WONTFIX which can be re-opened. Please raise your hand if you are willing!
Now this UI is pretty heavy, it’s more suited to rich UI’s. For something simple like a framerate indicator a more lightweight solution is needed, but this isn’t to say the two can’t co-exist.
Niwak,
Your screenshot is impressive. Hopefully your UI effort may produce a usable UI API for all to use ;D A great many people will thank you if that happens, myself being one.
Cheers,
Will.
One question I’m thinking about is : Is it REALLY possible to do a true, polished, UI for a game with AWT/Swing ?
Is the skin system extended a lot so that we can do sort of things like Niwak’s screenshot ?
I have just done some memory profiling for my game. I was amazed at the rate that objects are created and destroyed in Xith3D. I seem to be churning through thousands of primitave arrays (of every type) every frame. Not to mention a bunch of other objects to do with rendering. The GC has a lot of work to do.
With the UI stuff turned on things are worse. I am not sure if that is just because there is more stuff to render, or if swing is making it even worse. In any case there is more investigation required.
I think I can answer a few questions on David’s UI Interface stuff. I have spent hours looking at that code and am pretty sure I understand at least the basics.
Regards,
Alistair
On a Swing interface, I guess it’s a trade off between development time, complexity of the UI and frame-rate. If you want to create a very complex UI in a short amout of time, Swing lets you do that, but it has a cost. Have you played Alistair_Dickie’s game? It uses the Swing UI extensivly.
Alistair_Dickie,
Do you want to take charge of the UI code? It’s all yours if you want it. Please contact me by email if you do, and I will get you set up. What we will do is move the package into the xith-tk as an optional package, not tied to the core (thus, no bloat).
Regarding excessive garbage collection, if you identify the wastage and submit a patch, I will commit it in.
Cheers,
Will.
PS. Here are two UI bugs which you can look at if you like. W
Will,
These are both a little harder than they should be.
I am going to do some more work on my program and will do a little on the interface package but will not get to it for a few weeks.
I am currently looking at getting a really nice Text3D shape done. You should see that in the next few days.
Regards,
Alistair
That’s great
If you are interested, you can add Text3D as a package of the Xith3D toolkit, and it will be distributed with every copy of Xith3D downloaded.
Cheers,
Will.
Hi, im new here and want to first tell you all that Xith3D is great and thanks for your fantastic work!
On this thread earlier…
What about making a bit unconventional renderloop like this:
`
BranchGroup mainScenGraph;
BranchGroup foregroundScenGraph;
public void run() {
while(true) {
// render once with the main scene picking disabled
mainScenGraph.setPickable(false);
foregroundScenGraph.setPickable(true);
view.renderOnce();
// do picking to see if the GUI is picked
...
// render once with the main scene picking enabled
mainScenGraph.setPickable(true);
foregroundScenGraph.setPickable(false);
view.renderOnce();
// do your normal game logic checking
...
}
}
`
This should speed things up since if the root of the scene is disabled from picking, the picking will pass over the scene without picking it. Now the picking speed will be determined only by the GUIs complexity and that cant be very huge…
Then after picking for the GUI the states are reversed and normal game logic take place, maybe including picking on the scene triggered by a mouse click etc…
I’ve already written some code, where you can perform a pick on branchgroups directly without this setPickable stuff. (make a search in the forums) It would do the job, too. But I actually favor the way of rendering twice( first the scene and then the gui in PARALLEL_PERSPECTIVE) with jogl this should work and is probably much faster.
That is not completely true http://www-128.ibm.com/developerworks/java/library/j-jtp11253/ explains how the generational garbage collector in the 1.4.x, 1.5.x and even 1.6.x work. There are two main parameters which will greatly improve the application performance and reduce the pause times:
-Xnm8m -XX:SurvivorRatio=6
this will create a young generation of 8 MB minimum size and 6 MB for eden and 2 times 1 MB for the survivor space.
With these parameters I was able to create a Java abased image viewer that did only pause for about 3 ms every few images (1280x768xRGB => 4 MB per image). Without theses parameters the allocation of the BufferedImage alone took 130ms according to Netbeans profiler.
And you have to be very careful with object pools because once you modify an old object (which was promoted to tenured generation) may keep the new object alive until the next major collection - this can cause very long pause times.
The same is true for objects that are larger then the survivor space. But this should not be the case in Xith3D - only textures are this large and are normaly long lived. Otherwise increate the young generation or reduce the SurvivorRatio (like 2 -> e.g. 4 MB eden, 2x 2MB survivor).
I hope this can help to demystify the Java GC a little bit