Alternatives to heightfields in terrain representation?
Author
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
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
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
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.
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
Luck!
Guimo
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.
Author
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
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
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.
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.
Here is the discussion Yann was talking about.
http://www.gamedev.net/community/forums/topic.asp?topic_id=145134
-SirKnight
http://www.gamedev.net/community/forums/topic.asp?topic_id=145134
-SirKnight
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
