Yeah, it shouldn't matter whether you normalize it or not (although if you were to normalize it in the vertex shader that would screw things up). Does the vertex data match the ones I use?

I don't see anything obviously wrong in that piece of code, although I notice that you flipped some signs, but that shouldn't cause this kind of problem. The "HACK" stuff obviously doesn't belong...

The size does not matter since texture are looked up with normalized texture coordinates in 0..1 range regardless of size.

Half is just a lower-precision float.
Something like this should work.



varying vec2 texCoord;

uniform sampler2D Image;
uniform sampler3D LookupTable;

It's just a texture fetch. Pass the color that you want to process as a texture coordinate into a volumetric texture and you're done.

You're not confusing uniform location with sampler index, are you?
You have to assign samplers to texture units yourself with glUniform1i(), otherwise both lightDepthTexture0 and lightDepthTexture1...

I'm surprised that you're able to draw onto the other application's window at all. But in any case, did you call glViewport() in response to the window resize? Otherwise it'll just keep using the...

Some of my demos use volumetric textures. This one for instance:
http://www.humus.name/index.php?page=3D&ID=47

But you can also create your own test textures easily with DxTex.exe from the DX SDK.

All texture formats that are supported in the fragment pipeline should also be supported in the vertex pipeline on DX10 level hardware.

You need to pass down both z and w to the fragment shader and do the division there. Otherwise you're getting the wrong depth distribution.

Final depth values will always be [0..1], but your actual near and far plane are probably not where you expect them to be from your calls, nor will your depth distribution be linear just because you...

Why do you say that? The Z-buffer has advanced at least as much as the rest of the pipeline. 10 years ago a lot of hardware didn't even have one. The ones that did had a 16bit one. Since then we've...

The problem is that you're confusing the backface culling with the depth test. The backface culling is working perfectly from what I can tell running your app. The faces that bleed through are all...

Yes, it depends on W, but not on Z or Z/W that's used in the depth test.

I fear that you're right. I'm losing my faith in OpenGL to be honest. For the last year or so I have barely done anything in OpenGL. It's been DX10 mostly. For someone that used to be pretty much an...

You pass the texture coordinate that you'll use in the texture lookup. texture2DLod is generally faster, however, you won't get anisotropic filtering with it, and you have to factor in that it takes...

No it's not. Period.
You're either misunderstanding something, or you have a bug.



The depth is irrelevant to backface culling. X and Y is sufficient. Check the OpenGL spec, section 2.14.1,...

It doesn't help the final storage, but it helps the computations leading up to the final Z value. It helped a lot for Z-fighting in the distance in our engine, even though we use fixed point Z. I was...

It may be faster, but it would also be unreliable as there's no guarantee that the provided normals really match the input geometry. Any form of smoothed normals would be prone to artifacts. Besides,...

Backface culling is done before rasterization, so z-buffering have nothing to do with any artifacts you may see.
The only reason I can see why that would happen is because your projection matrix...

Many of us write projects that struggle with real-time performance on highend hardware. I wouldn't want the API to chance so that molecule to universe scale application can render effortlessly at the...

I don't think the Z-buffer is antiquated in any way. It's done the way it is for a reason. We're trading non-optimal Z-distribution for simpler and faster hardware. Z is linear in screen-space...

The G70 has rather poor dynamic branching performance. For this reason, the driver may decide to flatten the branch, or if it doesn't the branching performance may simply be this poor. What's the...

This is what I usually do if it's just for debugging to get it into visible range. If you want to be more accurate though, you can compute the linear depth from the Z values.
...

Here they are:
http://ati.amd.com/developer/open_gpu_documentation.html

Not sure if they'll help much though.