Normals and GL_TRIANGLE_STRIP

Mars_999
Unregistered
 
Post: #1
I am wondering about calculating normals with GL_TRIANGLE_STRIP? You send 4 vertexs to TRIANGLE_STRIP and I have only two vectors from three points. So I am guess I am going to have to calculate from 4 points 3 vectors? If I don't I will only have a lighted half quad surface due to only three vertexs are being used out of 4? Hope I am making sense. Thanks
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #2
You're not making sense.

Triangles have the same number of vertices/sides regardless of what mode you use to submit them to OpenGL.
Quote this message in a reply
kberg
Unregistered
 
Post: #3
I think what he's talking about is trying to do face normals with triangle strips? Not sure completely; if you could restate the problem Mars_999 it would help.
Quote this message in a reply
Member
Posts: 177
Joined: 2002.08
Post: #4
As everyone else said, calculating vertex normals has nothing to do with the primitive used to send them to GL.

If you don't send a normal for a particular vertex, it will just use the last normal you did send, so if a quad has 4 vertices and 3 normals then 2 of the points will have the same normal. This won't cause any real errors, but the lighting won't look correct.
Quote this message in a reply
Mars_999
Unregistered
 
Post: #5
Quote:Originally posted by Mark Levin
As everyone else said, calculating vertex normals has nothing to do with the primitive used to send them to GL.

If you don't send a normal for a particular vertex, it will just use the last normal you did send, so if a quad has 4 vertices and 3 normals then 2 of the points will have the same normal. This won't cause any real errors, but the lighting won't look correct.


That is what I meant to say. The lighting won't look correct. So what do I do to correct the problem. Sorry for the bad wording but working 12hrs and then coding after that the brain is mud. Thanks
Quote this message in a reply
kberg
Unregistered
 
Post: #6
I've got code in my model loader class that will generate vertex normals for .obj's that have none. I'd give a synopsis here now, but I just came off 48hrs of work with 3 hrs sleep to finish off a final project ZZZ.

Give me a few hours to sleep and if you're still having probs and no one else has answered it yet I'll put something together.
Quote this message in a reply
Mars_999
Unregistered
 
Post: #7
Quote:Originally posted by kberg
I've got code in my model loader class that will generate vertex normals for .obj's that have none. I'd give a synopsis here now, but I just came off 48hrs of work with 3 hrs sleep to finish off a final project ZZZ.

Give me a few hours to sleep and if you're still having probs and no one else has answered it yet I'll put something together.


That would be great. But I should let everyone know I am working on a terrain rendering engine. I have it up and running but would like to add in lighting now. I am not sure if that is possible due to I am rendering a 1024x1024 grayscale heightmap and using every 2nd vertex coordinates. So I am rendering 512x512x2 polygons = 524,000+ polygons. Ouch. I haven't even added in any .md2 models yet. I am thinking I am going to have to reduce my map size but then the terrain area gets to small. Just a heads up. Reason I want lighting is it is very hard to tell where the valleys are on the terrain unless you zoom in close. Thanks kberg.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #8
Then you don't want face lighting anyway, so I really can't understand your problem now...
Quote this message in a reply
Member
Posts: 196
Joined: 2002.04
Post: #9
Sounds like Mars needs a tutorial. Try the lighthouse3d tutorials the terrain tutorial taught me how to make OpenGL normals correctly. http://www.lighthouse3d.com/opengl/terrain/

Hope this helps,
Iceman

call it like this:

norm[0]
vert[0]

norm[1]
vert[1]

.... etc.

this gives you smooth more visible terrain
Quote this message in a reply
kberg
Unregistered
 
Post: #10
Code:
struct vertex  {
   float x, y, z;
};

void normalise(vertex &vec)
{
   float length;

   length = sqrt((vec.x * vec.x) + (vec.y * vec.y) + (vec.z * vec.z));

   if (length == 0.0f)
      length = 1.0f;

   vec.x /= length;
   vec.y /= length;
   vec.z /= length;
}

void calcnormal(vertex p1, vertex p2, vertex p3, vertex &normal)
{
   vertex v1, v2;

   v1.x = p1.x - p2.x;
   v1.y = p1.y - p2.y;
   v1.z = p1.z - p2.z;

   v2.x = p2.x - p3.x;
   v2.y = p2.y - p3.y;
   v2.z = p2.z - p3.z;

   normal.x = v1.y * v2.z - v1.z * v2.y;
   normal.y = v1.z * v2.x - v1.x * v2.z;
   normal.z = v1.x * v2.y - v1.y * v2.x;

   normalise(normal);
}

void addvertex(vertex& v1, vertex v2)
{
   v1.x += v2.x;
   v1.y += v2.y;
   v1.z += v2.x;
}

Those routines will be needed for the following algorithm

Code:
//I need to make some assumptions about how your data is laid out...
   //I'll pretend that we have an array of vertices somewhere
vertex Vertices[num_verticies];

   //And that your triangles are pointers to these vertices
struct triangle {
   int face0, face1, face2;
}

triangle my_terrain[num_faces];

   //And finally you need somewhere to store your normals
vertex my_normals[num_verticies];

void makenormals()
{
   for (int i = 0; i < num_faces; i++)  // loop through all triangles in your terrain
   {
      // lets pretend your triangles are an array of vertices
      vertex temp_normal;
      int v1 = my_terrain[i].face0,
           v2 = my_terrain[i].face1,
           v3 = my_terrain[i].face2;
      calcnomal(Vertices [v1], Vertices [v2], Vertices [v3], temp_normal);
      addvertex(my_normals[v1], temp_normal);
      addvertex(my_normals[v2], temp_normal);
      addvertex(my_normals[v3], temp_normal);
   }
   //Ok, basically each point has had the sum of the normals of all faces it is a part of added to its normal.  Now we need to re-normalise the result.
   for (int i = 0; i < num_verticies; i++)
      normalise(my_normals[i]);
}

Ok, now every vertex in your terrain has an associated normal. So vertex Vertex[i] has an associated normal my_normal[i].

Now when you draw your terrain, set one normal per vertex and you get a nice smooth appearance.

Code:
void Draw()
{
   glBegin(GL_TRIANGLES);
   for (int i = 0; i < num_faces; i++)
   {
      int v1 = my_terrain[i].face0,
           v2 = my_terrain[i].face1,
           v3 = my_terrain[i].face2;
      glNormal3f(my_normals[v1].x, my_normals[v1].y, my_normals[v1].z);
      glVertex3f(Vertices[v1].x, Vertices[v1].y, Vertices[v1].z);

      glNormal3f(my_normals[v2].x, my_normals[v2].y, my_normals[v2].z);
      glVertex3f(Vertices[v2].x, Vertices[v2].y, Vertices[v2].z);

      glNormal3f(my_normals[v3].x, my_normals[v3].y, my_normals[v3].z);
      glVertex3f(Vertices[v3].x, Vertices[v3].y, Vertices[v3].z);
   }
   glEnd();
}

Haven't really checked this too carefully, so no guarantees about typos, etc...

Hope this helps... Ask if there are any steps you don't understand.
Quote this message in a reply
Mars_999
Unregistered
 
Post: #11
I am going to ask this question because I am unsure, but think that it's correct. Ok, I haven't never done any lighting in my coding except for a spotlight that shines on a gluShere. Anyway in my terrain engine I want to be able to have the valleys and back sides of hills darker than the sides from where the light is coming from. Right now the user will have to zoom in close to determine their is a valley or hill. Right now I have my terrain textured. Am I correct in saying that I still have to calculate normals even with my textured terrain to use lighting? Thanks. Oh BTW this terrain engine is rendering 524,000+ polygons! So is lighting going to be a problem?
Quote this message in a reply
Member
Posts: 196
Joined: 2002.04
Post: #12
Quote:Originally posted by Mars_999
Am I correct in saying that I still have to calculate normals even with my textured terrain to use lighting?


Yes, when you use things like glutSphere() OpenGL already calculates the normals for you.

Quote:Originally posted by Mars_999

Oh BTW this terrain engine is rendering 524,000+ polygons! So is lighting going to be a problem?

On some older machines (like mine Grin) this could become a real problem. Don't worry about it most people are upgrading to Macs that can handle UT2k3 any way.

Iceman
Quote this message in a reply
Mars_999
Unregistered
 
Post: #13
Thats why I ditched my DP 1.25Ghz when I could and now am waiting on the G5. I am a speed freak. I don't like slow downs. I was somewhat disappointed in my Mac performance in UT2k3 even with a Radeon 9700Pro. But this will all change once the G5 ships.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Advantage of GL_TRIANGLE_STRIP? Bersaelor 21 18,284 Feb 17, 2011 07:14 PM
Last Post: Holmes
  Normals Nick 20 8,442 Mar 25, 2005 09:31 AM
Last Post: tigakub
  Normals? Quicksilver 3 2,928 Jan 13, 2003 05:31 PM
Last Post: henryj