If you choose something other than GL_DEPTH_COMPONENT, you will get an invalid operation error. glCopyTexSubImage will also try to grab the depth buffer if it's looking at the one you've changed to determine which buffer to use.

If it's just not just snipping the precision before copying it, then I have no clue as to why it is working like that. Quite strange.

TomorrowPlusX Wrote:And, when I sample the depth texture, are r,g,b and a all the same value? Am I sampling the incorrect one?

The conversion from DEPTH_COMPONENT to RGBA depends on DEPTH_TEXTURE_MODE. See section 3.8.4 in ARB_depth_texture.

Quote:I know that I'm supposed to use shadow2D samplers for GL_DEPTH_COMPONENT ( at least according to the orange book ) but there's no Rect variant.

shadow2DRect should work, and is defined by ARB_texture_rectangle, see 2.15.4.

I looked around and found these threads on opengl.org:

http://www.opengl.org/cgi-bin/ubb/ultima...013943;p=1

http://www.opengl.org/cgi-bin/ubb/ultima...1&t=001116

And I learned about depth_texture_mode there -- still no luck.

So, my depth texture creation looks like this, now:

And using the fragment shader:

I still get the exact same aliasing artifacts.

This, again, might be nitpicking, but are you sure that your smoothstep call in the fragment shader is correct? From where I'm standing, a-b won't be in the [0 10] range, but rather in the [0 1] range. But I guess that if that was the problem, it would make your effect far too faint to even render anyway...

Fenris Wrote:This, again, might be nitpicking, but are you sure that your smoothstep call in the fragment shader is correct? From where I'm standing, a-b won't be in the [0 10] range, but rather in the [0 1] range. But I guess that if that was the problem, it would make your effect far too faint to even render anyway...

Actually, the "ConvertDepth" functions are converting values in the depth buffer ( non-linear 0->1 ) to linear world-space, where 10 would mean "10 world units".

As far as I can tell, the math is right. My depth texture, however, remains nastily aliased.

On the off chance that somebody might be willing to help me out, here:

http://zakariya.net/shamyl/etc/Water.zip

This ought to build and run on intel ( but untested ). I can't seem to fix the problem, and maybe somebody here can see what I'm doing wrong.

When you run it, you'll see something like this:


On the left is the converted depth value for gl_FragCoord.z, on the right is the value from the depth texture. Very clearly aliased.

Any help would be greatly appreciated!

I hate to add to the problems, but it shows up as pure white on the right hand side on my MacBook Pro. I can try it on my PowerMac when I get home, but since it's also an ATI card, I doubt I'll see much improvement. I tried to change the formats a bit, such as using just GL_DEPTH_COMPONENT without specifying a size and trying different types such as GL_UNSIGNED_INT and GL_UNSIGNED_SHORT to no avail.

akb825 Wrote:I hate to add to the problems, but it shows up as pure white on the right hand side on my MacBook Pro. I can try it on my PowerMac when I get home, but since it's also an ATI card, I doubt I'll see much improvement. I tried to change the formats a bit, such as using just GL_DEPTH_COMPONENT without specifying a size and trying different types such as GL_UNSIGNED_INT and GL_UNSIGNED_SHORT to no avail.

Hey, since you're on an ATI, could you try running it ( from the command line ) as such:


THis will cause it to execute the water shaders, instead of the default depth_test shaders.

Could you let me know if it renders ( anything )?

It seems to work fine with just the water. Runs at about 42 FPS on my MacBook Pro.

It's kind of interesting seeing the difference between your demo and mine. I guess your method is best at simulating bodies of water like a turbulent ocean, while mine is better for something like a calm lake. When I start making bodies of water in games etc., I'll probably do something similar to yours for things such as an ocean, having less of the refraction showing through and having the diffuse lighting.

Same here, just white on the right hand side, but the water shader looks fine. Not sure if the transparency shows up, though, so I'd wager that you're getting all ones or zeroes. I tried taking a screenshot, and something magical happened:


The water just didn't print on the screenshot!

Anyway, notice how there isn't a transparent teapot under the water surface...

Screenshots can get... very finicky. Sometimes you'll get nothing, sometimes you'll get a piece of the final picture. The slower the framerate is, the harder it is to grab a correct one. It can often take several tries.

LOL @ the screenshot. If you want to capture it correctly, in my experience, use command-shift-3 -- as opposed to command-shift-4. FOr some reason that captures opengl better, perhaps it waits for a v-sync or something.

That said, thanks for the nice words, I still need to fix lighting in the reflection, though. It's inverted! And I can't figure out why...

BTW, I've been wondering, how do you do your movement? I took the lazy way out and just translated the water texture, and it looks fine as it is now, but if I ever want the more turbulent look and add diffuse lighting, then it definitely would be more obvious.

I couldn't figure out why your lighting is inverted, though. I just used gluLookAt for my camera, then inverted the x coordinate to achieve my lighting.

MacBook results:

Double click on Water:

./water from the Terminal:

./Water water from the Terminal:
got the same bus error & crash log as above, with this output on the Terminal:

Rebuilt in Xcode and got the same results.

FWIW, I should mention that akb825's water demo from that other thread does work fine on my MacBook, both the FBO & non-FBO versions (with the FBO version being 5-6% faster)

I have had some sucess getting the depth of field code working, well just the reading of the depth texture and creating a blur value based on distance from the camera.

The shader code is as follows (I appologise for my lazyness and hard coding so many values as opposed to passing them in)


Here is a screenshot of the result for a simple scene.



The black area would be the focal point, and white at and beyond the near and far depth values. If I had a larger scene to play with I could show it over a larger range. However as I am not rendering the depth value directly, I am possibly hiding the evidence of any banding. This is running on a Mobility Radeon 9600 which slows down quite a lot with this shader probably due to the branching. I have not yet tried it on my Geforce 6600.