I implemented a refraction effect using the offset_texture_2D texture shader. What I did was just render everything below the water to a texture, and then project that texture onto the water surface. I then use the texture shader to do EMBM-style water ripples.
The problem is that as soon as I enable the texture shader, my projected texture stops working. The texture coordinates for my water plane seem to go all over the place, rather than being projected properly as they were before I enabled the texture shader.
The problem isn’t due to the offsetting itself – even if I set the 2D matrix to all zeroes, the texture still gets horribly distorted. I’ve checked that the projected texture works correctly without the texture shader, and if I use a standard texture instead of the projected one (i.e. identity texture matrix), the offset shader also behaves as expected.
Any ideas what I could be doing wrong? Thanks,
I not sure if this will help, but the following may be what’s causing problems,
From an NVIDIA’s texture shader presentation ( offset texture 2d section )
Use previous lookup (a signed 2D offset) to perturb the texture coordinates of a subsequent (non-projective) 2D texture lookup
Thanks PH, it looks like you hit the nail on the head. Apparently there’s an “offset_projective_texture_2d” option in GL_NV_texture_shader3. I tried it out on my GeForce3 (by enabling NV25Emulate), and it’s exactly what I need. Unfortunately it runs in software
I found more information on NVidia’s site:
14. Are there any limitations with EMBM on GeForce3?
GeForce3 doesn’t do the divide for projection after doing the ds/dt offset and rotation for EMBM. You can, however, project before the ds/dt offset. In other words, the “bump map” can be projective, but the environment map cannot.
but that should not be a problem. the envmap can be a texture wich is yet rendered projectively… means the unprojected texture shows the projected image… then you can use it without any problems…
I’ve come across the same problem when implementing planar EMBM reflections. You can get around the non-projective restriction on GeForce3 by subdividing your reflection plane, and doing the projective divide per vertex in a vertex program:
transform to clip space
DP4 R0.x, c[C_MVP_MATRIX_X], v[OPOS];
DP4 R0.y, c[C_MVP_MATRIX_Y], v[OPOS];
DP4 R0.z, c[C_MVP_MATRIX_Z], v[OPOS];
DP4 R0.w, c[C_MVP_MATRIX_W], v[OPOS];
window space texgen
RCP R1.w, R0.w;
MUL R1.xyz, R0, R1.w;
MAD o[TEX0].xy, R1, c[C_HALF].x, c[C_HALF].x;
MOV o[TEX0].w, c[C_ONE].x;
Hope this helps,
[QUOTE]Originally posted by Tom Nuydens:
[b]Thanks PH, it looks like you hit the nail on the head. Apparently there’s an “offset_projective_texture_2d” option in GL_NV_texture_shader3. I tried it out on my GeForce3 (by enabling NV25Emulate), and it’s exactly what I need. Unfortunately it runs in software
Thanks Simon, that works very well. The problem now becomes visible only if you get very close to the water. I’m wrapping up a demo now, and will post it on www.delphi3d.net shortly.
can you explain, with more detail, how you do this effect? when you render what beneath the water to tezture, from where you render it? from the eye point, and project it from there too? its seems logic.
Originally posted by okapota:
when you render what beneath the water to tezture, from where you render it? from the eye point, and project it from there too?
Exactly – the viewpoint is never changed. Without ever touching the camera, I render the underwater stuff to the texture. Then I use Simon’s vertex program (see above) to render the water surface with window-space texcoord generation. The offset texture does the rest.
The offset texture is actually used twice: once to distort the refraction map, and once to look up in an environment map (in order to provide some fake lighting on the waves).
this vertex shader is what you call projective texturing right?
Yes. I originally implemented it using the “classic” projective texturing technique – i.e. I replicated the modelview and projection transformation on the texture matrix. However, as pointed out in this thread, that only works on GeForce4. The vertex program above, which is what I use now, does the exact same thing but also adds the manual perspective divide.
another question - do you generate the ds/dt bitmap used for bumpmapping and refraction in realtime using perlin noise, or is it a static bitmap, and you only change the offset matrix values?