Xith3D HUD support?

Engines, Libraries and Tools Xith3D Forums
#1

Has anyone had luck implementing a good clean HUD in Xith3D?

I’ve looked at the Billboard options and I’m not convinced there isn’t a better way. I don’t want to use the UI package for this as Swing adds a lot of overhead just for displaying a few images.

I would like a Node which keeps the geometry always infront of the view automatically (and importantly that honours alpha transparancy and blending).

Would I be correct in implementing this in the Foreground node? It doesn’t seem to do much at the moment.

I would probably use a similar technique to the background node to keep the camera locked to the objects, but unlike with the background node where the camera would rotate depending on the view, with the Foreground it would not.

These are just my initial thoughts - any comments? I will hopefuly be implementing this soon.

Cheers,

Will.

#2

Why not use a varient of the XithGui test example ???

I have several dialog windows, button etc painted to fixed positions of the window independent of view rotation

#3

The XithGui test (what I dubbed “UI package”) a.k.a. com.xith3d.userinterface is a great package, don’t get me wrong but there are some issues in using it for HUD’s.

Advantages:

[*] It uses Swing, so adding widgets is now very easy. Clickable buttons for example are simple, as are text boxes, scrollable windows, tabbed panes etc.

Disadvantages:

[] It uses Swing so you add a dependancy and some operating overhead. If you use Swing stuff then this isn’t a problem - you are saving a lot of development time, but if you just want an image on the screen this is a lot of needless overhead.
[] It’s 2D. While you can pre-render the HUD images to give a 3D looking HUD, it’s not true 3D. Eg. what if I want a cool movable 3D switch or steering wheel?

This is my reasoning.

I’m going to go code in this support as I think it will be useful for HUD’s and other uses.

Will.

#4

Yes, we need a clean and very simple to use HUD system in Xith3d.
The UI one is another topic, like Will said. Way too complex for some simple 2d textures.
However I’ve no idea which would be the best way to implement.

From a user’s point of view, there could be a switch to say “HUD mode on” (in other API’s you switch the renderer) and then you directly let plot your textures to screen coordinates.

#5

Ok, I have beefed up the Forground node functionality considerably.

I had to keep the “normal” view support as it turns out the com.xith3d.scenegraph package was using it (and now I think about it there may be some other use-cases which need it). By “normal”, I mean the geometry is rendered like it normally is as if it wasn’t a Foreground node at all, the only difference being that it is rendered last.

I added in “fixed” view support where the view is set to the origin to render the geometry (thus the geometry will always be in the same place) - this is commonly used for HUDs and this is what I needed. I decided to add in “fixed-position” support as well. This is exactly like how the background works, but as a foreground. I figured someone may need this for special application where the user could look around their HUD.

For completness, I added in “fixed” and “normal” view support to background node as well.

If you want to see how it’s done, look at the “display” and “setGLViewMatrix” methods of CanvasPeerImpl.

However, I had to make some alterations so that different nodes would be rendered in the correct view (it is possible to have FIXED and FIXED_POSITION foreground geometry). There were a few different ways of doing this, but to keep the overhead down I decided to simply create a special foreground renderBin just for the FIXED geometry and a second one for the FIXED_POSITION. This way, the view is set, the atoms are rendered and then the view is returned to normal. If an application doesn’t have any such atoms, then it should be absolutealy no different than before (except for maybe an extra boolean comparison).

Example of a very primitive HUD - just a single textured cube. As transparency adds some overhead in Xith3d it is probably better not to have one big quad with a transparent window like this.

To use is quite simple:
just call:

Foreground f = new Foreground(quad, View.VIEW_FIXED);

Where “quad” is your BranchGroup geometry and is added to your scene. Unless you are using transparency, it’s probably a good idea to disable the depth buffer so the foreground is always drawn on top.

Support in the LWJGL renderer was also added.

Enjoy,

Will.

#6

[quote]Yes, we need a clean and very simple to use HUD system in Xith3d.
The UI one is another topic, like Will said. Way too complex for some simple 2d textures.
However I’ve no idea which would be the best way to implement.

From a user’s point of view, there could be a switch to say “HUD mode on” (in other API’s you switch the renderer) and then you directly let plot your textures to screen coordinates.
[/quote]
The re-implementation of Foreground should be able to do exactly that ;D

It’s still geometry, so you’re not painting directly to the screen, but that geometry (if you use View.VIEW_FIXED) will always be rendered in exactly the same spot (with no jitter). A bit like making a Billboard that follows the View around - but MUCH more efficient CPU wise (basically two calls to OpenGL to get the VIEW_FIXED affect rather than lots of matrix multiplications to move the Billboard into position and keep it rotated correctly). I’m not saying Billboards are bad, there are just better ways of doing a HUD.

Basically what you do is create a single Shape3d quad which you position just infront of the origin (e.g. at a depth of -2.5f). Then plonk your texture on that quad and your done. When it renders - the camera will briefly move back to the origin to render your HUD (this is where those two OpenGL calls come in) then move back to where it actually is in the scene).

The nice thing about this is you don’t have to have a single quad - you can have a 3D animated HUD if you wish. You can also have a funky radar/map using little quads or tiny models to represent the targets.

Will.

#7

[quote]The XithGui test (what I dubbed “UI package”) a.k.a. com.xith3d.userinterface is a great package, don’t get me wrong but there are some issues in using it for HUD’s.
[/quote]
The UI package single-handedly reduced survivor’s frame rate by a large factor. It also randomly chops off the edges of swing components (looks like the clipping is broken non-deterministically).

Kev’s the expert on these problems, but I looked through the code and it’s so simple it’s hard to see how you could describe the UI systme as anything other than “broken for any real usage”. It’s fine for toy examples - like a single FPS counter - but just can’t cut it for even moderatly complex HUD’s :(.

#8

Ironic that displaying the frame rate reduce it substantially :-/

I think it’s a great concept and I was very impressed with the magicosm screen shot of it in use. I have not used it much myself beyond some testing.

It would be great to have the issues you and Kev found documented (prefrably in IssueZilla) if they arn’t already.

Will.

#9

AFAICS, the UI stuff is probably going to be rewritten almost from scratch at some point, seeing as no-one currently understands it, and it appears to have strange bugs.

It should be a very valuable feature, but until it’s perfect it’s almost useless in practice - I’d rather slave over creating a node-based 3D HUD from scrath that works than quickly whip up a swing GUI that doesn’t. I think that in general people prefer to learn a new skill than spend the same amount of time trying to work around someone else’s bugs to make the stuff created with their existing skill work the way it should.

So…all power to the 3D HUD! We’d already ended up deciding to go with a 3D HUD of some kind for survivor-2, but this will just make that considerably easier, I think :).

#10

I’ve added a simple demo and made a new snapshot.

Run the Xith3DBackgroundGeomTest demo - it now has a Foreground (VIEW_FIXED mode) as well. Press the ‘q’ and ‘a’ buttons to move the view. It’s a very basic demo, but hopefully shows how it works. The foreground geometry is just a quad - but it can be anything.

Will.

#11

Thanks a lot for your effort dennis :smiley:

perhaps the people in need for a hud can cooperate to get some general basic hud components up and running that can be (perhaps easily) incorporated into games.

components like crosshairs, radar (2d/3d), some simple video screen (like the com window in wing commander), a very simple console for text output, gauges.

It will take me still a couple of months to get to the point where I need a hud but I will be happy to share components.

#12

I have an application that requires switching between multiple Background nodes. After switching to the 9-13-04 Xith3D build, I am noticing that Background geometries do not seem to disappear when I detach the Background node or call setGeometry with a new geometry. Any ideas? :slight_smile:

#13

[quote]I have an application that requires switching between multiple Background nodes. After switching to the 9-13-04 Xith3D build, I am noticing that Background geometries do not seem to disappear when I detach the Background node or call setGeometry with a new geometry. Any ideas? :slight_smile:
[/quote]
That was a bug - I noticed it too.

Try the latest CVS, I have fixed this problem. Else, I can release a new community snapshot for you in 12 hours.

Will.

#14

[quote]Thanks a lot for your effort dennis :smiley:

perhaps the people in need for a hud can cooperate to get some general basic hud components up and running that can be (perhaps easily) incorporated into games.

components like crosshairs, radar (2d/3d), some simple video screen (like the com window in wing commander), a very simple console for text output, gauges.

It will take me still a couple of months to get to the point where I need a hud but I will be happy to share components.
[/quote]
Thank you, I appreciate the comments :slight_smile: It’s nice to hear that my efforts are helping other people.

I agree a library of HUD components would be great. Alas, I don’t have a full time artist for my game, so I probably won’t contribute my HUD scribbles :wink:

One important note: The foreground node does not sort transparent nodes currently (unlike with “standard” transparent nodes that Xith sorts before rendering). This means you must add them to the BranchGroup in the order you would like them rendered (an undocumented feature of BranchGroup, it will draw them in the order added - perhaps it is better to use an OrderedGroup so it’s guaranteed??). An easy bug to work around, I just thought I would mention it.

Will.

#15

Background switching seems to be working now. Thanks!

#16

Ok first is the performance penalty real or speculation?? I see from previous posts that it has affected people…but by how much 10% or 8 frames/sec? Is it the actual UI or calculating/writing the data in an FPS window. Does anyone have a feel for this, is it something like??

 No UI at all          = 50 fps
 UI no data           = 40 FPS
 UI with FPS calcs = 10 FPS

I ask because in my case at least one culprit was displaying the # triangle displayed. The call to determine this seemed to account for most of the time penalties.

What would you suggest for a dialog component for example. Currently I am writing text as my game progresses to a dialog based on the xith UI stuff. Is there a better way using a foreground node??

#17

That data is made up right? Just so nobody confuses it with a real benchmark, could you make that more clear?

I’m going to look into Text2D soon. Someone contributed some code a while back, I am going to see how that works with a foreground node.

Personally I am going to avoid UI for the realtime stuff. Also because I want my game to work with Xith3D/LWJGL and the UI stuff uses Swing.

I have added several alpha-transparency foreground nodes to my game for the HUD and the performance loss is negligable (just an observation, no real benchmarks - they will come). Foreground stuff is generally 3D and can be done on the grpahics card. The UI stuff involves 2D drawing which uses the CPU, and then has to be drawn by the graphics card as well.

Will.

#18

the data is not real. I was trying to identify how much of a penalty I would pay using the UI.

I assume what you are doing will have some textual display…how will you implement this?? Grabbing the image out of a texture and writing to it is not particulary efficient either…I guess that is essentially what updates to a Text2D would be.

#19

I am watching this thread and anticipating some good examples of this new setup! Thanks for doing this! I’ve been waiting for a replacement for the UIWindow method for some time now because of all the bugs with it, and noone understands it to fix it.

This sounds great. I assume we’ll be able to use this functionality for buttons and text input and such as well?

#20

[quote]I am watching this thread and anticipating some good examples of this new setup! Thanks for doing this! I’ve been waiting for a replacement for the UIWindow method for some time now because of all the bugs with it, and noone understands it to fix it.

This sounds great. I assume we’ll be able to use this functionality for buttons and text input and such as well?
[/quote]
Potentially. Personally I have not decided on how to handle this for my game. I don’t have any buttons in-game, it’s just the menus and setup that I am worried about. Some opengl based widgits would be nice and would work with Foreground.

Will.