Oh by the way, drop lighting altogether. It''s a waste of processor. (it''s also nearly impossible to code using ROAM so far as I''ve figured out. If anybody can show me wrong, please go ahead!).

Use a lightmap. Use some other application to generate a lightmap for your terrain (try WILBUR, it''s free). Then using multi-texturing, texture both your terrain texture, and your lightmap (a darkmap is the easiest way).

The negative to this is that game lighting changes will not affect your landscape''s lighting. I''m thinking of using dot-product bump mapping to light the landscape in a third texture operation to overcome this, but honestly, I don''t think this is a large problem.

With lightmaps you have one other huge advantage (other than the performance of not having to code your normal averaging). You can (at any point in time) generate a RAY-TRACED lightmap texture using another application, or coding this yourself. That way your mountains can actually CAST SHADOWS on terrain. This makes for a VERY cool effect when walking around your landscape.

Cheers, more great advice

I''ll give the 5-point clipping method a try and see how it works out.

Since this was my first terrain engine, I''ve basically took all the simplest ideas from all the articles I''ve read. I calculate the variance just by taking the actual height difference between the node and the mid-point of the edge the node is on (so 6 errors to calculate per quadrant). Then I do-

if ( error * threshold > distance ) -> split the quad

I know from the results I''m getting that this isn''t a good method, so I''m going to read the articles again and see what I should be doing. I have 4 levels of detail and only the first and last are used heavily. I''m also getting polygons wasted on entirely flat sections.

Still, that''s all totally fixable given a week or two more work.

Acutally the algorithm-

if ( error * threshold > distance ) -> split the quad

is ok afterall, it was just a dumb bug. I have much better polygon distribution and far less popping with the bug fixed.

A word of warning. If you want to reduce popping, then you should not simply check your top level polygons for accuracy, and failing that, recurse into more detail.

What happens with your algorithm if there are 2 small mountains in each triangle of your quad, but the middle point lies on the same plane as the 3 surrounding points? You won''t recurse to get those mountains, right?

That''s why you need to build a variance tree. It''s a tree (quad tree if you''re using quad trees, bintree if you''re using roam) that mirrors your normal subdivision. It contains a variance value (difference between real and interpolated height) for each stage of your normal subdivision. With quad trees, it should be a quad tree, with roam it should be a bin tree. Generate the whole tree in advance. So your first level (top level node) should contain the variance without any subdivision. Just the top level difference at the middle. Then you subdivide into 4 quads right? Well, then add the variance for all those 4 quads (their midpoint variance) into the tree. Keep going until a vertain point (usually until a resolution of 8x8 point samples).

The catch is that what you should really do is store the MAXIMUM variance at each level. So at the top level, don''t store just the variance based on the difference of the top point. As you keep recursing down, and checking variance down lower, bubble the LARGEST variance found all the way up to the caller. So if you had that twin mountain situation I described earlier, you would get that large variance (perhaps after 2 subdivisions) bubbled up to the top level. So your top level would store the variance from a few levels down in fact!

Of course, the next level deeper would most likely store the SAME variance figure as the top one, because ALL nodes should keep the largest value they find. It''s either going to be the one they calculate from themselves, or the one that is bubbled up from a deeper recursion, which you know is the biggest value found deeper down, since you keeped bubbling up the MAX value found.

Did I make sense? It''s a little hard to explain.

You only need to store this stuff as a BYTE to save storage because it will be a large tree.

So you''ll typically have values like 17, 6, 4, 23 in your tree. This represents how badly off your approximation is at any given point (considering also deeper nodes because of the bubbling). Now you need to factor in distance. A value like 4 might NOT be ignored if close to the camera. But it would be in the distance. However a value of 23 should never be ignored even in the distance, because mount everest might vanish.

Normally you would (by some factor that you will have to tweak yourself) divide the variance by the distance. So 23 would be reduce to 2.3 if it was 10 units in the distance (well, 2 since we are talking integer division of course). You may have coded to ignore variances of 1, but keep all those >1. If you did this, this moutain would only vanish at 20 units distance.

You get the idea?

When implimented like this, popping should nearly vanish, because distant objects that deform the terrain significantly should be retained even in the distance.

Best of luck,

Greg.

(still working hard on my terrain engine acutally, I''m not an expert, but I''m getting there after hours of toil. Geez what a pain these things can be).

Don''t even THINK about texturing yet (well, not advanced texturing).

Are you using gouraud shading? It can be done in quadtrees without much trouble, but it''s expensive. ROAM it''s almost impossible. I like lightmaps myself. You should give them some thought.

Terrain programmers seem especially generous, thanks again

I had already noticed that problem, but hadn't come up with a solution to it. Just testing accuracy against 3 nodes per triangle at the top level (out of 64 nodes per quadrant of a patch) means quite significant features can be completely missed. I definitely need to fix this, plus there's the time I'll save by not calculating the variance on the fly. Preumably it would have to be an implicit quad-tree to keep the size down.

..and the explanation did make sense, cheers

Simon.

Edited by - simon_brown75 on July 24, 2001 3:08:52 PM

Well, all the posts have been really helpful, so a big thank you to everyone

Just an update on my progress - I'm now using a 1K*1K height field, and I'm now using a pre-calculated variance tree. I'm about to add 2 more detail levels at the top end (I'm using the top-down method), which should help reduce the triangle count. I'm also about to add the code to 'bubble-up' variances that are higher than the parent quad.

2nd update - added bubble sort of variance data and fixed frustrum culling. Added 2 more levels of detail, which has improved frame rate considerably.

masterg/
What kind of racing game? Something with off-road buggies would be good with a terrain engine. Or even something like a free-form version of wipeout. Or even racing down canyons in aircraft.

Edited by - simon_brown75 on July 25, 2001 11:54:54 PM