Hi, currently I'm seeing a 30% framerate increase by software-culling the back sides of any mountains on my terrain. I guess my math is failing me again, however, because while the normals are facing away from the camera, the face itself is visible, but the engine effectively culls it, leaving holes in the ground. Here's some code, can someone see anything wrong in it?

//calculate the normal
...
pNode->Normal = VecNormalize(VecCrossProduct(*pNode->Corners[2] - *pNode->Corners[3], *pNode->Corners[1] - *pNode->Corners[3]));
...

//the functions
TVector3f VecCrossProduct(TVector3f pVec1, TVector3f pVec2)
{
   //returns the normal
   return TVector3f((pVec1.y * pVec2.z) - (pVec1.z * pVec2.y),
     		    (pVec1.z * pVec2.x) - (pVec1.x * pVec2.z),
                    (pVec1.x * pVec2.y) - (pVec1.y * pVec2.x));
}

float VecMagnitude(TVector3f pVector)
{
   return (float)sqrt((pVector.x * pVector.x) + (pVector.y * pVector.y) + (pVector.z * pVector.z));
}

TVector3f VecNormalize(TVector3f pVector)
{
   return(pVector / VecMagnitude(pVector));
}

float VecDotProduct(TVector3f * v1, TVector3f * v2)
{
   return((v1->x * v2->x) + (v1->y * v2->y) + (v1->z * v2->z));
}


//and finally - the testing is done as follows:
if(VecDotProduct(&(*pNode->Corners[0] - GLCamera->GetPosition()), &pNode->Normal) >= 0)
   {
   //do not draw the poly
   }
  

This needn't necessarily be an error in the code - maybe the fault lies in my head. Either way - can anyone pinpoint it? Thanks in advance, Crispy edit: typo [edited by - crispy on November 24, 2002 6:51:00 AM]

I can't see anything wrong with the maths. The problem may lie in your test, as you discard an entire polygon based on a single vertex. Imagine a very basic mountain (four polys):

plan view:     front view:  +----+  |\  /|           /\    | \/ |          /  \    | /\ |         +----+  |/  \|  +----+ 

The normal at the top points directly upwards. The normals at the base may point directly outwards. If you now happened to pick the top point of your mountain as your test coordinate your current code wil cull the front facing polygon even though it is visible. You should instead test all the vertices and only cull a polygon if all of them are back-facing.

Alternatively you could just use the OpenGL vertex culling extension, which does all this for you!

Hope this helps

Enigma

Edit: corrected pre tags to use angle brackets instead of square brackets!

Edit 2: O.K., the forum decided that my backward slashes in the diagrams were instructions that the line countined on the next line!



[edited by - Enigma on November 24, 2002 8:12:32 AM]

ok, confused here - i was under the impression that a face normal indicates the direction of the front side of that face, regardless of its vertexes. Therefore, shouldn''t it be so that only calculating one normal based on any three points on the plane should suffice to show in which direction the entire polygon is facing. Hence, only testing that one normal should indicate whether the poly is visible or not: if the angle between the viewport and the normal doesn''t fall within 90-270 degrees. Erm - right?

quote:

---

Alternatively you could just use the OpenGL vertex culling extension, which does all this for you!

---

never heard of it - what''s the full name? if you''re referring to simple backface culling by the means of glCullFace() et al, then the reason I''m doing this in software is that this way I won''t have to send a considerable amount of vertexes down the opengl pipeline altogether... natural face culling, if enabled, only takes place in the video card afaik...

Crispy

quote:

---

Original post by Crispy


never heard of it - what''s the full name? if you''re referring to simple backface culling by the means of glCullFace() et al, then the reason I''m doing this in software is that this way I won''t have to send a considerable amount of vertexes down the opengl pipeline altogether... natural face culling, if enabled, only takes place in the video card afaik...

Crispy

---

Have you timed this? Letting OpenGL do your backface culling is fast than doing it in software 99% of the time.

quote:

---

Original post by Anonymous Poster
Have you timed this? Letting OpenGL do your backface culling is fast than doing it in software 99% of the time.

---

As mentioned above, the FPS increases from ~20 to ~29... Then again, my cpu''s (1.4GHz) way too fast for my poor old TNT2.

Crispy

quote:

---

Original post by Crispy
ok, confused here - i was under the impression that a face normal indicates the direction of the front side of that face , regardless of its vertexes. ...

---

This depends on whether you specify your normals per-face or per-vertex. If you specify normals per-face:

glBegin(GL_SOMETHING);   glNormal3f(...,...,...);   glVertex3f(...,...,...);   glVertex3f(...,...,...);   glVertex3f(...,...,...);   glVertex3f(...,...,...);glEnd();

then testing just one vertex should be fine. If on the other hand you specify normals per vertex:

glBegin(GL_SOMETHING);   glNormal3f(...,...,...);   glVertex3f(...,...,...);   glNormal3f(...,...,...);   glVertex3f(...,...,...);   glNormal3f(...,...,...);   glVertex3f(...,...,...);   glNormal3f(...,...,...);   glVertex3f(...,...,...);glEnd();

then you are effectively using one polygon as an approximation to a smooth curved surface. In this case the normals at each point of the polygon are different and while one normal may not point towards the camera, the others may do.

The extension I mentioned is GL_EXT_cull_vertex. I''ve never used it myself, but I spotted it while looking through the OpenGL extension registry.

Enigma

The thing is - with software culling I don''t need to specify glNormal() - I''m culling the faces before I even start sending them down the pipeline! Besides - chech out this paper.

The weird thing about the faces is that only about 5% of them are incorrectly culled and they all seem to be inclined towards the camera rather than away if I draw the normals. I''ve output vertex and normal data and it everything seems just fine.



The face normal is only drawn (from one of it corners) if the face should be culled. As can be seen, most of the normal lines are well behind the hill while some stick out camerawards (imo), but are nevertheless culled using the code in the original post...

Crispy

Seeing the screenshot I''d have to agree. Only a couple of those polygons are potentially symptoms of the problem I described above. I can''t tell what the problem is but I would suggest two tests that might highlight what''s going wrong.

1. Drawing just the normals to the culled polys (i.e. no triangles rendered at all) render the scene at ninety degrees to the camera position, so that all the polys that should be culled have normals that point to the right of the screen. This should demonstrate once and for all whether the maths is as fault or the logic is. If any normals are drawn pointing to the left then there is something wrong with the maths, if not then there is something wrong with the logic. Obviously you will need to render the normals such that you can tell which way they are pointing.

2. Assuming the above test proves there is something wrong with the maths, render the scene axis-aligned. When your test culls a poly based on a normal with a positive z component, repeat all the calculations and print out the results at each stage. This (hopefully) will show where the maths is going wrong.

I''m afraid I don''t have time at the moment to read the paper you mentioned, but I''ll copy the link and hopefully remember to look at it some time.

Let me know how things go

Enigma

Just had another thought - when you do your cross product, do you check that the resulting vector actually points the correct direction? I.e. when you draw the normals in the image you posted, do you just calculate the cross product, normalise and draw that vector from the vertex or do you calculate them some other way?

Enigma

take a look at the top right of that image.. the normals there don't look too correct...

I can't see a problem with the code... looks fine...


I did write a whole bunch of stuff about terrain rendering... with the final note being "but, of course, if you have a tnt, or such, it flips completly..."

I should learn to read all replys first eh

| - Project-X - my mega project.. big things comming soon - | - adDeath - an ad blocker I made - | - email me - |

[edited by - RipTorn on November 26, 2002 6:01:30 AM]