Getting FengGUI run with Xith

[Schabby]

Hi guys,

I am currently trying to make FengGUI render on top of Xith which is what we talked about a while ago. I grabbed the HelloXith3D example and mangled it such that it calls FengGUIs render routine after Xith finishes traversing and rendering its scene graph… Well that’s the plan at least. I have elementary questions that hinder me at the moment to fulfil that plan

From what I can tell without having digged in the Xith code too deeply is that it uses JOGL per default (right?). In order to instantiate FengGUI, I need to get the javax.media.opengl.GL instance from somehwere. Where can I get it? I checked RenderPeerImpl, CanvasPeer and Canvas3D before I came to the conclusion that it is probably smarter to ask you guys.

Thx,

Johannes

PS: btw, me managed to get FengGUI run together with jME. Check out here: http://www.jmonkeyengine.com/wiki/doku.php?id=integrating_fenggui_with_jme

[bohdan]

Well, I’m not 100% sure, that this is the answer on your question but you can get GL instance in CanvasPeerImpl… getGL() method, for example, or you can probably dig in to CanvasPeerImpl.display(GLAutoDrawable drawable)…

[Qudus]

Try something like this:

GL gl = ((CanvasPeerImpl)(myCanvas3D.get3DPeer())).getGL()

Marvin

PS: What’s this HelloXith3D class you’re talking about?

[eMKa]

@Schabby : 2 questions before answering to yours :

• Does FengGUI support both LWJGL and JOGL JSR-231 ? (IIRC you had an abstraction layer… please detail how it works)
• Could we provide you a generic GL with basic OpenGL functions which semlessly calls real ones (JOGLJSR-231 or LWJGL, depending on the OpenGL layer choosed by the dev)

[Qudus]

@Amos Wenger

Could we provide you a generic GL with basic OpenGL functions which semlessly calls real ones (JOGLJSR-231 or LWJGL, depending on the OpenGL layer choosed by the dev)

I stormed my brain a lot about that. It would be quite handy and we could simplify the Renderer abstraction very much. But… On the other hand, this would mean one more method call for each single OpenGL call. This will certainly be very slow :’(. So I really think this can’t be done efficiently.

Marvin

[cylab]

Would it not be cleaner to create an own FengGui node type for the scenegraph and implement RenderAtomPeers for it? Ultimately it would be nice to use a FenGUI as arbitrary Shape, so you can create computer terminals with a GUI in a game.

@Marvin Fröhlich

@Amos Wenger

Could we provide you a generic GL with basic OpenGL functions which semlessly calls real ones (JOGLJSR-231 or LWJGL, depending on the OpenGL layer choosed by the dev)

I stormed my brain a lot about that. It would be quite handy and we could simplify the Renderer abstraction very much. But… On the other hand, this would mean one more method call for each single OpenGL call. This will certainly be very slow :’(. So I really think this can’t be done efficiently.

I don’t think the overhead would be much, since most performance critical work should be done by the GFX-Card anyway (DLs, VBOs, Shader etc.).

The JSR itself defines an abstract wrapper around the GL functionality, so you could even create a LWJGL binding with an JSR interface (croft did something similar afaik with the jGL software renderer)

[Qudus]

@cylab

Would it not be cleaner to create an own FengGui node type for the scenegraph and implement RenderAtomPeers for it? Ultimately it would be nice to use a FenGUI as arbitrary Shape, so you can create computer terminals with a GUI in a game.

This won’t be totally possible. FengGUI and HUD both depend on a plane, which is normal to the view direction. Well, as far as clipping of containers and picking are concerned.

@cylab

I don’t think the overhead would be much, since most performance critical work should be done by the GFX-Card anyway (DLs, VBOs, Shader etc.).

The JSR itself defines an abstract wrapper around the GL functionality, so you could even create a LWJGL binding with an JSR interface (croft did something similar afaik with the jGL software renderer)

Well, accessing a field directly is faster then accessing it through a getter / setter. Doing it many times in a time critical place (like the rendering code) will certainly make the whole thing a lot slower. So this might be resonable for a GUI, where only a few Nodes are drawn. But for the whole scene, this is not resonable.

Marvin

EDIT: And the performance critical work is not only done by the GFX card, but the prerendering work is also performance critical. It prepares the Shapes and things to be in a format the GFX card can understand. And this is done frame by frame (or could possibly be).

[Schabby]

First of all thanks for the answers!

[quote]Does FengGUI support both LWJGL and JOGL JSR-231 ? (IIRC you had an abstraction layer… please detail how it works)
[/quote]
Yes. FengGUI runs on JOGL as well as on LWJGL. Our “abstraction layer” is quite straight forward: We got an interface IOpenGL that declares the few dozen gl calls we need to render FengGUI. For example beginQuads, end, bindTexture, etc. For each OpenGL binding we got a class that implements this interface, namely OpenGLLWJGL and OpenGLJOGL. It is up to the developer which binding he wants to use because their behaviour is identical of course.

More precisely, you can setup FengGUI by

Display fengguiDisplay= new Display(new JOGLBinding());

or

Display fengguiDisplay= new Display(new LWJGLBinding());

Both bindings instantiate the associated IOpenGL in question which is then used for rendering.

[quote]Could we provide you a generic GL with basic OpenGL functions which semlessly calls real ones (JOGLJSR-231 or LWJGL, depending on the OpenGL layer choosed by the dev)
[/quote]
Hmm, I believe that is not necessary although I appreciate the offer. Since FengGUI will render the widgets completely separated from Xith we do not need to bridge the OpenGL binding between Xith and FengGUI. It is probably enough for both APIs to stick to the same binding (either JOGL or LWJGL). In other words, when you setup Xith with LWJGL, you should use FengGUI with LWJGL as well and vice versa with JOGL.

GL gl = ((CanvasPeerImpl)(myCanvas3D.get3DPeer())).getGL()

I tried this, but the returned gl instance points at null. :’(

[quote]The JSR itself defines an abstract wrapper around the GL functionality, so you could even create a LWJGL binding with an JSR interface (croft did something similar afaik with the jGL software renderer)
[/quote]
Hmm, the thing is that FengGUI combines several gl commands in one method in a few cases. However, having FengGUI in a node in the scene graph would be pretty cool. But maybe we should first try to render FengGUI simply after Xith. (like we successfully do with jME)

Johannes

edit: whoops, Marvin was quicker than me

[quote]FengGUI and HUD both depend on a plane, which is normal to the view direction. Well, as far as clipping of containers and picking are concerned.
[/quote]
Yeah, that may turn out to be a problem, but it is possible to overcome I believe. But again, we may want to go for the easy thing first.

[Qudus]

@Schabby

@Marvin Fröhlich

Try something like this:

GL gl = ((CanvasPeerImpl)(myCanvas3D.get3DPeer())).getGL()

I tried this, but the returned gl instance points at null.

Maybe you’ll have to call this after the first frame is rendered.

And again the question: What’s this HelloXith3D class you’re talking about?

Marvin

[Schabby]

Maybe you’ll have to call this after the first frame is rendered.

ah, ok, I will check it out! Thanks

And again the question: What’s this HelloXith3D class you’re talking about?

Dont you guys know your own examples? Just kidding… It’s in org.xith3d.test (I guess it came with the toolkit package) and is written by Jens Lehmann (isnt he a goal keeper of some sort?)
I am happy yo post the code here… but it is pretty long

Johannes

[Qudus]

@Schabby

Dont you guys know your own examples? Just kidding… It’s in org.xith3d.test (I guess it came with the toolkit package) and is written by Jens Lehmann (isnt he a goal keeper of some sort?)
I am happy yo post the code here… but it is pretty long

Well, no it isn’t. Maybe you have a somewhat old CVS snapshot (or an old release). So when you’re trying to port your GUI to Xith3D you should certainly use a recent version.

[Schabby]

That’s peculiar… I downloaded xith3d-0.8.0.tar.gz. Is there a more recent release? After extracting the archive I found the HelloXith3D class in \xith3d\toolkit\src\org\xith3d\test

Johannes

[Qudus]

@Schabby

That’s peculiar… I downloaded xith3d-0.8.0.tar.gz. Is there a more recent release? After extracting the archive I found the HelloXith3D class in \xith3d\toolkit\src\org\xith3d\test

No. There’s no more recent release. But there have been quite huge changes to the CVS tree. Please use a current CVS checkout.

[Schabby]

oh, ok. I will do that

[cylab]

@Marvin Fröhlich

@cylab

Would it not be cleaner to create an own FengGui node type for the scenegraph and implement RenderAtomPeers for it? Ultimately it would be nice to use a FenGUI as arbitrary Shape, so you can create computer terminals with a GUI in a game.

This won’t be totally possible. FengGUI and HUD both depend on a plane, which is normal to the view direction. Well, as far as clipping of containers and picking are concerned.

Hmm… it’s a pity - it just sounds so cute

@Marvin Fröhlich

@cylab

I don’t think the overhead would be much, since most performance critical work should be done by the GFX-Card anyway (DLs, VBOs, Shader etc.).

Well, accessing a field directly is faster then accessing it through a getter / setter. Doing it many times in a time critical place (like the rendering code) will certainly make the whole thing a lot slower. So this might be resonable for a GUI, where only a few Nodes are drawn. But for the whole scene, this is not resonable.

Where do you get that from? Simple getters and setters are inlined by the compiler. Even final, static and private methods can be inlined, see Optimizing Java for Speed for more info.

@Marvin Fröhlich

EDIT: And the performance critical work is not only done by the GFX card, but the prerendering work is also performance critical. It prepares the Shapes and things to be in a format the GFX card can understand. And this is done frame by frame (or could possibly be).

Don’t know how much of the prerendering needs direct OpenGL calls, but as a rule of thumb OpenGL calls (especially state changes) should be reduced as much as possible (using approproate data structures, display lists etc), and since the wrapper would only affect direct opengl calls, there will be only a few places with the delegation overhead (if at all due to inlining). If you set the time needed for e.g. uploading vertices to vram in relation to the overhead of a java method call, this seems like a negligible performance hit…

Anyway, it was not my intention to promote the creation of such a wrapper.

[Qudus]

@cylab

@Marvin Fröhlich

Well, accessing a field directly is faster then accessing it through a getter / setter. Doing it many times in a time critical place (like the rendering code) will certainly make the whole thing a lot slower. So this might be resonable for a GUI, where only a few Nodes are drawn. But for the whole scene, this is not resonable.

Where do you get that from? Simple getters and setters are inlined by the compiler. Even final, static and private methods can be inlined, see Optimizing Java for Speed for more info.

Interesting stuff. I didn’t know. Thanks for the link :).

[cylab]

@Marvin Fröhlich

Interesting stuff. I didn’t know. Thanks for the link :).

You are welcome

[c_lilian]

a rather old link, but some things are still valid…

about inlining : IIRC inlining methods across classes is only available to hotspot server. hotspot client just inlines methods in the same class.

but I’m not 100% sure : may be gettters, setters and one line methods are a special case.

Lilian

[cylab]

Thanks for that info. Do you have a link to a more accurate overview of such optimizations? Could be handy.

[c_lilian]

this one’s not bad : http://java.sun.com/developer/community/chat/JavaLive/2005/jl0315.html

Lilian