• ### Announcements

#### Archived

This topic is now archived and is closed to further replies.

# Vertex Normals

## Recommended Posts

I was wondering how I should approach this. I know what they are but not how to implement them. I have an array with all the vertices of my triangle strips, and have calculated the normals for each face (well, I made a normal for each set of 2 triangle strips, treating them more like a quad). Should I just run through this array checking for vertices that are equal for what. I just can''t think of specific code to accomplish this.

##### Share on other sites
Hey there, to get a vertex normal, you add the normals of all the faces that use that vertex, then normalize the result. I think you''ll find each vertex has 3 different faces whose normals need to be added and then normalised.

I may post some code later,

FatalXC

##### Share on other sites
I dunno if this works or not, because the 'land' in my game so far is flat, maybe some1 could tell me if this makes sense:

All my vertices are stored like this (bad I know but I'm a beginner)

numstrips_x[polynum][3];
numstrips_y[polynum][3];
numstrips_z[polynum][3];

Where polynum is the polygon number and the '3' represents 3 x,y,z coordinates for each polygon. I have already generated the face normals and transfered these face normals to each vertex on that face and stored this normal in
Norm_Vertex[Polynum][3]; '3' representing this time the normal at each of the 3 points on the polygon.

The following code I ain't sure about, basically what its MEANT to do is search for any points that are the same (therefore the normals at that point should added - normalised later)

for(int u=0; u < TotalPolygonNumber ; u++) //Loop through all polygons
{
for(int y=0; y < TotalPolygonNumber ; y++)
{
if( (((numstrips_x[u][0] == numstrips_x[y][0]) && (numstrips_y[u][0] == numstrips_y[y][0])) && (numstrips_z[u][0] == numstrips_z[y][0])) )
{
Norm_Vertex[u][0] += Norm_Vertex[y][0];
}

if( (((numstrips_x[u][1] == numstrips_x[y][1]) && (numstrips_y[u][1] == numstrips_y[y][1])) && (numstrips_z[u][1] == numstrips_z[y][1])) )
{
Norm_Vertex[u][1] += Norm_Vertex[y][1];
}

if( (((numstrips_x[u][2] == numstrips_x[y][2]) && (numstrips_y[u][2] == numstrips_y[y][2])) && (numstrips_z[u][2] == numstrips_z[y][2])) )
{
Norm_Vertex[u][2] += Norm_Vertex[y][2];
}

}
}

After this I just normalize the normals and assign them to their vertex? Sorry for being long winded' and complex.

Edited by - AbeE on June 26, 2001 10:55:48 AM

##### Share on other sites
How are you calculating your vertices from the faces? Are you using 3-plane intersection? If you are then vertex normals are easy. Just add the normals of the faces that intersect at the vertex then normalise the result.

You really should change your data formats to something nicer. Have a cVector class with all your vector operations, and a cFace class and a cPlane class etc... It will make everything so much easier. You could have my base classes if you want, they are a good starting platform.

If you need more explanation or if I''ve screwed something up, its no problem.

FatalXC

##### Share on other sites
Thanks, that''d be a great help, but I''ve got one minor problem left. I have gotten some type of lighting going, I think its per Vertex, it looks decent enough anyways I think for a first attempt. In fact I''ve gotten the whole terrain done and I''d love you to try it on your system some-time and tell me what kinda frame-rate you get. But before I show anyone I have 1 more question:
At certain areas on my terrain the frame-rate is alot higher than on others, and because of this the movement of the ''camera'' occurs quicker in some areas than others (it all depends on where you look!). Is there anyway I can fix this using the timer of something???
That''d be a great help
Thanks again.

##### Share on other sites
OK, frame rate fluctuations are normally due to overdraw. Doing frustrum culling will help, definitely have back face culling on (especially for a terrain engine!!) and implement a QuadTree for relatively flat terrain, else use an Octree. I''m not sure but maybe using an SBuffer would be good, there are some articles on www.flipcode.com. Alpha blending can also slow rendering down a lot, so don''t complain if thats whats causing it!! I hope I haven''t confused you more!!

I''ll send you my cVector, cVertex, cPlane, cCamera, cTiming, cPolygon classes and anything else i think might be useful!! They work pretty well and are not frame rate linked. What address should I use?

I''d love to see what you''ve made, my address is standingintheshadows@hotmail.com. I have an Athlon 800 and a GeForce 256 DDR.

Cheers,

FatalXC

##### Share on other sites
Sure, I''ll send it to you hopefully tomorrow, I just have a couple of things to do to it first.
See ya

##### Share on other sites
Hey FatalXC:
Could I give u the address of my website to download it off? It would save me emailing it on my crappy modem.

##### Share on other sites
Yeah sure, no problem

FatalXC

##### Share on other sites
But wouldn''t you still have to upload it....?

##### Share on other sites
You could also tell me the framerate you get cause it uses display lists to draw the terrain and it would be interesting to see whether different graphic cards are better or worse at drawing them.
you should also try it in windowed first to check it runs ok on your system so if it were to crash you could ''End Task'' it. Though it shouldn''t cause it doesnt on mine and it uses Nehe''s base code.
Cheers again

http://www.becko.freeserve.co.uk

##### Share on other sites

It ran fine, about 120FPS give or take a bit. Its cool the way you can adjust the water, i reckon you have a really good start there, especially with the terrain generation, some of the terrains I got were very cool . If you put some more textures and stuff on it would even better, and you could see the joins on some of the water textures which didn''t look so flash, but overall, very nice

FatalXC

##### Share on other sites
Thanks for lookin' at it, I added a few things, like when you enter the water there are sound effects on entering and exiting it and when you stay under. Plus I also added a feature that lets you switch between using a display list and just drawing it using a loop every frame at runtime using the 'D' key, so it'd be interesting to see what difference there is in framerates there (though I havent put that version on the site yet)
Also, do you remember what grid options you used when you got about 120fps, thought terrain height shouldnt make any difference. And what computer specs u have.
I have a Pentium3 500Mhz now and a GForce 2 GTS and I get 800fps on a medium grid size. Dunno if I calculate fps right, though some1 said it was ok, it seems ok because when it reads 25 it seems proportionate and at 4 fps it seem right when lookin' at it.

Edited by - AbeE on July 19, 2001 7:07:14 PM

##### Share on other sites
That was on a RivaTNT2 Athlon 700, not my other GeForce.

The height of the terrain would have a huge impact on performance, if you look at a mountain range and you are drawing everything, lots of the mountains will obscure other mountains and overdraw will be very high, but if you have a relatively flat landscape and draw everything, not as much overdraw, which means higher framerates.

The way higher memory bandwidth of the GeForce2 compared to the RivaTNT2 would make a really big difference.

FatalXC

• ### Forum Statistics

• Total Topics
627704
• Total Posts
2978716

• 21
• 14
• 12
• 10
• 12