Translucent reflections and nvidia

Say we have a water surface at y=0 and we place a model in it, where parts are below and parts are above the water. Now I would like a partly reflective and transparent water surface and I would like the water surface to be modulated with a bluish-water-texture. The problem is when rendering the mirrored object where I would want the parts y>0 to be cut off. The right way would be to use a user clipping plane but nvidia does only support this when saccrificing a texture unit. Any suggestions?

I suggest sacrificing the texture unit. The other option is that you could manually clip the object, but I would strong suggest you should NOT do that. Or you could try stenciling out areas, but that may not be as good either (I certainly dont think it would get you any better off than the clipping plane)

Originally posted by LordKronos:
I suggest sacrificing the texture unit. The other option is that you could manually clip the object, but I would strong suggest you should NOT do that. Or you could try stenciling out areas, but that may not be as good either (I certainly dont think it would get you any better off than the clipping plane)

Thank you for your comment. As I see it stencilling cant do the work here. And yes manually would be too slow. The clipping plane is the right way. It is really unacceptable that nvidia doesn’t support such an simple feature. Even quake3 uses a user clipping plane for the portals.

Other suggestions to this problem are welcome?

Hmm… can you afford 2 passes on the clipped reflection? Are you already using stencil?

A first pass with a stencil write on the clipped reflection would improve things. Then you stencil test on the second pass leaving you with all textures.

It’s not perfect, if the clipped reflection get’s occluded by the unclipped reflected geometry above the water it will pass the stencil test.

You could supplement this with primitive level culling to reduce the likelyhood of the above problem.

[This message has been edited by dorbie (edited 05-31-2002).]

Trying to solve the occlusion problem raised by my solution I realized that a depth equal test on the second pass would solve the occlusion problem if you’re on a decent NVIDIA card (this isn’t guaranteed on all OpenGL implementations but probably is OK on most decent new cards).

Now for the bonus. Depth equal testing the second reflection pass also eliminates the need to use a stencil test.

So you draw the reflection with glColorMask to stop color writes, and a clip plane to clip to the water surface. Then you draw the reflection with a glDepthFunc of GL_EQUAL without the clipping letting you include all your shader stuff, and any stencil you might want for other purposes.

You basically use the depth buffer to store the invisible fragment clip test result to the framebuffer.

[This message has been edited by dorbie (edited 05-31-2002).]

i assume an extra pass is worse than ‘sacrificing a texture unit’ (said with a big grin) the best way to do it is sacrifice a texture unit using uum i dont know projected textures or something (with alpha test) sorry guys

The extra pass is a bummer but it might save having to implement a multipass shader or compromise on the appearance of the object being reflected. It’s getting drawn twice anyway, so it’s 3 vs 2.

If you’re prepared to sacrafice the texture unit you’d probably want to use glClipPlane, why reinvent the wheel?

I find it frustrating there’s no way to work around this in a single pass, (at least nobody has come up with it yet).

How about this; assign fragment alpha using vertex values to be linearly interpolated? No texture unit required.

You map the alpha from 0-1 linearly on the object in the plane of the water such that .5 alpha fragment interpolation lands exactly on the water surface. If height changes you must reassign vertex alpha, if you want to you could easily implement a vertex shader to make vertex alpha generation by height automatic. Then you perform fragment alpha test with a reference value at 0.5. You end up with the alpha clipping at the waterline (precision permitting).

Or use the fog coordinate extension, with a fog alpha range, the use the alpha test.
Essentially the same thing as using a vertex program (but more widely supported), but you lose the use of fog!

Thank you for your comments.

Stencil: As you wrote, with stencilling some of the guys ‘feet’ would be included.

z-buffer: it could be used, but then the model would have to be drawn z-sorted (too slow).

alpha pixel test: It may work, but I fear that precision could be a problem.

alpha-fog pixel test: I dont think alpha is a part of the opengl fogging.

user clip plane: this is the right way if the hardware supports it.

How about some of you made a small demo program which illustrated your idea? I actually think this problem is much more relevant than many other strange new hardware features. Nvidia should have implemented this long ago. Doesn’t the radeon support this?

[This message has been edited by mfugl (edited 06-02-2002).]

The model is not drawn zsorted for the zbuffer approach. It certainly needs to be drawn without the water plane in the zbuffer but that’s true with any approach.

With the vertex alpha pixel test you clamp at 0 and 1, the real precision must be spent between where you know the largest polygon will be on either side of the plane while intersecting the plane.

i.e. the precision issues are mitigated by the triangle size rather than the primitive or object size. This should only be a problem if you have very large triangles.

Good luck.

[This message has been edited by dorbie (edited 06-02-2002).]

mfugl
About user clipping planes: don’t forget they don’t work with nVidia’s vertex programs. If you have something that is drawn using vertex program and must be clipped to the water then you have to use texture shader and sacrifice TMU by yourself

Coop

Originally posted by coop:
[b]mfugl
About user clipping planes: don’t forget they don’t work with nVidia’s vertex programs. If you have something that is drawn using vertex program and must be clipped to the water then you have to use texture shader and sacrifice TMU by yourself

Coop[/b]

Where did you get this idea? They clip on a per pixel basis using a tmu always and probably switch to software mode if not enough tmu’s are unused.

Originally posted by dorbie:
[b]The model is not drawn zsorted for the zbuffer approach. It certainly needs to be drawn without the water plane in the zbuffer but that’s true with any approach.

With the vertex alpha pixel test you clamp at 0 and 1, the real precision must be spent between where you know the largest polygon will be on either side of the plane while intersecting the plane.

i.e. the precision issues are mitigated by the triangle size rather than the primitive or object size. This should only be a problem if you have very large triangles.

Good luck.

[This message has been edited by dorbie (edited 06-02-2002).][/b]

This is black talk to me!

It’s in the GL_NV_vertex_program specification. Look at the issue section, here is the fragment:


Should client-defined clip planes operate when vertex program mode is
enabled?
RESOLUTION. No.
(…)

User clip planes work with ATI vertex shaders (GL_EXT_vertex_shader). That’s a pity nVidia doesn’t support it.

Originally posted by coop:
[b]It’s in the GL_NV_vertex_program specification. Look at the issue section, here is the fragment:


Should client-defined clip planes operate when vertex program mode is
enabled?
RESOLUTION. No.
(…)

User clip planes work with ATI vertex shaders (GL_EXT_vertex_shader). That’s a pity nVidia doesn’t support it.[/b]

Ok thanks I can’t see the logic though. Perhaps it is something against a possible future implementation with clipping which modifies geometry…

I think the reason is more simple than that. Nvidia does clipping planes using a texture unit with texgen. Texgen is part of the T&L processes. Vertex programs bypass the standard T&L and allow you to specify a custom T&L process, thus it would probably be difficult for nvidia to mix clipping planes into your user defined vertex programs (ex: what do they do if your vertex program is too big for them to add in extra instructions for the clip plane tex-gen?).

What is black talk?

Originally posted by dorbie:
What is black talk?

It’s a Danish expression translated literally into English - it means you might aswell have been speaking Chinese ( I think that is the English version ) - that is, he didn’t understand what you wrote.

Originally posted by PH:
It’s a Danish expression translated literally into English - it means you might aswell have been speaking Chinese ( I think that is the English version ) - that is, he didn’t understand what you wrote.

Damn that was bad english