Depth buffer texture

[Thomas.]

Here is simple test app. This app says "Creating render buffer in depth mode!", I don't know where the method should be.

http://dl.dropbox.com/u/26148874/TestProject.zip

[EgonOlsen]

The problem seems to be (according to some sparse information on the web), that you can't attach a render buffer to the default frame buffer. You always have to create a FBO to do this.
So what might work instead is this:

Instead of rendering directly into the frame buffer, create an additional render target with the size of the frame buffer, call createRenderBuffer() on the frame buffer and assign the target. Render into that instead of the frame buffer and blit or "overlay" the result into the actual frame buffer. If that works, i'll somehow rework the current API design because it comes down to sharing render buffers between render targets in that case.

[Thomas.]

I think that problem with my understanding persists (black screen) Could you edit test app, please?

[EgonOlsen]

I fail to see any relation between the TestProject and the actual problem, but the test case wasn't correct anyway, because it didn't use the static factory-method to create the NPOT-texture. It tried to do that directly in the constructor, which isn't supported. Anyway, i've changed two things in the API:

• that static factory method for NPOT-textures is gone. Instead, there's a class NPOTTexture that you can use.
• I've removed the createRenderBuffer-method and replaced it with a new class DepthBuffer. You can create a DepthBuffer and assign it to a texture. You can assign one DepthBuffer to multiple textures. That way, you can use the same depth buffer for different render targets.

I've modified your code to reflect this:

Code Select Expand


renderTarget = new NPOTTexture(fb.getWidth(), fb.getHeight(), null);
tm.addTexture("renderTarget", renderTarget);

depthBuffer=new DepthBuffer(fb.getWidth(), fb.getHeight());
renderTarget.setDepthBuffer(depthBuffer);


Setting the depth buffer here has no real purpose though, because your code doesn't use multiple render targets anyway...but i guess that's just because it's a test case.

The jar has been updated as well, of course.

[Thomas.]

Oh sorry, I forgot on NPOT texture. I do not know if we are understand in this problem. First render is to texture, second (here I need depth buffer) to "screen". Is needed to render both to the texture and in extra third rendering just blit it?

[EgonOlsen]

Yes. You will end up with two render targets of the same size, one depth buffer assigned to them and a final stage where you blit/overlay the result onto screen. No idea if that actually works, but if it doesn't, i don't know what will.

[EgonOlsen]

I've updated the jar again with a version that includes a small fix that lets the DepthBuffer survice a context change.

[Thomas.]

Something is wrong (green plane would be shaded), but depth really working. And it is very slow, just 39 fps on xperia neo.



updated test app
http://dl.dropbox.com/u/26148874/TestProject.zip

[EgonOlsen]

What am i supposed to see in that test app? It doesn't look like the one on the screen shot!? Nothing is green in it and can't spot any intersections...? Anyway, i don't see a relation between shading and a depth buffer. They have nothing to do with each other. Are you sure that your setup is correct to get this thing shaded?

Regarding performance: That's what you ask for, i'm afraid. You are rendering the screen 3 times per frame. That alone eats fillrate. Combine that with the large NPOT textures you are using and the additional power needed to process the (albeit simple) shaders as well as the state switched needed to change the fbos and that's the result. The code that sets the shared depth buffer is the exact same one as before with the only difference that it uses a different variable to store the render buffer in. It's not performance critical. Apart from that, 39 fps on a Snapdragon device is NOT very slow. 3.9 fps would be very slow.

[Thomas.]

By menu button you can switch between objects, in screenshot is second one. Colors are bad. Color of object in second world is from "fb.clearColorBufferOnly(RGBColor.GREEN);" if you call "fb.clearColorBufferOnly(RGBColor.WHITE);", object be white, wtf?

[EgonOlsen]

BTW: Don't let these simple test cases fool you. If you are not taxing the cpu much (which you don't do here), the device might clock down. I can see this in the test app on my phone...as long as i make the cube spinning around, performance is around 40-45 fps. But when i stop doing so, it drops to ~30fps...simply because the energy saving kicks in and clocks things down.

[EgonOlsen]

By menu button you can switch between objects, in screenshot is second one. Colors are bad. Color of object in second world is from "fb.clearColorBufferOnly(RGBColor.GREEN);" if you call "fb.clearColorBufferOnly(RGBColor.WHITE);", object be white, wtf?

I can't verify this. I've no intersection of that blue plane with any other object. The blue plane is always in front of everything no matter how i turn the objects. And the shading on the objects looks fine to me. Are you sure the download points to the right test case?

[Thomas.]

On my device it is shaded about 0.5sec. Object in first world has color from fb.clearColorB... When you change this code

Code Select Expand

fb.clear();
fb.setRenderTarget(renderTarget);
fb.clear();
world.renderScene(fb);
world.draw(fb);
fb.display();
fb.removeRenderTarget();

fb.setRenderTarget(renderTarget2);
fb.clearColorBufferOnly(RGBColor.GREEN);
secWorld.renderScene(fb);
secWorld.draw(fb);
fb.display();
fb.removeRenderTarget();

fb.clear();
fb.blit(renderTarget2, 0, 0, 0, 0, fb.getWidth(), fb.getHeight(), FrameBuffer.OPAQUE_BLITTING);

to this

Code Select Expand

fb.clear();
world.renderScene(fb);
world.draw(fb);
secWorld.renderScene(fb);
secWorld.draw(fb);

it is what I want

[EgonOlsen]

I see...there was a little problem in the buffer sharing code, but i don't think that this has caused it. I've updated the jar anyway, you might want to try it.

On my phone, shading works fine, but the depth buffer doesn't...maybe time still hasn't come for this stuff on current devices. Seems like asking for compatibility problems all the way...

[Thomas.]

It is same on my phone

edit: and what fb.clearColorBufferOnly(...) method? when I replace it by fb.clear(), colors are fine, but of course depth is also cleared...