Jump to content
  • Advertisement
Sign in to follow this  
Hawkblood

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

This topic is 1828 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 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.

Share this post


Link to post
Share on other sites
Advertisement
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?

Share this post


Link to post
Share on other sites


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.

Share this post


Link to post
Share on other sites


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.

Share this post


Link to post
Share on other sites

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.....

Share this post


Link to post
Share on other sites

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...

Share this post


Link to post
Share on other sites

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.....

Share this post


Link to post
Share on other sites

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.

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!