7 replies to this topic

[luckyyyyyy]

Actually i don't have any problem in calculating the vexter normal vector.. I have done it by average adjucent faces normal approach.

But the issue is, I have a model that contains 119995 triangles, very large number of triangles, I need to change the vertices position of model in the real-time. for example I am rotating the model vertices. So, by changing the vertices position, face and vertex normal vector must be calculated again. When I enable the face normal, obtained FPS is 59 but when toggled to Vertex normal FPS goes down to 1 FPS,

in every single frame two loops are running, vertices position updating and vertex normal calculating, because of large number of trinagles, I think computer processor give up...

Is there any method to speed up the vertex normal calculations? by using GPU ? or any suggestions?

yea one more thing I am also using FBO but no results. I think the issue is loop running by vertex normal calculation. am i right?

At this stage I am running my simulation by using face normals but I wish I can use vertex normal in real-time. What to do ?

void RotateMeshByComputingRotationMatrix(float XRotAngle)
{
	 for (int i=0; i<N_Vertices; i++)
	{
	 	 Rotate_Model_Vertices(i, XRotAngle);
	}
	 for (int i=0; i<N_Trinagles; i++)
	{
	 	 ComputeFaceNormals(i);
	}
	 for (int i=0; i<N_Trinagles; i++)
	{
	 	 ComputeVerticeNormals(i);
	}
}

Thanks.
Lucky

[Brother Bob]

What is the reason you're not just making a rotation matrix and letting OpenGL do the rotation? If you have to rotate manually, just rotate the normals with the same rotation instead of recalculating them.

[luckyyyyyy]

Realy Thanks...
Actually, in simulation, each vertex position must be updated at every single updated frame, so thats why, manual rotation is required instead of OpenGL rotation glRotatef().

yes its working.. I couldn't understand, why i didn't think of it.. to rotate the normals with the same rotation of the model vertices.

[dpadam450]

Quote

Actually, in simulation, each vertex position must be updated at every single updated frame

That sounds completely wrong. Give an idea of the simulation you are doing. If it is something with physics you can instead convert other objects into this ones frame by taking their final world position and then multiplying only all of those vertices of the smaller object by the big obejcts matrix. So the 110,000etc verts remain static and then the smaller things that interact with it that might be 100 vertices, you just put transform those objects. The fact that you posted this and it was a surpise that your fps dropped seems like maybe you are going by a bad approach, so give and idea of what you are doing and why you need those new verts stored.

[slicer4ever]

it sounds more like you need to do another approach to what your attempting to achieve.

modifying nearly 120,000 object's 60 times a second is a tremendous amount of work, since a vertex normal requires one to take the length of all adjacent faces to the vertex, then it requires a sqrt, doing a sqrt 100k times obviously has alot of overhead(hopefully your data structure means that your know the faces ahead of time that are connected to the vertice, if not, here's another huge bottleneck of lookup time).

in short, either try creating another thread to run the simulation in and separate the draw/update routines, use a shader to find the vertex normals on the gpu(this requires knowing the amount of rotation the vertex has done.), or attempt to approach w/e your trying to achieve in a diffrent direction. attempting to real-time the volume of data your attempting to manipulate doesn't work very easily, and your application is probably going to be locked to only very high-end machines.

to be fair, i can't imagine what beast of a machine your working on, that your haven't seen even more bottlenecks.

[luckyyyyyy]

OK this is my code... this code is working 100% perfectly in order to visualize the cutting section by a tool.. actually you can have an idea like a CNC machine. there is a tool that cut the surface of a model.

you can see in the below code I am rotating the model in X-direction and then I update the vertex normal by making another loop. that loop is a making a problem in FPS. and if I don't update the vertex normal vector after "rotating and cutting of the surface" then offcourse I can not see the good visualization of the cutting section.

so how can i update the vertex normal in this kind of situation.. ? thanks

void RotateMeshByComputingRotationMatrix(float XRotAngle)    // glutIdleFunc
{
    float mat16[16];
    float vec4[4];
    for (int i=0; i<nb_Vertices; i++)
    {
        vec4[0] = getVertexPos(i).x;                        
        vec4[1] = getVertexPos(i).y;
        vec4[2] = getVertexPos(i).z;
        vec4[3] = 1;                    

        matrixRotateX(XRotAngle, mat16);                    // get rotation matrix along Y-axis
        VMatMult(mat16, vec4);
        p_VERTICES[i].set(vec4[0], vec4[1], vec4[2]);


        // rotation of vertex normal  but this isn't working
        // when vertices change their position, vertex normal must be calculated again. With the rotation of vertices, vertex normals rotate too.
        //vec4[0] = VertNormals[i].x;        
        //vec4[1] = VertNormals[i].y;
        //vec4[2] = VertNormals[i].z;
        //vec4[3] = 1;                            

        //VMatMult(mat16, vec4);
        //VertNormals[i].set(vec4[0], vec4[1], vec4[2]);
    }

    // when vertices change their position, face normal must be calculated again.
    for (int i=0; i<nb_Faces; i++)
        ComputeFaceNormal(&FaceNormals[i]);

    // when vertices change their position, vertex normal must be calculated again.
    for (int ix = 0; ix<nb_Vertices; ix++)        //    compute the vertices normal of each vertex
        ComputeVerticeNormal(ix);
}

void UpdateVerticesPositionByBoundingBoxOfCuttingTOOL() // // glutDisplayFunc
{
    for (int i=0; i<nb_Faces; i++)
    {            
        if( IsCollision())
            updatevertex(i);    // update x , y, z

    }
}
 

[Brother Bob]

The normal is a vector, not a point, so its W-component must be 0. Besides, don't calculate the rotation matrix for every loop iteration; it will be the same all the time.

[luckyyyyyy]

Thanks.. its works.