GL3 tb.pl.disco.duck in Windows
Hi everyone,
I'm digging into the wonderful gl3 package, and I found a strange artifact using "tb.pl.disco.duck" under Windows. By default, opening the patch in Windows looks like this:
Changing the "shininess" of the second [jit.gl.mesh] to somehting very close to 0 like 0.00001 is better, but some shadows are still strange (look inside the orange square at the bottom right):
These screenshots are made on a PC with an Nvidia RTX2080. I had a guess it was due to a different graphic card than a Macbook Pro, but I have the same behavior on a Macbook Pro using Windows with Bootcamp.
What is happening ?
How to avoid these artifacts ?
All the best !
hi Thomas, I believe this is simply different driver implementation for undefined behavior. in the GLSL doc for the pow function it says: "The result is undefined if x<0 or if x=0 and y≤0"
so i think the main issue is in the shader. Same for those cone shapes, I think the shader needs to do a better job of handling the lighting calculations for the flat plane. I'll take a look, but the nice thing about these gl3 effects is the source is there, so everyone please feel free to suggest improvements!
Finally !!!
Updating line 107:float spec= pow(clamp(dot(normalize(Vn + lightVec), Nn), 0.0, 1.0), frontMaterial.shininess);
float nh = clamp(dot(normalize(Vn + lightVec), Nn), 0., 1.0);
if (nh < 0.) {nh = nh * -1;}
if (nh == 0.) {nh = 0.00001;}
float spec = pow(nh, frontMaterial.shininess);
(Yes I know, there are conditional branching....)
[EDIT]This came from a test I did to see how Mac and Windows hands differently pow in opengl.
For "tb.points.lights.jxs" the solution is in fact simpler. Because of the "clamp", the solution is to adjust the minimal value of clamp. Like this:float spec= pow(clamp(dot(normalize(Vn + lightVec), Nn), 0.00001, 1.0), frontMaterial.shininess);
cool, thanks for sharing your solution! i'll look at integrating this into the distro.