Hi, 1) I thought I had solved the problem, but on closer inspection this is what is happening in my terrain engine: Since I''m out of texture units (on any 2 TU machine - the most I could reasonably ask for) and I''m drawing the dynamic lightmaps onto the terrain separately, offseting them some distance. If you look at the picture, the white line is the terrain, and the yellow line the lightmap. The green box encapsulates a steep hill that becomes very sensitive to z-fighting since the lightmap moves very close to it. This is the downside of offseting the lightmap straight up at vertexes. Another idea would be to offset the lightmap in the faces'' normal directions, but that would leave gaps at the edges. Other than that I''m pretty much out of ideas - is the only solution really avoiding steep hills in the levels? 2) I''m rendering the scene to texture twice currently (either time for a different purpose) and I think I need to do it a third time as well. I''m aware that there are faster methods out there as glCopyTexImage2D() (such as using ceratin extensions), but is glCopyTexImage2D() really so slow as to eat up 1/3 of the framerate per call? I mean - is that normal for 512x512 textures? Thanks in advance for your input, Crispy

You can offset the lightmap in the direction off the normals then add a cap to the space between them. It might be a bit of a challenge to implement that though. Also you can offset the light map straight up to avoid the cap coming to close to the top of the hill like the picture below:

  ____   cap / /\ \/ /  \ \L   Ti   eg   rh   at   i    n

Yes, the thought crossed my mind. However, a few things to keep in mind before I jump into it:

1) What is the z-fighting currently caused by? I mean - what is it really due to. Answer: floating point error - the two lines (yellow and white) never meet in a perfect world.
2) Implementing a gap fill means that I''m bound to calculate/draw a whole lot of extra polygons - soemthing to keep in mind. These new polys are small - see point 1. They just won''d align, causing the lighmap to "move inside"
3) Coloring/texturing the gaps is a problem because generally a lightmap is divided precisely at face intersections, but now I need to expand these lines/gaps into real quads. I ran a test - implemented the normal solution and what came out wasn''t exactly pretty. These gaps can be huge (on a relative scale). This means that giving them non-interpolated coloring will show up in the final lighmap (as colored lines). Since the breadth of a gap is dependent on the angle at which the two adjacent terrain polygons are, there is no way to precalculate any texture coordinates either...

Anyway - this is what I figure...

Crispy

a 4 channel image at 512x512 is ~1mb so although that is a comparitively large texture, im doubtful it should be that hard on the system.

I know this could sound dumb since you seem like a pretty competant programmer, but altering the near clipping distance on the viewing frustrum can solve problems like this, try 1 or greater.

Also i am assuming you are blending the height map onto the terrain, when doing this make sure that the depth buffer is locked or that depth testing is disabled, then render the lightmaped terrain, you shouldnt need to offset at all since doing this will render the blended surface ontop of all drawn surfaces. I could probably sort you a demo if you like.

"Very funny, Scotty. Now beam down my clothes."

Instead of using a single normal, try using the average of the two normals at the corner to get a smoother transition. Similar to what is used in smooth shading. It wont be totally perfect because sharp points like you have wont really work to well. The course will have to be a bit smoother to look good.

quote:

---

Original post by aleks_1661
a 4 channel image at 512x512 is ~1mb so although that is a comparitively large texture, im doubtful it should be that hard on the system.

I know this could sound dumb since you seem like a pretty competant programmer, but altering the near clipping distance on the viewing frustrum can solve problems like this, try 1 or greater.

Also i am assuming you are blending the height map onto the terrain, when doing this make sure that the depth buffer is locked or that depth testing is disabled, then render the lightmaped terrain, you shouldnt need to offset at all since doing this will render the blended surface ontop of all drawn surfaces. I could probably sort you a demo if you like.

"Very funny, Scotty. Now beam down my clothes."

---

Altreing the near clipping plane should and does not have any effect on the framerate. Can you give me a reference that suggests that?

What do you mean by "locking the depth buffer"?

Disabling depth testing is not a solution when drawing blended objects because you can see through them. That is, you can actually see the same lightmap that is on a farther hill through a hill that is closer to the viewport if the lightmap is large enough.

Regarding the demo - I''d appreciate a working solution although I try to write my own code.

Is it somehow possible to tell OpenGL each time I draw a poly, that "this time I want it to be preferred to any vertices in its vicinity and drawn in front"? In other words, isn''t it possible to dictate the order of preference with some set of glDepthFunc() calls?

quote:

---

Original post by xiros
Instead of using a single normal, try using the average of the two normals at the corner to get a smoother transition. Similar to what is used in smooth shading. It wont be totally perfect because sharp points like you have wont really work to well. The course will have to be a bit smoother to look good.

---

I''m thinking: performance. There is no way to precalculate the possible averages for all of the polys in the terrain, meaning that I''d have to do potentially thousands of additional calculations per frame. Just a sidenote: the kind of lighting I''m doing is effectively wrong as I''m not taking into account the direction in which a lit poly is facing - if a large-biased light is one side of a mountain, I''m also lighting the other...

Crispy

Si je''n''m''abuse, you would like to render multipass since you''ve already eaten all of your texture units, right ?
If so, you could simply use the "standard" multipass technique, which consists in rendering the same object multiple times, but with depth test set to EQUAL. It works very well if :
1- the object is not translucent,
2- every pass uses the same vertices ; if vertices differ 0.0001% (there''s no real limit in fact) it will not work !

Thanks vincoof - correct as usual! It did''t work for me before because I was also offsetting the lightmaps. Works just fine now.

PS - I already posted this a few days ago - I hate stuff that disappears - blaaargh

Crispy