I was thinking of something like a bunch of bezier curves, with the center of each tile being a control point. This would let you get a very smooth terrain instead of being restricted to triangles. It also gives a perfect setup for level of detail. Just use a lower tesselation count for objects farther away. Is this practical? It seems like it would be a lot of work for the cpu, but then again there is no need to worry about a more complex level of detail system. The GPU would also be rendering more than it would with a standard triangle mesh, and texture coordinates could be a pain. Opinions?

Personally I wouldn''t go with this, for the reasons you mentioned below. Do not think it''s flexible enough. However, there are already a few engines/games using this technique, and hardware support for bezier curves and higher level patches is up and coming.

You might look into this technique:

http://www.lighthouse3d.com/opengl/terrain/index.php3?smoothing

It allows you to smooth normal terrain to the point where it is just about as smooth as bezier curves.

quote:Original post by Raloth
I was thinking of something like a bunch of bezier curves, with the center of each tile being a control point. This would let you get a very smooth terrain instead of being restricted to triangles. It also gives a perfect setup for level of detail. Just use a lower tesselation count for objects farther away. Is this practical?

Yes. I exclusively use HOS (primarily NURBS) to create and render terrain. I also add a little realtime fractal detail to it, but the basic shape are defined by HOS. The greatest advantages over a simple heightmap is the extreme flexibility (your terrain can have any shape your like, overhangs, caves, cool rock formations, etc) the very efficient LOD, and the low memory consumption. Now, pure HOS terrains tend to look a little too smooth and 'mathematical', but adding some fractal detail to it solves that issue. CPU hit is higher than a HM, but if you do lazy evaluation and caching, it isn't that bad at all.

I would encourage you to try it out. Once you have a well working HOS terrain system, you'll wonder how you ever lived with heightmaps before Suddendly, they seem so extremely restrictive.


[edited by - Yann L on October 6, 2003 3:34:56 PM]

Personally, I really like the idea of using Beizer curve to render terrain, because I really hate using trangles. I try not to confrom to "normal" idea''s to much, it can be a bad thing in some cases... such as the case of using triangles to render terrain...ugh!

The CPU time might a little slow, but I think that it is well worth the results you get using a Beizer curve. NURBS are a nice idea too

Cool Yann . How do you handle keeping things over the terrain when you can have vertical cliffs and overhangs? I can''t even figure out how I would do that. All of the pictures I have seen don''t demonstrate overhangs or caves. Do you use the OpenGL (I assume you use OpenGL from some messages I have seen) functions to tesselate it or do you do it yourself?

Indeed very cool Yann.

Maybe I _should_ take a look at it, and not be restricted to my old habits. A couple of questions:

- what kind of data do you use to create the terrain (ie where do you get the control points from)?

- how do you do overhangs with this scheme?

- what about texturing the whole terrain + overhangs (what technique)

- aren''t there already some graphics cards which support hardware calculation of higher order surfaces?

- wasn''t there a snowboard game of some sort which already used this technique for their terrain?

Thanks,

Edo

The SSX games on the PS2 use it I believe. This is why I was interested. Some of the screenshots of newer games have the terrain looking so smooth and detailed. I really want to know how they do it .

when using HOS for terrain rendering, how is the physics done? You just dynamically evaluate the surface functions as needed for physics calculations? or do you generate a heightmap from the surface that is used for physics...

Anyone have any experience with this? YannL perhaps? Curious, because I see the advantage of surfaces for terrain but on first thought it seems like it would also up the cost, immensely, of doing physics code on that terrain.

quote:Original post by edotorpedo
- what kind of data do you use to create the terrain (ie where do you get the control points from)?

Mostly from artists. They design the overall look and feel of the terrain, on a coarse level. That''s very easy and quick with NURBS. It is typically done in a modelling package that provides native NURBS support (3DSMax, Maya, etc). He can also add fractal generation directly onto the control points, split regions of the terrain into smaller patches, etc. It''s basically human-assisted fractal generation. This allows for a precise control on how the terrain will look like afterwards.

quote:
- how do you do overhangs with this scheme?

Well, the terrain is just a parametric object. There are no limits on the topology, you can do whatever you want. You could even render a 3D NURBS character with the terrain shader applied... As mentioned above, the artist creates a very rough shape of the terrain. Including overhangs, caves, whatever you need. A fractal system adds the details.

quote:
- what about texturing the whole terrain + overhangs (what technique)

Well, that''s a little bit more involved. You can simple use parametric texcoords, derived from the HOS splines. This works more or less OK, but can show weird stretching on certain parts. A better approach is to use a 6-planar mapping with seam blending. Similar to the ''box'' UVW mapper in 3DSMax, but with blending to remove any visible seams.

quote:
- aren''t there already some graphics cards which support hardware calculation of higher order surfaces?

Yes, basic support is already available. But with future support for überbuffers and even more flexible vertex and fragment pipelines, the GPU will be able to fully tesselate the parametric terrain without CPU assistance. That''s why I would consider this technique very well suited for future 3D cards.

quote:
when using HOS for terrain rendering, how is the physics done? You just dynamically evaluate the surface functions as needed for physics calculations? or do you generate a heightmap from the surface that is used for physics...

Either you use the tesselated version to compute the physics, or you directly use the parametric representation. I do the later, and that for two reasons: first, once 3D cards will fully do the tesselation on the fly, you won''t have an easy access to the triangle data anymore. And second, because a parametric surface is a continuous mathematical equation, the physics evaluation is much more precise than on a polygonal surface. It takes more CPU time, sure. But there is always Moore''s law And since the tesselation part will soon shift to the GPU, the CPU is free for more accurate physics.