Xith3D feature question

[DavidYazel]

I got Magicosm's overlays working last night in Xith3D and am trying to decide what sort of overlay support to put in the base scenegraph.  Overlays are really complicated if you want to do them correctly and with good performance, but everyone has different needs.  Rasters do not perform very well and image aligned triangles can perform very fast.  The texture management and power-of-2 restriction on textures makes building overlay's more complicated because you really have to carve up your overlay into pieces.  Our overlay system is working right on top of Xith3D's regular scenegraph, so it can be done without any special support from the scenegraph.  But I know this is a feature everyone wants and I am trying to figure out the base set of capabilities which would be useful.

1) The first thing I thought about was the issue of having to match the view's transform inorder to align the image plate.  There are no other choices in a scenegraph.  But if I added a Node called ScreenAlignedGroup, which is guarenteed that the children can use geometry in the XY plane guarenteed that coordinate 0,0 is in the upper left of the screen and W,H maps to the bottom right most pixel in the screen.  Then the renderer can actually set the view matrix to the identity and push the image plate transform matrix before rendering the geometry.  This has the advantage of removing the jiggle that effects view transformed overlays when the view is > 6000.

2) The next thing I thought about was creating a Foreground leaf, similar to the background leaf except the scenegraph in the Foreground is drawn last, guarenteed, even if there are transparent objects in the sub-scene.  This way you can be absolutely sure that your overlays, hud, etc is always drawn on top of the screen.

3) Another enhancement is to give the programmer finer control on how a transparet object is sorted in relation to ordered groups.  Option 1: render transparent object sorted with all unordered transparent objects.  Option 2: render the transparent object sorted with other transparent objects inside the same ordered group.  

4) Finally an overlay node which you would generally attach under a Foreground Node -> ScreenAlignedGroup -> (Overlay, Overlay, Overlay).  The overlay would act very much like a raster in that you could set its dimensions and location and update its image whenever you wanted (except during rendering of course).  It could either be translucent or opaque.  

I think these tools would be all anyone would need to build a GUI for their game, without dictating to them exactly how they would do it.

Could I get comments?

[endolf]

Hi
 HUD wise it looks good to me, I guess my HUD code is pretty similar in the way it works to the stuff you submitted to j3d.org. The only thing I could *never* get working in properly was a layered hud, If i used an ordered group to redner the hud components back to front then it messed up when the hud got rendered in relation to all the other transparent objects in the scene. with out it the HUD is always at the front but there isn't any layers to the hud. So I guess that would be my bigest request beyond what you have, so you can have a static image that is a dials background for example, and then just redraw a counter in it each time. That and 'any size' components (my hud code did this by returning a section of the texture and adjusting the texture coordinates, to give the illusion of it, that would be enough )

Cheers

Endolf

[DavidYazel]

Thats the exact problem I also had.  These features would completly eliminate that problem since you would be able to flag the transparency attributes to stay within the ordered group, thus you can control overlapping windows, something which has always elluded us in Java3D.

Anyone else want to weigh in?  I will be implementing this in the next 2 days.