I haven’t started to code yet, but I’m actually designing the future Xith UI System.
I have a question about performances and I WANT ( ;)) your opinions on that.
Is it better :
Personally, I think it’d be better to resolve the issue of Parrallel/Perspective projection swapping. Then just use the parrallel mode to avoid picking altogether 
Even nicer might be to avoid using the scenegraph for the GUI at all (since its not the best of fits). If the ability to plugin in bits of LWJGL/JOGL code directly to the sccenegraph is made available (see other post) then you could just plugin a GUI module which swapped into glOrtho matrix and drew the GUI.
I think however you design it - using the scenegraph for the GUI is going to lead to a slow(er) implementation.
Kev
Oh, I see.
Thanks for your advice.
But I can design the system, displaying with the scenegraph, and then switch to JOGL/LWJGL code to display faster ?
The whole picking thing is exactly what I did in Java3D, it’s not bad at performance, but it really does suck being in the scene graph. I’ve tried porting my hud and hit a number of issues with picking in xith close to the frontclip plane. Ranging from it picking nothing, to it picking values that make no sence at all. I gave up. You are welcome to the J3D code and the bit of porting I had done if you after, just patch up the picking code and it should automagically work :).
The best way would be to stick the post render glOrtho stuff in
Endolf
Can we avoid using picking by using the Foreground node? That is a feature that is already in Xith3D.
Will.
Yeah, but we’ll need picking then also. The foreground node only makes the objects to be relative to the view, so we’ll still have perspective there. Or am I wrong here?
Arne
couldn’t one use a transform group and some math magic to add a coordinate space too a foreground node where the top/left corner is always 0/0 and the bottom/right 1/1 … or based on the resolution?
guess this would avoid picking too …
just my thinkin’
If you can do that magic
I really think we should do this Parallel/Perspective swapping and then simply rendering it in parallel on top of the perspective stuff, like kev said. Then we can also quarantee, that the positions really have a linear relationship. And we wouldn’t have to do that kind of magic 
Yes, so who is in charge of implementing these special features to Xith (multi-pass rendering…, direct access to underlying API, and so on…) ?
Using foreground node and Transform.ortho method, we might be able to get round it and avoid picking at all
Currently plaing in Java3D with my old hud code. If I get it working, i’ll be able to port it to xith easily (I think).
Endolf
That is correct. It does currently work quite well for hud’s in its present state though.
Will.
Currently no-one, it is just the seed of an idea. This is a large and important feature to Xith3D, I believe the priority should be getting it right the first time.
Will.
Indeed, I too seek this magic forumla. Recently I was creating a top-down game, and I was able to match the coordinates for a 1024x768 ground texture to the screen coordinates by using a FOV of 90 degrees and placing the camera at a Y value of half the texture height (IIRC). I wanted to be able to match the coordinates with an arbituary FOV, but could not find/devise the forumla (as I had it working with FOV-90 though I didn’t worry too much). I am sure this must be possible.
Will.
Isn’t this what Transform3D’s ortho method is for?
(Currently playing to find out)
I’ve seen it used in a tutorial for Agency9’s scene graph.
Endolf
can anyone explain me what how the planes in the view frustum are to be understood?
Frustum f = new Frustum();
view.extractFrustum( f, canvas );
System.out.println( f );
gives me:
Frustum[Left:Plane[A:-0.7187723 B:0.0 C:-0.6952455 D:0.0] Right:Plane[A:0.7187723 B:0.0 C:-0.6952455 D:0.0] Bottom:Plane[A:0.0 B:0.8193296 C:-0.5733228 D:0.0] Top:Plane[A:0.0 B:-0.8193296 C:-0.5733228 D:0.0] Far:Plane[A:0.0 B:0.0 C:1.0 D:1999.9532] Near:Plane[A:0.0 B:0.0 C:-1.0 D:-1.0]]
those are the planes of the view frustum … but how can i construct a frustum from these values?
specially the -1.0 nearplane confuses me …
This is maybe a bit OT, but I’ll try to answer it anyways. A moderator can move it later if he thinks this would be necessary.
It returns the Area in which things get rendered. And where they are rendered. The nearplane simply specifies, that things that are too close don’t get rendered.
Arne
it’s not OT as i try to get those ‘magic math’ thingy from this … should be possible … or am i mistaken there?
Ok then I have misunderstood you, sorry :-\
It should be possible. But don’t ask me how
it’s just that i can’t guess how to construct a frustum form those values
the standard values for front and back clipping plane are 1 ( unit from camera if i’m not mistaken ) and 2000
so the backclipping plane is represented by Far:Plane[A:0.0 B:0.0 C:1.0 D:1999.9532] where i find the distance in field D … but what is C:1.0? … and A and B?
nevertheless that could be right … what i can’t understand is the two -1 values in the frontplane …
and how to puzzle the other values into the whole thing is some kind of riddle for me
I don’t know for sure, but it looks like you are facing plane equations of the form ;
Ax + By + Cz + D = 0
Or under another form : N.OM = -D with N the normal of the plane (A,B,C) and OM the vector to your point (x,y,z).
Therefore, your near plane if facing backward along z axis (N = (0,0,-1)) and is placed at z = -1 (D=-1), and your far plane has N=(0,0,1) and is placed at z = 1999.9532.
Hope it helps
Vincent