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.

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)....

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.

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.

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)

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.

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).

Does FengGUI support both LWJGL and JOGL JSR-231 ? (IIRC you had an abstraction layer.. please detail how it works)

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

1

DisplayfengguiDisplay= newDisplay(newJOGLBinding());

or

1

DisplayfengguiDisplay= newDisplay(newLWJGLBinding());

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)

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)

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.

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.

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

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.

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.

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.

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.

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.

I rather should concentrate on the terrain thing first... I must admin that I both over- (regarding lod) and underestimated (regarding complexity) the existing terrain code, so there is enough work for me there

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org