I try to implement technique, called “Screen Space Reflections”. For this I need to reconstruct point position from geom buffer (depth, normal), then reflect view ray and trace it in the ScreenSpace.
The problem is that I get an incorrect result.
I think that i miss something in transformations algorythm or I do wrong position reconstruction.
// point position reconstruct
float D = tex2D(depth, l_texcoord0).x;
float4 P = float4(l_position.x, l_position.y, D, 1);
P = mul(trans_clip_to_view, P);
float4 N = tex2D(normal, l_texcoord0);
N.xyz = (N.xyz - 0.5) * 2.0;
R = reflect(P.xyz, N.xyz);
R = normalize(R);
// To viewspace
R = mul(trans_view_to_clip, R);
In raytrace cycle I calc position to check
float4(l_position.x, l_position.y, D, 1) + R * i;
Not sure that I can explain correctly, but I can upload full example.
Yes, I used ShaderGenerator to get all textures needed to the geometry buffer and yes, my shader works in post-rocessing pass.
In this case trans_view_to_clip is also incorrect, right?
Can I somehow work around this behaviour or should I pass custom matrices to the shader?
Maybe if you use the same lens for the postprocessing pass, but that also means you’ll need to reposition the quad so that it still fills the screen properly.
However, this particular matrix is very easy to pass yourself, as it remains constant as long as the lens settings remain constant (it is the projection matrix of the lens). I think you can get it using lens.getProjectionMatInv().
There may also be coordinate system transforms involved. I’m not sure.
I’ve tryed to use matrices from main camera, but it seems that something still wrong. Seems that reflections depend on camera angle and distance, and more or less correct reflections I get when angle about 45 degrees.
I also found out that I can simply set main camera as shader input and then use trans_clip_of_mcamera_to_view_of_mcamera, trans_view_of_mcamera_to_clip_of_mcamera it’s the same as getProjectionMatInv(), getProjectionMat()
Seems I solved problem. It’s my fault again I’ve made reflected vector in the ClipSpace instead of ViewSpace.
So I have another question: In Cg I can’t make dynamic cycle for raytracing - Cg reports me that “shader to complex” when I try to do it. I’ve bit played with GLSL and hasn’t found this restriction in it. I read somewhere that it’s because Cg unwraps cycles into linear instructions and shader becomes too large. Is it fixed behaviour or I may avoid it?
I’m not sure. I’ve found that on ATI cards, if you use a non-constant value in the for loop, it can’t be unrolled and the shader won’t compile. Does it work when you replace the variable with a constant value?
Or is it the other way around in your case, that it does work when using a non-constant value but doesn’t when it’s able to unroll it?
You may try using a more recent Cg profile, and setting “basic-shaders-only” to “#f”. I don’t know why it would still give the problem with the glslv and glslf profile if it does work in GLSL.
By the way, the effect looks incredibly cool. Great job! I hope that you’ll share it with us when you’ve finished it!
The onboard Intel cards has the same issue.
Yes, this is one aspect of the problem. Another - that if the cycle has too many iterations (even with constant in it) Cg also dosen’t compiles it for some cards, and I can’t tell how many iterations I can do on the specific video card. So I thought that maybe there is a way to tell to Cg “do not unroll cycles”.
I already use “basic-shaders-only #f”.
I’ve tryed to play with setting different profiles in shader header, but it seems that it hasn’t any effect.
Well, there are compiler flags to “cgc” related to unrolling (see “man cgc”). It would be relatively trivial to add support for setting these in Cg shaders, ie using something like “//Cg unroll none”. Could you file a bug report for this so that I’ll remember to look into it?
Ah, in the bug report you mentioned that you got the issue “Cg shader too complex for driver”. This issue occurs when the shader does compile correctly, but its profile does not match the one you requested.
If you get it, then the solution is to choose an explicit profile in your Cg shader, using a line like “//Cg profile vp40 fp40”.
(Arguably, this should not be a fatal error. I’ll check in a change that clarifies the error more, though. It actually indicates that the shader did compile correctly, just not for the profile that was selected.)
The feature request to specify custom options is perhaps nice, but it’s not necessary to fix the issue.
Oops. Sorry. Just checked Cg ignores profile definition and drops it to arbfp1 arbvp1. Like in this theme panda3d.org/forums/viewtopic … f23e278598
But it’s happens only on ATI and Intel and I already have latest drivers.
Please download the latest devel build of Panda3D for Windows. Then, set “notify-level-gobj” and “notify-level-glgsg” to debug. It should print out various debug messages about the supported Cg profiles and the shader compilation process.
Can I used previous versions?
I think that we discuss the problem also related to this topic [push texture to vshader sha file) because in both cases we are dealing with non-Nvidia cards and changing profle not solved it (at least for me).
May be start new topic which reflects the problem?
I only today checked in the new debug messages, so you’ll need to use the latest build in order to get the debug output.
Yeah, I started to think that we’re uncovering a deeper bug with Cg and ATI, which is why I made these commits in the first place. This debug output will help me get a better understanding of what’s going on.
The TypeHandle error is new to me. I’m currently too busy with the migration to look into it, so please remind me in a few days.