I'm thinking about migrating from java3d to JME. My application is not a game but a scientific visualization tool. Before I consider to migrate I would like somebody to answer these questions:
Lightweight, no. Heavyweight, yes.
The reason is that if done as a lightweight component, the framebuffer data will have to be copied to CPU, drawn on a panel, then sent to GPU again. This process is utterly slow (gpu feedback) and will become slower in the future with technologies such as SLI becoming widespread. There are some posts on the forum that help with integrating the heavyweight canvas with other swing components.
dhdd said:
darwinjob said:
IMHO java3d is dying. The only thing which is unique in j3d is stereovision support.
A more advanced stereo pass can be found here:
http://code.google.com/p/radakan/source/browse/trunk/JMEContext/src/com/gibbon/jme/pass/StereoRenderPass.java
which supports asymmetric frustum and OGL stereo buffers.
So? JOGL was designed for general purpose applications, so it attempts to work as stable as possible, even when a large performance penalty can occur, while jME was designed for fast 3D graphics (mostly for games), so it does not concern itself with slow approaches to various issues.
Like I said, some of the issues of heavyweight components can be lifted with some tweaking to swing/awt. I have been using the jME heavyweight canvas and I do not have any issues with it.
JOGL was designed for general purpose applications, so it attempts to work as stable as possible, even when a large performance penalty can occur, while jME was designed for fast 3D graphics (mostly for games), so it does not concern itself with slow approaches to various issues.
Does this mean that jme is not able to handle large performance penalties?
Momoko_Fan said:
some of the issues of heavyweight components can be lifted with some tweaking to swing/awt. I have been using the jME heavyweight canvas and I do not have any issues with it.
Could you tell me please how I can tweak JInternalFrames?
If you are truly worried about performance of some high-level component, you can always rewrite that piece of code (and contribute back ;)) yourself… jME uses mainly LWJGL for all GL calls, so it can perform as good as necessary (and as good as JOGL too)… And there is a JOGL port attempt somewhere in the forums too.
Does this mean that jme is not able to handle large performance penalties?
That's not what I said. What I mean is that if the developers of jME are faced with a decision to either use a fast approach or a slower but slightly more stable approach, then the fast approach will be used.
If you are truly worried about performance of some high-level component, you can always rewrite that piece of code (and contribute back wink) yourself...
Performance is not the problem.. the problem is that the LWJGL canvas is a heavyweight component which means it will draw over the UI when it's in a JInternalFrame
And there is a JOGL port attempt somewhere in the forums too.
JOGL is available in the latest jME2 from SVN as an official rendering library binding. Though I am not sure if it returns the lightweight version of the canvas or not.
Could you tell me please how I can tweak JInternalFrames?
Doesn't really seem like it's possible (yet). JRE7 will be able to support heavyweight components inside JInternalFrames, see this thread:
http://forums.java.net/jive/thread.jspa?threadID=29175&tstart=0
Meanwhile, you can use SWT which has better support for heavyweight components, or if you don't mind the performance loss you can implement a lightweight canvas component. There's an OffscreenRenderer class here:
http://jmonkeyengine.com/wiki/doku.php?id=offscreen_renderer
You can use the getImageData() to retrieve the framebuffer and then paint it on a JPanel or whatever.
