Cubemap & Depth write problem

Hello, I am trying to get a water shader, but I have problems with the cubemap generation. If I use the code snippet found here panda3d.org/manual/index.php … _Cube_Maps and replace the environment by the default panda model :
I get this (inside yellow rectangle) :

it looks like depth write is disabled for the cameras used for the creation of the cubemap, this is not a big problem, but when I use cubemap in a scene with a skybox (with normals reversed) the objects inside the sphere flicker every frame, like a z-fighting problem maybe. It seems the cubemap generator ignores all my depth write & test settings.

Hmm, that’s the first time I’ve heard of a problem like this. Normally, the depth buffer should be functional in the cube map buffers; but it sounds like you’re somehow getting an offscreen buffer without a depth buffer associated for some reason, which is strange.

Can you check the kind of object is the return value from makeCubeMap()–is it a ParasiteBuffer, or is it a GraphicsBuffer? What is the result of buffer.getFbProperties() on this buffer object? (You might need to wait for a frame to elapse, or for base.graphicsEngine.openWindows(), before this value is filled in correctly).

How large a buffer are you asking for? What happens if you set “prefer-parasite-buffer 1” or even “force-parasite-buffer 1” in your Config.prc file?

What operating system are you running on? What hardware?

David

Thanks for answer!

buffer is “libpanda.GraphicsBuffer”,
getFbProperties() gives “depth_bits=1”.

With parasite buffer it is displaying ok.

My OS is ubuntu 10.10, cg is gtx 260 with updated drivers.

Hmm, so for some reason, you are not getting a depth buffer even though it thinks you are. Something appears to be broken either in your driver or in the way Panda is creating an offscreen buffer. This will bear further investigation.

Can you get an offscreen buffer that has a working depth buffer in other contexts, or is it only with a cube map that it’s broken?

David

Yes I have working depth buffer in other context, only the cube map generator does this.

What are the pros&cons of parasite buffer?

Hmm, that’s strange, since win.makeCubeMap() simply calls win.makeTextureBuffer(). When you have a working depth buffer, is it from a call to makeTextureBuffer(), or is it some other call? Do you get a working depth buffer if you call makeTextureBuffer() directly?

What are the pros&cons of parasite buffer?

It’s mostly pros, in my opinion. :slight_smile: A parasite buffer renders directly to the main window’s back buffer, then copies the pixels out before the main window draws itself.

pros:
(1) no additional framebuffer memory is required
(2) fewer driver issues
(3) guaranteed to match the main window framebuffer properties

cons:
(1) it’s not possible to share the texture memory directly–a copy is always required. However, this is commonly the case anyway, and the copy is fast, because it involves only high-speed graphics memory, not relatively slow main memory.
(2) the parasite buffer cannot be larger than the window. Cube maps are usually smaller than the main window anyway.

David

g_buffer = base.graphicsEngine.makeOutput(
            base.pipe, "offscreenBuffer",
            0, props, winprops,
            GraphicsPipe.BFRefuseWindow,
            base.win.getGsg(), base.win)

depth_map = Texture()
g_buffer.addRenderTexture(depth_map, GraphicsOutput.RTMBindOrCopy, GraphicsOutput.RTPDepth)

or

shadow_map = Texture()
shadow_buffer = base.win.makeTextureBuffer('shadow', 512, 512,shadow_map)

give me a working depth map.

Something I noticed too and don’t understand : if my main class inherits from Showbase, my fps is lower than if it inherits from DirectObject, it looks like the fps is capped to 60 or something.

If you inherit from ShowBase, be sure you remove any imports of DirectStart. You don’t want to both import DirectStart and also inherit from ShowBase, because that will create two ShowBase instances.

David

For the record, I recently found the problem with depth buffers with cube maps in the render-to-texture FBO buffer implementation. Will be checking in a fix shortly.

David

Awesome, I was unable to figure that one out in the past. Great job, thanks!