I zoom by mooving the object closer to the camera. FOV is not affected.
If the FOV is not changed, the multiplication by w coordinate should be sufficient. At least when I modified some GLSL demo to emulate that, the thickess appeared as constant (at least based on measurements in MS Paint).
Just tried this solution. So…it has failed 
Threshold = 0.3 * gl_FragCoord.w was used.
Seems i’m realy stuck with it… and nobody knows how to help
When I modified one GLSL example by adding following lines:
To VS:
MCPosition = vec3 (gl_Vertex); <-- this was actually already here
w_coordinate = gl_Position.w ;
To PS:
float threshold = 0.01 * w_coordinate ;
float Dist = abs( dot( vec4( MCPosition.xyz, 1.0 ), vec4( normalize( plane.xyz ), plane_offset ) ) ) ;
if ( Dist <= threshold ) {
gl_FragColor.xyz = float3( 1.0, 0.0, 0.0 ) ;
}
I got this
And again something is going wrong.
Finally i have this code:
VP
varying vec3 Position;
varying float WCoord;
void main()
{
Position = vec3( gl_Vertex );
gl_Position = ftransform();
WCoord = gl_Position.w;
}
FP
varying vec3 Position;
varying float WCoord;
uniform vec4 SectPlane;
uniform vec3 P1;
uniform vec3 P2;
uniform vec3 P3;
uniform vec3 P4;
bool SameSide( vec3 p1, vec3 p2, vec3 a, vec3 b )
{
vec3 cp1 = cross( b-a, p1-a );
vec3 cp2 = cross( b-a, p2-a );
return dot(cp1, cp2) >= 0;
}
bool PointInTriangle( vec3 p, vec3 a, vec3 b, vec3 c )
{
return SameSide(p, a, b, c) && SameSide(p, b, a, c) && SameSide(p, c, a, b);
}
void main()
{
float Threshold = 0.1 * WCoord;
float Dist = abs( dot( vec4( Position.xyz, 1.0 ), SectPlane ) );
if ( Dist > Threshold ) { discard; }
if ( !( PointInTriangle( Position, P1, P2, P3 ) || PointInTriangle( Position, P4, P2, P3 ) ) ) { discard; }
gl_FragColor = vec4( 1.0, 0.0, 0.0, 0.0 );
}
In this case i also have an unwanted scaling of the line.
Try mapping abs(dot(Position,SectPlane)) to color and see if you get what’s expected.
I swear this dot product is correct since the section itself is rendered exactly as it was expected
I agree that section is rendered exactly WHERE expected but since it’s width scales, then there is a bug somewhere, right?
Could you map that dot product to color anyway?
Scale that dot product by some constant value, so the color would change slowly over entire mesh. Then make 2 screenshots with different zoom, but make sure that object is fully visible in both screens.
Whan I tried your shaders in the sample application, the scalling was not there. How do you construct various matrices (modelview & projection) used to display the object?
He is passing plane’s equation and triangles via uniforms and compares them with gl_Vertex
It probably means that his object space is the same as world space and the plane is defined in the same space (it should be if this is supposed to work without any transformations in vertex shader).
Matrix contents don’t affect this shader in any way other than gl_Position = ftransform(). This causes entire geometry to zoom in and out on the screen, but using .z or .w coordinates should suffice to fix it. Unless his plane equation is wrong - normal vector not normalized or something like that. This is why I asked to map that dot product to color to see what really happens with point<->plane distance.
Plane equation seems to be correct and it is normalized. I will post screenshots on monday.
Originally posted by k_szczech:
Matrix contents don’t affect this shader in any way other than gl_Position = ftransform().
Which is important thing since it calculates the w coordinate and onscreen size of the object. His shader works in my testing application which does have constant plane equation and constant scaling in modelview/projection matrices so it is reasonable to assume that one from those two things changes when the object is zoomed in his application.
Because on the screenshots the plane is always at the same position on the object, I did assume that the plane is stored in object space and does not change during the zooming so it is reasonable to assume that the change might be from the matrix.
Both model and plane are defined in the same object space.
Here are the screenshots with the visualized distance.
As you can see, it is tightly connected to the model.
Thanks, that eliminats half of possibilities 
So we only need to calculate the threshold properly. It should be proportional (linearily) to distance from pixel to camera measured along eye plane’s normal vector. We don’t care what the FOV is or how far the eye plane is - if object’s distance is 2x bigger then threshold must be 2x bigger, too.
So if you have all transformations in MODELVIEW matrix and you only have perspective in PROJECTION matrix, then threshold should be multiplied by z coordinate of vertex transformed by MODELVIEW matrix:
threshold = vec4(gl_ModelViewMatrix * gl_Vertex).z * 10.0 / viewportSize;
Just trmember to make sure you on’t put any transformations to PROJECTION matrix except for glFrustum.
A little performance hint: note that threshold and distance to your plane will change linearily across polygon’s surface and therefore can be calculated in vertex shader, but if you have lots of small polygons then it would be better to leave that calculations in fragment shader.
Also - instead of performing 2 triangle hit tests you could define 4 planes and just test dot products. These dot products will also change linearily, so only >0 test must be done in fragment shader.
Again i’m doing something wrong… The value of my vec4(gl_ModelViewMatrix * gl_Vertex).z is… zero
How do you know it’s 0? If you map it to color then perhaps it’s a negative value and just appears black?
You are right! It was just negative! I’ve put an abs() to your equation and made some other changes:
Thresold = 2.0 / abs( vec4(gl_ModelViewMatrix * gl_Vertex).z / ViewportSize)
And now it is all fine!
Many thanks to everybody who was spilling inks into this thread during 2 weeks. Personal respect to k_szczech. Your help is realy appriciated!
Topic is closed.
This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.