Support for 32-bit depth buffers is driver dependent. I believe some will
fallback on 24-bit if 32-bit is not supported.
On Thu, Nov 14, 2013 at 3:49 PM, Bram Vaessen wrote:
> Thanks, that makes perfect sense. I didn't know it was normalized, so I
> just have to make sure the camera's have the s
Thanks, that makes perfect sense. I didn't know it was normalized, so I just
have to make sure the camera's have the same clipping planes, didn't need to
increase it to 10 (my scene is much smaller than that :)
The depth buffer is based on 32 bits floats right (just for my information)?
Hi Bram,
Sorry, I misunderstood your question.
The values in the depth buffer are normalized based on the near/far clip
planes. If you are automatically computing the near/far planes, then they
can end up being different for each camera, which causes the depth test for
the water scene to be compu
Farshid, I should have been more clear about it, but that was actually my
intention. The terrain and water are in the same world so i wanted to use the
depth information from the terrain render to draw only visible portions of the
water to the other buffer.
Sebastian, I always get this error: "
Hi Bram,
From my experience you should always add the depth texture as input
sampler to the consecutive passes if they use it for writing.
That sounds weird but solved those issues for me.
Also keep in mind that all buffers should have the same resolution (i.e.
as you are using sampleRect). Do
Hi Bram,
The water camera is not clearing the depth buffer, which means it will be
performing depth tests against the depth values from the world camera. Try
setting the clear mask for the water camera to the following:
waterCamera->setClearMask(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
Cheers
6 matches
Mail list logo
