quote:

---

Original post by 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

---

Question: how do I actually check if the normal is pointing in the correct direction? Isn''t calculating the cross product basically what is supposed to do that? And yes, I''m calculating the cross product based on three points on the plane (face) and then normalise them - should be enough IMO.

I haven''t run any tests because I haven''t had the time.

quote:

---

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

Granted, but they are correct - that''s a teeny weeny little fault in my heighmapping code which messes up the edges of the heightmap (drags certain points down to zero level) - I think I''m reading too much/little data somewhere, but that''s pretty much irrelevant right now

Crispy

---

When you calulate the cross product of two vectors, the resulting vector will be at ninety degrees to both vectors, and thus perpendicular to the plane. However, this still leaves two directions it could be pointing - in your case it could point up out of the ground or down into the ground. The direction of the normal is determined by the right hand rule (according to a website I just checked). This means that as long as you are consistent in the manner in which you choose your initial vectors, all the normals will point in the same direction.
examples:

    ^ vector 2                       ^ vector 2    |                                |    |                                |    +----> vector 1    vector 1 <----+  normal points           normal points     upwards                 downwards 

All the normals in the screenshot you posted do indeed point the correct way (upwards, out of the ground). When you draw them do you just draw a line from v to v + ((a × b ) / |a ||b |)? (where v is the position of the vertex and a and b are the sides of your polygon, pNode->Corners[2] - pNode->Corners[3] and pNode->Corners[1] - pNode->Corners[3] respectively)

Enigma

Edit: oops, had the vectors in the diagram the wrong way round!

[edited by - Enigma on November 26, 2002 11:07:03 AM]

the only thing I can suggest otehrwise is that your camera position isnt'' accurate... Or you are using glTranslate before drawing the terrain...

it looks from the image that the camera position calculated is lower than the real position realitive to the terrain.

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

I''m workin on some research at Univ of Maryland Graphic lab, and we had a problem like this recently. After double checking all our math and code, we realized that some of the tri''s were winded in the wrong direction, thus normals going the wrong way. I''m not sure if you checked it, but it might be worth looking into. Good luck.

All of the quads are drawn consistently ccw, the world is never either translated or rotated. this is the code i'm using to draw the normals:


//the function to calculate the vector
TVector3f VecTrim(TVector3f pOrigin, TVector3f pTarget, float pTargetLength)
{
if(pTargetLength == 0)
return pTarget;

float Length = VecDistance(pOrigin, pTarget);

//NOTES: Length is ALWAYS positive and greater than zero.
//due to internal inaccuracies, sometimes
//1.0000 can be treated as a number greater than 1.0000,
//resulting in wrong output. The constant here SHOULD be
//1.0(0)
if(Length > 1.1f)
{
pTarget = (pTarget - pOrigin) / Length;
pOrigin += pTarget * pTargetLength;
return pOrigin;
}
else
pTarget -= TVector3f((pOrigin - pTarget) * Length * pTargetLength - (pOrigin - pTarget));

return pTarget;
}


//draw the normal
glVertex3fv(*pNode->Corners[0]);
glVertex3fv(VecTrim(*pNode->Corners[0], *pNode->Corners[0] + pNode->Normal, 25));


As for camera position inaccuracies - if the camera class were in fault, frustum culling shouldn't work and I believe the effects would be more evident; and besides - all camera movement etc adds up just fine - and, finally, no matter what the camera position is, i'm using the same vector values to cull the faces - so either way this shouldn't pose a problem...

PS: I encourage people to check out the link I posted above - it's not there to prove something related directly to this particular thread - it's there because I found it while browsing and I see it as a thing of great potential (unfortunately for static objects only as of now) - so check it out!

Crispy


[edited by - crispy on November 27, 2002 1:34:17 PM]

Well, I can''t see anything wrong with your code then. I can only suggest that you try the two tests I recommended before and hope that they shed some light on the problem!

Enigma