Archived

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

MARS_999

Normals and GL_TRIANGLE_STRIP

Recommended Posts

Ok I am trying to setup my engine to do lighting on the terrain and now have to calculate normals. I am not sure but since I am using GL_TRIANGLE_STRIP and have 4 vertexs calculating a normal using 3 points and two vectors isn''t going to work is it? I mean only half the so called quad would have light right? If this is the case do I have to do the calculations on the 4th point and third vector? Thanks for the help.

Share this post


Link to post
Share on other sites
there are two good reasons not to.

-opengl vertex lighting doesnt look too good
-for a lot of geometry its pretty slow (for me at least, might be my mistake)
-calculating the average normal for every vertex is a pain (though you''ll do that one way or another and there a great shortcuts for grids)
-normals will take up another 3 floats per vertex (in my case not acceptable to require 80mb just for terrain geometry)

-using a normal map allows per pixel lighting
-normal map has 3byte per vertex instead of 12
-per pixel lighting looks far better
-per pixel lighting is only slightly slower than no lighting

btw. again it doesnt matter if you use strips or lists, thats just changing the order of visiting vertices and in no way what they contain.

Share this post


Link to post
Share on other sites
Trienco I don''t have any knowledge about per pixel programming. I am assuming you''re saying using normals on every polygon in a terrain engine would be suicide for speed? What are you referring to when you say a normal map? Thanks for all your help.

Share this post


Link to post
Share on other sites
a normal map would still contain all normals, with red as x, green as y and blue as z. your pixelshader/register combiner/whatever would just have to calculate the dotproduct of this normal and the light direction, multiply the result with the light color and the texture.
bonus: different levels of detail wont have different looking lighting.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
per pixel lighting requires at least a geforce 3/radeon 8500 to run , for my , at this time it''s still an expensive card, MARS , the order of vertices drawn with tri strips goes like this :

triangle 0 : v0,v1,v2
triangle 1 : v2,v1,v3
to find the normals per face get the cross product from the difference of each 2 vectors per face, as for the normal per vertex you will need to average the normals of the faces sharing that vertex that''s simply just normalizing the sum of those normals.
feel free to mail me at bytebrain@k.ro for more feedback

Share this post


Link to post
Share on other sites
Trienco: How can you have perpixel lighting ( using a normal map ) WITHOUT using vertex normals? Infact, you''d have to save at least one other vector ( tangent ) to do it, as you''d have to transform the light vector into tangent space before you perform the dot product.

Unless you''re talking about stretching a texture over the terrain, and doing a "bump" on that ( ie, so one pixel equals one vertex ), in which case it won''t look as good as standard lighting because the accuracy just isn''t as good.

Death of one is a tragedy, death of a million is just a statistic.

Share this post


Link to post
Share on other sites
Trienco:

I am curious, what video card can you possibly be using which supports normal maps yet is "slow" when rendering vertices containing normals?

Share this post


Link to post
Share on other sites
hm. that might be the reason.. im having scenes with 50k-200k

do you have a demo of that? i cant imagine 8 lights making no difference.

its a basic gf3 btw. but i thought gf2 also had register combiners. after all per pixel lighting was their great hype when they introduced it *confused*

Share this post


Link to post
Share on other sites
I guess I need to ask this since I am becoming confused. I have my terrain engine up and running, it also has textured polygons. Now if I add in lighting which I need normals for right? Will lighting still work after I have applied textures? If so how is going to look? Does anyone have a screenshot with lighting and a textured terrain engine? What I am trying to do is, allow the user to see that their is valleys and hills without having to zoom in really close to see them. As of right now its difficult to see them without getting in real close. Thanks

Share this post


Link to post
Share on other sites
You only need a normal and tangent for per pixel lighting if the normals are in tangent space. Storing the normal map in world/object space (pretty much the same thing with terrain) and doing the dot product in that space is just fine and saves you the setup. It would lead to problems with repeating but unless you require that you should be fine.

Share this post


Link to post
Share on other sites
Trienco:

I take it you''re doing super-low res bumpmapping on that terrain? Like, one texel per vertex? Because, that lighting doesn''t look very per-pixel to me, infact it looks rather alot like per-vertex...

Death of one is a tragedy, death of a million is just a statistic.

Share this post


Link to post
Share on other sites
Ok, no one answered my question about normals and lighting if I am texturing. I guess I do still have to calculate normals for either each triangle or each vertex. I am thinking each vertex would look better than each triangle? Thanks for all the info. BTW Trienco that image looks good. How are you smoothing out the terrain? You bumpmapping it or you rendering every 2nd vertex? I am right now rendering on a 1024x1024 grayscale map ever 2nd vertex to smooth out my terrain. Thanks

Share this post


Link to post
Share on other sites
quote:
Original post by Trienco
hm. that might be the reason.. im having scenes with 50k-200k

do you have a demo of that? i cant imagine 8 lights making no difference.

its a basic gf3 btw. but i thought gf2 also had register combiners. after all per pixel lighting was their great hype when they introduced it *confused*


Yes, download Eternal Lands. There is no option to turn off the lights (since the sun is a light in the first place), but during my debugging tests, I noticed no difference in the FPS counter between lights on/off.


Height Map Editor | Eternal Lands | Fast User Directory

Share this post


Link to post
Share on other sites
quote:
Original post by python_regious
Trienco:

I take it you''re doing super-low res bumpmapping on that terrain? Like, one texel per vertex? Because, that lighting doesn''t look very per-pixel to me, infact it looks rather alot like per-vertex...


hehe, caught me. yes, as normal and height map have the same dimensions, for the hightest detail level its one normal per vertex. depending on how well you can compare the texture filtering to interpolating the normals its phong rather than gouraud. though i might be missing other fundamental differences i understand that gouraud or vertex lighting would calculate the "brightness" at each vertex and interpolate that across the face, while phong interpolates the normals and does the calculation for every fragment.

the benefit of this is that low res patches look more like the high res patches (depending on the angle, from straight above theres no difference between two and 5million triangles).

i dont like the term "per pixel lighting" anyway. outside of raytracing, is there even a way to do it per pixel? but i guess per fragment lighting just didnt sound good enough.

smaller heightmaps or bigger normalmaps should give better results (i wonder if a little noise in the normalmap would produce an acceptable effect to make it less smooth).


trying to have a look at el, thought it would hang the first few times. then the message about not reading the license (that would appear every time, no matter what) made me close it a few times.
actuall while typing this im still waiting if anything happens...
sorry, either its taking more than 5 minutes or it doesnt like my system.

Share this post


Link to post
Share on other sites
Cool. How are you going to cope with self-shadowing? You might want to take a look at horizon mapping techniques for performing self-shadowing of bumpmaps. I''ve lost the URL for the paper that described it, but it isn''t hard to figure it out for yourself anyway. I remember the author using 8 different horizon directions, and interpolating between them to get an approximate horizon for an arbitary direction. Also, using horizon maps to get the illumination of a point looks nicer ( and is more correct ) than the lambertian model.

( Here''s a link to a good aricle on horizon mapping and it''s applications )

Death of one is a tragedy, death of a million is just a statistic.

Share this post


Link to post
Share on other sites
So am I correct that I still need normals to be calculated if I want lighting even if I have textures applyed to my polygons? And if so should I do it for each vertex or each polygon? Thanks

Share this post


Link to post
Share on other sites
so far i didnt think about self shadowing. shadows in general were briefly on my mind, but at the moment im rebuilding it from scratch (except the index buffer stuff, that gave me headache enough for one life). in fact the part above reminded me to this time modify the error not only by distance but by view angle.

didnt have a closer look at shadowing at all im afraid, so i guess the naive idea of rendering from the suns point of view and somehow using the stencil buffer wont get me far ,-)

doing it for a lightmap was easy and even my silly approach to make the shadows softer worked quite well (for each point count the steps the line to the sun is below the terrain, stop at around 10 and for low numbers make the shadow a little less dark).




the normals. you will still need them in one way or another and as long as you dont want any sharp edges you should do them per vertex. calculate the normal for each polygon and average those that a vertex is part of. or, if your heightmap is evenly spaced and you dont want lots of code and headache theres a lovely gem in one of the gpg books. its rather obvious if you think about it.

for a vertex at x,y:
h1=height[x+1][y];
h3=height[x-10][y];
h2=height[x][y+1];
h4=height[x][y-1];
float normal[3]={h1-h3, 2, h2-h4};

normalize it and your done.

Share this post


Link to post
Share on other sites
SO you suggest per vertex if I want a more smooth looking lighing. I don''t want my lighting to look very blocky. So I need to calculate the normals for each vertex(X,Y,Z) and then take the avg of all 4 vertexs since I am using GL_TRIANGLE_STRIP and normalize that value? Then with that value I use that value in the glNormal3i() for all 4 vertexs?

Share this post


Link to post
Share on other sites
For a start, look into vertex arrays. Secondly, you want to use vertex normals, so one normal per vertex. You''d first calculate the face normals, then for each vertex, grab which faces use it and averge their normals to gain the vertices normal.

Death of one is a tragedy, death of a million is just a statistic.

Share this post


Link to post
Share on other sites
About self shadowing:

I just did a raytrace. For each point trace a ray in the direction of the sun, if it intersects the terrain, that point is in shadow. Of course, that provides shit shadows, so I just put the resulting lightmap through an average filter. 4 times. That provides adequate shadows. Just.

( Old screenshots [1,2] of my engine showing these shadows. ).

Death of one is a tragedy, death of a million is just a statistic.

Share this post


Link to post
Share on other sites
hm, averaging seems to make a lot more sense *g*.. but i dont think i can do this in real time for 2.35million points anyway. just like occlusion culling causes head ache, if you want it real fast AND without requiring much memory.

Share this post


Link to post
Share on other sites
I''m just about to add occlusion culling to my engine. I''m using the horizon at each point to decide if it''s visible or not, and it''s a rather fast comparison. Well, I say point, more like sector really. There''s a decent paper on vterrain.org that explains the process.

Death of one is a tragedy, death of a million is just a statistic.

Share this post


Link to post
Share on other sites
Python how are you getting your terrain to be so smooth and not so square or blocky looking? I have used a smoothing function and have not gotten those results. I have tried rendering every 2nd vertex and still doesn''t look like yours. Do I have to try and render a larger number between vertexs instead of 2? My terrain still looks to much like triangles. I don''t have bumpmapping, or lighting done. Will that help smooth out my terrain? Thanks

Share this post


Link to post
Share on other sites