Rendering 1 World to 2 FrameBuffers

[Mr.Marbles]

There seems to be a problem with textures when I render the same world into two different FrameBuffers. The textures don't appear on the second rendered frame buffer. Is this a known issue? Here's the code I'm using:

Code Select Expand


frameBufferA.clear();
world.renderScene(frameBufferA);
world.draw(frameBufferA);
frameBufferA.update();
frameBufferA.displayGLOnly();
viewingCanvasA.repaint();

frameBufferB.clear();
world.renderScene(frameBufferB);
world.draw(frameBufferB);
frameBufferB.update();
frameBufferB.displayGLOnly();
viewingCanvasB.repaint();


This problem only occurs with hardware rendering; in software rendering mode it works fine.

[Mr.Marbles]

I just tried creating a seperate world for the second FrameBuffer and I still get the same texture problems. I know the TextureManager is a Singleton, does it have any dependancy on the World object that may prevent it from being shared in two different worlds?

By the way, this is the 3rd world in my application. At first I had 2 worlds; the 1st one is rendered to its own FrameBuffer and the 2nd one was the one I rendered to 2 different FrameBuffers (as in my last post).

So now even after creating a 3rd world, I still have the same problem with the textures; they either don't appear, or are mapped to the wrong objects randomly  :?

[EgonOlsen]

Which renderer is that? GL or AWTGL?

[Mr.Marbles]

I'm using:

Code Select Expand


viewingCanvasA = frameBufferA.enableGLCanvasRenderer(IRenderer.MODE_OPENGL);


So I guess it's GL  :?:

[EgonOlsen]

No, that's AWTGL. I've already thought so, because i think that you can't even do what you do with the native LWJGL window (cause there can be only one). I'll check out if this is a jPCT or LWJGL problem that you are experiencing.

[EgonOlsen]

There was a problem with the different FrameBuffers using different renderers running in different contexts. I've uploaded version 1.11a which should fix this problem (see News-section). Keep in mind that the contexts don't share ressources, i.e. three framebuffers mean three times the texture memory needed.

[Mr.Marbles]

EgonOlsen,

Thank-you for the fix.

Keep in mind that the contexts don't share ressources, i.e. three framebuffers mean three times the texture memory needed.

Why is the TextureManager a Singleton? Why could it not have been instanciated in the World class and used through the World's API? This way each world would contain its own set of textures. Also, it seems excessive to allocate space for all textures everytime a FrameBuffer is created...

[EgonOlsen]

Why is the TextureManager a Singleton? Why could it not have been instanciated in the World class and used through the World's API? This way each world would contain its own set of textures. Also, it seems excessive to allocate space for all textures everytime a FrameBuffer is created...

Making the TextureManager a singleton makes a lot of things easier internally. Instead of passing around the World and get the Textures from it, each class can access the TextureManager without knowing anything about a world.
Making it a World's attribute won't help memory wise either. The textures are not doubled inside the manager or something when creating a new FrameBuffer. On the Java side, they exist exactly one time no matter how many FrameBuffers you are using. However, they will be uploaded multiple times to  the graphics card when used in different contexts. That's the way OpenGL works. But it's lazy uploading, i.e. they won't be uploaded until needed in the context.

[Mr.Marbles]

However, they will be uploaded multiple times to  the graphics card when used in different contexts. That's the way OpenGL works. But it's lazy uploading, i.e. they won't be uploaded until needed in the context.

Ok I understand now, so the graphics bandwidth increases with every context that is rendered to. With the worse case being completely different contexts, which in my case shouldn't be so bad since I'm rendering the exact same scene twice.