Jump to content
• Advertisement

# World Terrain Generation. What to do next?

This topic is 2142 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

Ok, I have part of my terrain generation process, now I need to know if I've got the right idea for the next part. I have completed making the quad tree "cube-to-sphere" described in http://acko.net/blog/making-worlds-1-of-spheres-and-cubes/ . Now I want to generate the close-up portion using marching cubes. Marching cubes (as far as I know) requires a boxed-in volume to work with. This is a problem because of the following image:

[attachment=17659:Untitled.png]

This is the result at one of the "corners" of the cube after being "spherified". This region doesn't have square sections to form the base of the marching cube volumes. I can generate the volumes on the surfaces of the cube and then "spherify" the resulting verts......

What I want to know is: Will this work?

I don't want to waste my time if this will result in failure, or if there is something that will give me the desired results (cliffs, overhangs, and caves)......

Please let me know what you think.

#### Share this post

##### Share on other sites
Advertisement

You seem to be mixing up your paradigms here. The cube-to-sphere distortion is good for doing what essentially amounts to a "spherical heightmap". This is similar to a regular heightmap (ie, a plane deformed by a 2D function). That is, the surface of the sphere is deflected toward or away from the sphere center by what amounts to a 2D function applied across the surface of the sphere.

A marching cubes implementation, however, is a volumetric approach. Space itself is partitioned into discrete units, and a topology is formed by evaluating the space density function at these discrete steps and constructing mesh geometry per cell.

There is just no real relation between these two paradigms, and trying to force them together is probably going to be an ugly mess. You might want to rethink your approach.

#### Share this post

##### Share on other sites

I understand both of them.....

How would you do it?

I want to have caves, overhangs, and cliffs. I want (and will have) a fast terrain generation process over the surface of a planet. I want them both, but the marching cubes will only be used once landed. I just need some way to marry them.

#### Share this post

##### Share on other sites

Well, the problem is that they're just too different. Marrying them just isn't really a straightforward job.

If you want overhangs, then cube-to-sphere suffers from the same limitations that a standard planar heightmap does. The structure just isn't there to do overhangs. Marching cubes can do overhangs just fine, but the difficulty there is doing the adaptive level of detail. LoD on a marching cubes implementation is fairly straightforward; the difficulty comes in fixing the cracks between chunks of different resolutions. You might take a look at http://www.terathon.com/lengyel/Lengyel-VoxelTerrain.pdf by Eric Lengyel. I haven't really researched this topic that much, nor have I read that whole thing, but I understand that he had a method for accomplishing the transitions.

swiftcoder has some links up at http://swiftcoder.wordpress.com/planets/isosurface-extraction/ that you might want to browse through, seems like some of the enhancements to marching cubes such as dual contouring might offer solutions.

At any rate, it's a pretty complex problem. Best of luck.

#### Share this post

##### Share on other sites

I don't want to do LOD on the marching cubes. That part will already be the highest detail. I only need to do LOD on the other. All I think I need is a way to make regularly spaced grids for the MC framework to work on.

#### Share this post

##### Share on other sites

I think I understand your methodology, but I think it differs greatly from where I'm starting. I think you are talking about "modulating" the values, but I don't understand how to do that.

#### Share this post

##### Share on other sites

I think I understand your methodology, but I think it differs greatly from where I'm starting. I think you are talking about "modulating" the values, but I don't understand how to do that.

Well, what is your methodology? And I'm not really sure what exactly you mean about "modulating the values."

#### Share this post

##### Share on other sites

Ok. I have the "cube-to-sphere" with quad-tree detailing. I have a height map that I use to push out the verts that I generate. From there I want to start generating the high detail with marching cubes. In order to use them, I need to have box volumes. The "cube-to-sphere" gives me an irregular grid pattern once put into the sphere, so I can't use that. However, before performing the "sperification", the verts form a nice regular grid pattern on the six faces of the cube. I think if I come up with a method to generate the marching cube voxels along the regular grid pattern (on the faces within range of the detail center), and then "sperify" those verts, they will still line up and look mostly normal. By mostly normal, I mean that there will be some "bunching" at the corners/edges where the cube faces meet. The bunching shouldn't cause any overlaps or gaps, though.

#### Share this post

##### Share on other sites

Ok. I have the "cube-to-sphere" with quad-tree detailing. I have a height map that I use to push out the verts that I generate. From there I want to start generating the high detail with marching cubes. In order to use them, I need to have box volumes. The "cube-to-sphere" gives me an irregular grid pattern once put into the sphere, so I can't use that. However, before performing the "sperification", the verts form a nice regular grid pattern on the six faces of the cube. I think if I come up with a method to generate the marching cube voxels along the regular grid pattern (on the faces within range of the detail center), and then "sperify" those verts, they will still line up and look mostly normal. By mostly normal, I mean that there will be some "bunching" at the corners/edges where the cube faces meet. The bunching shouldn't cause any overlaps or gaps, though.

This doesn't seem like it will work. "Spherifying" the vertices of the cube is done by normalizing the coordinates, after which they lie upon the surface of the sphere. Then they are given shape by pushing them out with a heightmap. The spherification comes first, then the shape is applied. But if you generate a marching cubes volume first and then perform the "spherification" afterward the result will be a very messy yet smooth sphere of points. All the vertices of the mesh will be collapsed onto the surface of the sphere, and the shape will be lost with no real way to get it back.

Your mistake lies in thinking that you can somehow use the spherified mesh structure to do the marching cubes. You really can't, not in any way that makes sense, at least to my understanding. They are two completely different techniques. The sphereified mesh is a simplification; basically a hack to make a spherical heightmap. Heightmaps and isosurfaces are two completely different things, handled and created differently, and your best option is to go with the sphere technique from afar then use shader tricks to gradually blend in the volumetric mesh as you draw nearer.

#### Share this post

##### Share on other sites

• Advertisement
• Advertisement

• ### Popular Now

• 18
• 18
• 11
• 21
• 16
• Advertisement
×

## Important Information

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

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!