Epic fail on my terrain.... Now what?

Started by
12 comments, last by Hawkblood 10 years, 8 months ago

Ok. I had a post recently, talking about putting a plane over a sphere. I was going to use that idea as a skirt for a more detailed terrain. The concept depended on the plane being wrapped over the sphere in a fashion that kept each square of the terrain a constant size. This is an utter failure! It is NOT possible to do that-- there will always be a "crumpling" of the vertices at one edge or the other (at least).

My desire is to create a terrain that would move with the player as he crosses over the planet's surface. This approach would give a little detail to an otherwise smooth sphere. As the player gets closer to the planet's surface, the detail would become greater. All of this should happen in real time. I'm shooting low on the detail to keep it fast, but as I said, my earlier approach failed.

I'm looking at an article http://acko.net/blog/making-worlds-1-of-spheres-and-cubes/ to generate the terrain. The article uses a cube that is projected into a sphere. This cube is made up of 6 quad-trees. I'm slowly trying to understand how to implement a quad-tree, but I think I need to be able to convert a spherical coordinate into a plane coordinate in order to know where on the quad-tree the player is.... How would you do that?

I wasted about a week of programming before discovering my flaw; I hope I'm not going down another dead-ended road.

Advertisement

Sounds like you want to map a point on the sphere to a point on one of the cube faces? Like how a cubic environment map works?

Try this link, I've not tested whether it works or not:

http://petrocket.blogspot.co.uk/2010/04/sphere-to-cube-mapping.html

"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley
Thanks for the link. I thought going from a cube to a sphere would simply be taking a normaled vector of each point on the cube and pushing it out to a specific radius. I’ve never actually made a sphere that way, so I really don’t know. This article indicates another mathematical way to do it, but I think to be consistent, so I will use the way presented in the article first. As for the sphere-to-cube, I thought using a function utilizing cosine and angles would be the way. Again, I think I will try the article first…. Does anyone have more info?


I thought going from a cube to a sphere would simply be taking a normaled vector of each point on the cube and pushing it out to a specific radius.

While this does give you a mapping from a cube to a sphere, if you try and tile a quad tree across the resulting mapping, you'll have a lot of distortion (i.e. quads near the center of the cube face will be very large compared to quads at the corners of the cube face).

The mapping defined in that blog post squishes things a little, so that the resulting quads are more evenly distributed. This has a big impact on the quality of terrain around the edges of the cube.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

It sounds like you think the one in the article is better, right?


It sounds like you think the one in the article is better, right?

It results in less distortion, yes.

* "better" is a very subjective quality. It depends on the precise use case.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

I'm still trying to figure out how to do this...... I've never done a quad-tree, so this is a hard concept to wrap my head around.

I think I need to make 6 quad-trees, one for each face of the cube. Then, for each mesh created (depending on detail etc...), I will have to convert the flat planes into their spot on the sphere. Then, using some noise function (like perlin noise), generate the elevation (which is in/out from center of the sphere)..... This is getting complicated.....

The problem is that I can't take this "one step at a time", because I can't see true results until I get it nearly finished.....

The problem is that I can't take this "one step at a time", because I can't see true results until I get it nearly finished.....

Nah, you just aren't breaking this down quite right smile.png

1. Start with a single plane, defined either by the 4 corners, or by the center, orientation and extents.
2. Figure out how to use 6 of those to render a cube.
3. Figure out how to subdivide a plane into 4 children.
4. Figure out how to recursively subdivide planes.
5. Figure out the sphere->cube mapping, so you can dynamically subdivide the planes based on camera position.
6. Profit?

Each of the above stages has a well-defined visual result, so you can build this up iteratively, and carefully work out all the bugs at each stage...

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

I'm already at the beginning of step 4 because up to this point, I can see it in my head. If I made code to visualize these, I would have to make it in a different way than is needed for the final product. I can make a single plane to visualize step 4 before implementing all 6 cube faces though.....

If I made code to visualize these, I would have to make it in a different way than is needed for the final product.

Aye, that's definitely one of the costs of iterative development.

Well worth it in most cases, I might add - plus, you usually want to leave the debug visualisations in until near the ship date.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

This topic is closed to new replies.

Advertisement