Re: [Algorithms] Terrain Normals

[Klaus H. <k_h...@os...>]

----- Original Message -----
From: Pai-Hung Chen <pa...@ac...>
To: <gda...@li...>
Sent: Monday, August 14, 2000 11:55 PM
Subject: Re: [Algorithms] Terrain Normals


> > That's simply a greenish-blue alpha-polygon (no texture). It basically
is
> > one big square polygon that cuts through the whole terrain. The reason
why
> > that does not look too crappy is, because you see the lit terrain
beneath
> > the water.
>
> (1) Is it because "the terrain beneath the water is lit" that make the
water
> look good?

Yes, because it looks as if the lit terrain beneath the water adds
color-variations to the water surface. Normally, however, I'd use an
alpha-blended texture (probably animated) for the water surface. The only
reason why there's no texture in the screenshots is because I'm too lazy to
write a portable image file reader for OpenGL.

> The terrain is lit either with or without lightmap.  Does that
> make a difference?

Yes it does make a difference. Sometime ago, I also tried to use
Direct3D's/OpenGL's lighting engine to render *rough* non-LOD terrain mesh.
I wasn't able to get rid of those Gouraud shading artifacts (as I already
expected), even though the vertex normals were correct. Since then I'm using
pre-lit surface textures, which completely eliminate these artifacts. In
addition, you can use Phong shading and other nice lighting tricks. Also,
pre-lit textures can make the terrain look as if there was a very high
triangle count.

> (2) How do you make the terrain mesh?  It looks like ROAM.

It's not ROAM. It's an implementation of S. Röttger's "Real-Time Generataion
of Continuous Levels of Detail for Height Fields" algorithm. The
implementation is sort of stupid though, as it uses single triangle fans
(glVertex3f <g>) to render the mesh. I could have used a faster method, but
I intend to make the source code publicly available in order to show an
exact implementation of Röttger's paper, and things like vertex-buffered
indexed triangle lists would just destroy the purpose of the sample.

Which leads me to a question... Maybe someone can answer this off-line. Is
there a better *portable* timer than clock()?

HTH,
Niki