Sign in to follow this  

Tettain Normals

This topic is 4843 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Im looking for an easy way to generate normals for heightfield terrain.I tried one from BOGLGP. But it didnt really work. What i need is a tutorials or a pointer from someone in the right direction. Any help would be appreciated. PS: Do you have to assign materials to primitives for lighting to show up?

Share this post


Link to post
Share on other sites
to find the normal of just a polygon you can take the cross product of any 2 vectors which make up that polygon. This would mean that every vertex on that polygon has the same normal.

however, to do lighting correctly on a terrain, you must first find a normal vector for each polygon surrounding the vertex, and average those together to get the normal for that vertex.

*Im still new, so someone correct me if i'm wrong!

Share this post


Link to post
Share on other sites
this isnt the site where i found my model, but you coudl try it:
http://www.flipcode.com/cgi-bin/msg.cgi?showThread=Tip-VertexNormalsHeightMaps&forum=totd&id=-1

...hmmm... cant find the one i based mine off of, but that link should be sufficient information (hopefully) i googled for fast heightmap normals

hope that helps, sorry i coudlnt find the link i wanted
-Dan

Share this post


Link to post
Share on other sites
Yes, i did do my normals using the cross product. But when i ran it the lighting didnt seem to show up.I excpect this is beacuse i didnt set upthe lighting right. Ill look intoit and post back.

Share this post


Link to post
Share on other sites
from the code Ademan555 posted a link to, i came across this


void calculateNormals(){
for (unsigned int y = 0; y<height; ++y){
for (unsigned int x = 0; x<width; ++x){
sx = HeightMap[ ( x + 1 )%FIELD_WIDTH, y ] - HeightMap[ ( x - 1 )%FIELD_WIDTH, y ];
sy = HeightMap[ x, (y + 1)%FIELD_WIDTH ] - HeightMap[ x, ( y - 1 )%FIELD_WIDTH ];
normal[y*width+x].set(-sx*yScale, 2*xzScale, sy*yScale);
normal[y*width+x].normalize();
}
}
}





which *seems* to work. i'm impressed. it's much faster... and A LOT simpler than my method. the code for it is too painful to paste, but here's some psuedocode

calcNormals(){
for(p=each polygon){
p.calculateNormalFromVectors();
}
for(v=each vertex){
average the six surrounding polygons' normals
}
}





ok, so i got a little lazy with my psued... both of the for loops are actually nested loops, but if you're here, you probably guessed that.

anyways, my method is REALLY slow. i have it implemented in my terrain editor right now and it is not NEARLY as fast as the code i posted first. also, mine leaves a lot of room for error since my code is around 50 or 60 lines of code. probably more like 40ish w/out all the debug print statements.

i have yet to test the accuracy of either method, although, if i programmed correctly, the theory behind mine works out... which is fairly simple to understand.

the theory behind the other method is probably the same but not as clear. someone care to offer an explanation on this method?

i suppose i could look at it and figure it out, but i have a paper to write, laundry is waiting to be folded, and this post is already too long.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by domstyledesign
i suppose i could look at it and figure it out, but i have a paper to write, laundry is waiting to be folded, and this post is already too long.


its just a nice and simple way to approximate the normal, even better if you happen to tesselate in the right way. if you have a diamond like shape around the point then only the 4 points next to it matter.

t
/|l-c-r
\|/
b


(and if it doesnt look like that it wont matter much unless you have REALLY ugly and crude terrain where the difference is visible)

if the point to the left and right are at the same height then the x of your normal will be 0 (doesnt matter how high the point itself is).

if you like, imagine you DO use the center point:

x1 = r.y - c.y
x2 = c.y - l.y
norm.x = x1 + x2 = r.y - c.y + c.y -l.y = r.y - l.y

Share this post


Link to post
Share on other sites
Quote:
Original post by domstyledesign
for points? how about six?


,-) thats one reason why i alternate my "diagonal" lines and subdivision scheme for every odd level (getting twice as many lods to select from and getting a regular diamond pattern everywhere).

anyway, basically the point is: you would expect your heightfield to have more or less the same normals, independent of how you tesselate it. and if you really use huge triangles to stretch a 64x64 heightfield to 100x100 squaremiles gamesize then slightly wrong lighting probably isnt your biggest visual problem ,-)

Share this post


Link to post
Share on other sites
you're talking about doing this:

right?

when i implemented that, it made my terrain seem more choppy. but besides that, shouldn't your vertex normal still depend on the 6 surrounding vectors, instead of just 4?

[Edited by - domstyledesign on September 15, 2004 1:13:33 PM]

Share this post


Link to post
Share on other sites

This topic is 4843 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this