Jump to content
  • Advertisement
Sign in to follow this  
benderB

Alternatives to heightfields in terrain representation?

This topic is 5009 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I'm currently reseaching on terrain generation and realized that almost all papers and tutorial use a heightmap to represent the terrain data. As heightfields doesn't allow overhangs and tunnels I'm curious what other data stuctures can be used in the process of terrain generation to overcome these limitations. If anybody could give me some hints or point me to some articles discussion alternatives I would be very gratefull! Thanks, benderB

Share this post


Link to post
Share on other sites
Advertisement
Depth Maps? :P

Sorry me just being silly.

Yeah i would suggest just using a model exported from maya or summet.

Not sure how you would go about doing collision with it.

ace

Share this post


Link to post
Share on other sites
How about parametric representation? Heightfields are not that bad, though. You can overcome the drawbacks (e.g. no overhangs) by additionally placing hand-modelled meshes on top of them.

Share this post


Link to post
Share on other sites
Once I found a website with a 3D terrain engine capable of creating caves, overhangs, archs. It even had a nice demo. The library was open and free. It was discontinued work but looked very good. Search a little in google and you may find it.

Luck!
Guimo

Share this post


Link to post
Share on other sites
Quote:
Original post by darookie
How about parametric representation? Heightfields are not that bad, though.

I have to disagree, terrain heightfield are the spawn of the devil :)

Seriously, heightfields are a very bad representation for a terrain, with more limitations than it's worth. On todays' hardware, there are no reasons to use them anymore.

I personally use a high order parametric system with realtime fractal generation. See the terrain as a 2D signal in the frequency domain. The HOS generate the lower octaves, while the seeded fractal generator adds the high octaves. This allows for virtually infinite detail, controlled terrain shape, and every kind of topographic feature you can imagine (caves, overhangs, everything).

There was a thread (or threads) way back then, where I explained the system in great detail. I'll have to check my bookmarks.

Share this post


Link to post
Share on other sites
Thanks for the suggestions so far! (but keep 'em comming ;))

About the loading of 3d models:
That's not quite what I'm looking for, as I'm more interested in an alternative data model when generating fractal terrain (should have been more specific..).

This "high order parametric system" sounds interesting I'll have to see if I can find some info on that...
Maybe there's a paper or a good link on this topic?

thanks,
benderB

Share this post


Link to post
Share on other sites
The reason why height map is often used is because originally was used coupled with a telemetric system of relevation, using fractals is mandatory because as far as i know is very difficult to 'fractalize' a mapped terrain.
Any thoughts ? i have used a fractal terrain it gave me an huge satisfaction no lod or precomputation required and fast triangle stripping but the main problem was taht i couldn't load an already mad terrain .
by the way if someone know how to 'fractalize' a map please let me know.

Share this post


Link to post
Share on other sites
Here is the discussion Yann was talking about.

http://www.gamedev.net/community/forums/topic.asp?topic_id=145134



-SirKnight

Share this post


Link to post
Share on other sites
I'm doing something like what YannL said but with Catmull-Clark subdivision surface (ie, quad-based subdivision). Subdivision gives you a smooth surface and fractals displace along the surface normal to give detail. When modelling the terrain I also limit the control mesh to only allow quads (no tris, etc) - this is because alot of terrain algos (like LOD) rely on quad patches. To do this I (i) start with a heightfield generated by Terragen, (ii) convert it to a bspline surface (2D array of control points whose surface passes through heightfield) which is actually a Catmull-Clark subdivision surface, (iii) load it into Blender and (iv) the artist can only do operations which remove/create control-mesh quads (eg, extruding quad faces). Also worth noting is the extraordinary vertices (where number of quads at vertex is != 4) create some difficulties with texture blending, generating texture coords, etc, but you'd have those problems with any arbitrary topology terrain.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!