Hello Guest

Problem in the shader when rendering?

  • 1 Replies
  • 3131 Views
Problem in the shader when rendering?
« on: April 14, 2018, 17:38:51 »
I moved on. I figured out how to determine if the point is inside the frustum or not. I did it this way: I just calculated the distance to each of the 6 planes, if it turns out to be negative, then the point does not lie inside the frustum. Implemented this all in a fragmented shader.

Below is the implementation of this shader. I transmit 6 square matrices of size 3 A B C D E F - each of them contains 3 vertices of the plane. In the shader, a method was written that finds the distance between the point and the plane of the
Code: [Select]
distancePointPlane. When the program is started, it independently selects a polygon or does not draw with color. With the transfer of the coordinates of vertices, problems should not exist. The problem at the level of computation in the shader. Help.

Code: [Select]
version 330 core
in vec3 normal_modelspace;
in vec3 vertex_modelspace;
in vec2 TexCoord;
in vec4 vertexColor;
in vec3 coord;
out vec4 color;


float distancePointPlane(float pointX, float pointY, float pointZ, float a, float b, float c, float d) {
        float denom = sqrt(a * a + b * b + c * c);
        return float((a * pointX + b * pointY + c * pointZ + d) / denom);

    }

float distancePointPlane(vec3 point,mat3 matr) {
        float v1Y0Y = matr[1][1] - matr[0][1];
        float v2Z0Z = matr[2][2] - matr[0][2];
        float v2Y0Y = matr[2][1] - matr[0][1];
        float v1Z0Z = matr[1][2] - matr[0][2];
        float v2X0X = matr[2][0] - matr[0][0];
        float v1X0X = matr[1][0] - matr[0][0];
        float a = v1Y0Y * v2Z0Z - v2Y0Y * v1Z0Z;
        float b = v1Z0Z * v2X0X - v2Z0Z * v1X0X;
        float c = v1X0X * v2Y0Y - v2X0X * v1Y0Y;
        float d = -(a * matr[0][0] + b * matr[0][1] + c * matr[0][2]);
        float s=0.0;
        return distancePointPlane(a, point[1], point[2], a, b, c, d);
    }
uniform mat3 A;
uniform mat3 B;
uniform mat3 C;
uniform mat3 D;
uniform mat3 E;
uniform mat3 F;

uniform vec3 light_worldspace;

uniform sampler2D ourTexture;

void main() {
  vec3 n = normalize(normal_modelspace);
  vec3 l = normalize(light_worldspace - vertex_modelspace);
  float cosTheta = clamp( dot( n, l), 0,1 );
  float ambient = 0.05;

  float aF= distancePointPlane(vertex_modelspace,A);//нахожу расстояние от вершины модели до плоскости а
  float bF= distancePointPlane(vertex_modelspace,B);
  float cF= distancePointPlane(vertex_modelspace,C);
  float dF= distancePointPlane(vertex_modelspace,D);
  float eF= distancePointPlane(vertex_modelspace,E);
  float fF= distancePointPlane(vertex_modelspace,F);
  if(aF>=0.0 && bF>=0.0 && cF>=0.0 && dF>=0.0 && eF>=0.0 && fF>=0.0){
   color = vertexColor;
  }else{
    color = texture(ourTexture, TexCoord)*(cosTheta + ambient);
  }
}


*

Offline KaiHH

  • ****
  • 334
Re: Problem in the shader when rendering?
« Reply #1 on: April 14, 2018, 17:59:19 »
Your solution would become much more elegant, if you did not submit three points on the plane for each of those 6 planes, but instead used 6 vec4's each holding the factors a, b, c and d of the plane equation `a*x + b*y + c*z + d = 0`, making your `distancePointPlane(vec3 point,mat3 matr)` (which computes the plane equation from three points on the plane) completely superfluous.
And as I said in your previous post (which you should just have continued answering to), you can perfectly compute the distances IN THE VERTEX SHADER and only perform the `distance >= 0.0` test ON THE INTERPOLATED VARYING `distance` in the fragment shader. This will be correct, since OpenGL performs perspective-correct interpolation of that varying based on your camera projection. This will save you A LOT of computations in the fragment shader.

All of this was already mentioned in my answer to your initial post. Please read it.