Reading some old posts about OffScreen rendering I found one I wrote some time ago.
MikOfClassX said:
(not like this: http://www.sisco78dvd.com/store/images/galleria/200603300010100.sleepyhollow_horsemanboxed_photo_01_dl.jpg :) )
haha, nice
Yes, make a patch. I don't think many people use jME headless, but any improvements are welcome. Have you tried the alternative approach mentioned in that same thread?
The patch should go to the contribution depot right ?
Headless is the way we'll use JME 2.x. My aim is to base our new broadcast graphics engine on jme so I'm evaluating the many aspects involved in the implementation. Nothing to do with gaming as you can see. I'm quite confident that jme is not only good for games.
My next step is to concentrate on threading issues, speedy update of the scenegraph, dynamic texture updates, quick reading pixels from buffers.
Cheers,
Mik
Just 2 questions:
Q1:
Taking a look at the JOGLDisplaySystem implementation I see something like:
@Override
public void createHeadlessWindow(int w, int h, int bpp) {
// TODOX Auto-generated method stub
}
This means that the JOGL headless path is no-op.
So, why keep an "almost implemented" JOGL code path instead of going on full steam with LWJGL alone ?
Q2:
I'm going to implement and contribute a true context sharing for JME2.x, LWJGL path. No incompatible API changes.
The api would look like this:
DysplaySystem.setSharedContext(Object sharedContext);
the Object sharedContext will point to a Drawable for the LWJGL path and probably to a GLDrawable for the JOGL path (not going to implement the JOGL path, help needed here from JOGL freaks).
The functioning is quite simple: create your sharedContext and pass it to setSharedContext() at the very start of your code. Sadly I have to use Object instead of a "context" type because of different context implementations between LWJGL and JOGL. At least one cast will be required in the setSharedContext() method.
For the LWJGL path the sharedContext init would be a simple 1x1 PBuffer.
The implementation of an external shared context support comes from the need/possibility to integrate JME with other APIs that want to share their GL context with JME itself.
Ready, waiting for a green light to proceed.
Mik
It seems I keep replying to myself…
Ok, the status of my implementation is the following:
the DysplaySystem.setSharedContext(Object sharedContext); for externallly-supplied shared context is up and running for the LWJGL code path. Really no scratch 
For the multiple context support in JME I decided to write my own Renderer and DisplaySystem by inheriting from the LWJGLDisplaySystem. It works. I'm able to create and switch many renderers with different views of the same scene. The solution is really customized to my needs so it will not be public, but I can contribute the context sharing code.
Cheers.
Uhm, why write your own implementation of context sharing and multiple context support if its already written?
http://code.google.com/p/radakan/source/browse/trunk#trunk/JMEContext/src/com/gibbon/jme/context
Many thanks for the pointer Momoko.
Basically I have to render JME scenes into my previously-created GL contexts. The aim is to maximize performance and minimize memory impact, so I would opt to not use intermediate textures and/or PBuffers. Also, I need to share one main context so I'm able to grab pixels from buffers at any time. This is one of my needs.
My current implementation is working quite well at the moment. JME does not suspect/complain that it's writing to my FBOs instead of a canvas or a display.
Today I hope I'll be able to put in place a render-to-texture mechanism in my DisplaySystem implementation so it would be easy to run a number of JME samples without changing a line.
I am not sure I am understanding this well… but I thought that Headless mode was supossed to use a DummyDisplaySystem, and not depend on any graphic library…
What you suggest seems to depend on LWJGL…
:?
AFAIK the DummyDisplaySystem is so dummy that it does not rely on … nothing concrete.
I'm inheriting from LWJGLDisplaySystem just because it works… 
Mik
Ok, I mixed headless mode with the DisplaySystem used. Sorry.
I'm giving a deeper look at the Momoko_fan code and maybe I'll adopt some of it as lately I've encoutered some problems when changing the current renderer with .setRenderer().
The scenario is the following: two headless renderers, two different rootNodes, two contexts.
Basically to see my scene rendered correctly I have this code sequence:
rootNode.lock();
renderer.draw(rootNode);
renderer.draw(rootNode);
renderer.displayBackBuffer();
rootNode.unlock();
so, I have to render twice in order to see something correct. one draw() call alone does nothing. Only so looks like that the first draw() call prepares things for the second call. A bit crazy.
I have no idea why, at the moment.
At last I’ve succeeded in creating my JME headless, shared-context renderer. I didn’t use Momoko_fan code as it did not support FBOs. I’ve created my own DisplaySystem, so the JME source will remain intact.
To make it work I had to issue the following:
rootNode.setRenderQueueMode(Renderer.QUEUE_TRANSPARENT);
Here’s a pic of the test application: 
In this case I have 2 different (rotating) spatials in 2 renderers going to 2 different FBOs.
The FBOs are then used as texures, 2D transformed and drawn into a third FBO which is grabbed and put in one JFrame.
The CPU is very low. Very positive.