Planetary coordinates

I found this pretty cool link

It uses some pretty simple equations too!

With this, we would save the altitude for points that are grid-oriented, and then map them to a sphere to make a planet!

This might be useful, but I'm not a maths guy, I don't understand how it works. Let's have Bashi see it.

Pretty cool... if I wasn't a complete and total idiot in math class.

Couldn't we just use regular lat/long?

The problem with LatLon coordinates is that when you get to the poles of the sphere, the points get much, much closer together. It would be hard to measure distances across this sphere, and would cause texturemaps and heightmaps to become ultradense and distorted.

With this method, we would define 6 boxes. One for each side of the cube. Each of the datapoints in the box would represent an altitude for it's point. We wouldn't have to worry about the poles this way.

I found out it's actually how most planet simulators do it. I'm also thinking about using ogre, rather than writing my own engine completely from scratch.

roadkillguy wrote:

The problem with LatLon coordinates is that when you get to the poles of the sphere, the points get much, much closer together. It would be hard to measure distances across this sphere, and would cause texturemaps and heightmaps to become ultradense and distorted.

With this method, we would define 6 boxes. One for each side of the cube. Each of the datapoints in the box would represent an altitude for it's point. We wouldn't have to worry about the poles this way.

I found out it's actually how most planet simulators do it. I'm also thinking about using ogre, rather than writing my own engine completely from scratch.

If it works better, I'm all for it.

Yes, no, yes, no, yes, no, yes, no, undecided.

Pros:
Much easier to map some form of "game grid" onto the sphere. You simply treat it as a cube.


Cons:
Possible artifacts at "cube edges". Can you test this with various textures, and post results?

If i'm looking at it right, we need to distort the textures slightly at the inverse of the cubemapping to get the them to look right

What do you propose we use then? I don't think the texturemaps will have to stretch very much unless we use one for the whole planet :affraid:, and I don't like the idea of lat-lon vertices.

I haven't even made a hollow subdivided cube yet, so I can't exactly test it.:lol:
EDIT: By made, I mean "Written an algorithm to do it based on a specific width" It wouldn't be too hard to do it manually, I just want to write a master-equation. Which is hard.

Also, we need some method of LOD (Level of Detail) decimation. I found something called quadtrees, but I have yet to look at any source.

Aha, just as in the other post i replied to, yes you use quadtrees to represent the sphere's surface. setting the texture coordinates shouldnt be too hard, if you can reverse the transforms done on the cube in order to get a sphere

I would actually think to create the sphere, and then modify the (altitude) of each point. Maybe that's not what you were talking about.

Okay..

The planet would be represented by 6 quad trees. one for each flat edge of a cube. The quad trees are wrapped around a spherical shape.

A quad tree is as follows:

you have a node, the root node, that can be split into four more nodes.

Code:

      O
      |
  ----------
  |  |  |  |
  O  O  O  O

each of these nodes can then be split into four more nodes, and so on.
the lowest level nodes, ones without nodes underneath them, are called leafs.
(note, however, that each leaf isnt necessarily sitting the same amount of nodes in.)

Each leaf represents a cell. And when taking into account what i said in parenthesis above, each cell could be a different size. This is how the example video represents the data for the planet. If the leaf gets a set distance to the camera, it splits. when the camera moves away again, the leafs are discarded.

Every time you split a leaf, you need to generate more detail. so each leaf then needs to have its height modified by some amount.
if you use a psuedo-random function with the coordinates of the leaf on the tree, you can recreate the same planet every single time.

Of course, you would eventually stop splitting the leafs as well, you need to impose a limit, to stop "infinity detail" being created and asploding the cpu

I understand how it works, it's just the act of creating the vertex and triangle lists that will seem a little more daunting. Not to mention the texture mapping.

If you walk through the tree as follows:

Code:

    u
l        r
    d
   
child1 child2
child3 child4

Code:

walk(node, l,u,r,d)
{

node->settexturecoords(l,u,r,d)


if(node->child1)walk(node-child1, l, u, r/2, d/2)
if(node->child2)walk(node-child2, r/2, u, r, d/2)
if(node->child3)walk(node-child3, l, d/2, r/2, d)
if(node->child4)walk(node-child4, r/2, d/2, r, d)
return
}

(Of course i wouldnt use recursion, but it's simpler to write out than a loop.)
(And i'm not sure if that is exactly, right, it looks right to me though.)

l,u,r,d are the negative and positive horizontal and vertical limits of the edges of the node.

the root node's limits are -1,1. Each planet would get 6 textures.
texture coordintates are clamped to 0,1, so you would have to halve the number, then add 0.5 to get the texture coordinates from the cell limits.

You must have done this before..

Yes and no

There's another algorithm I've found.. It's called the ROAM algorithm. They simply subdivide where the camera is, and desubdivide where it's not. They have versions for sphere mapping as well.

Looks interesting.

For simplicity's sake I was thinking of something like the following:



Not necessarily like a quadtree, just sectioned LOD. It may prove to not work if the planet is VERY large, but for this game I was thinking spore sized planets or less.

It would work by having nodes that contain two-dimensional arrays. To get the vertices, we render the initial grid, and then add more vertices depending on the detail level.

It works in my head anyway

EDIT: Here's some pseudo-code.

Spoiler:

Planets should be as scalabe as possible, because right now we can't just see what size will have the best gameplay/performance ratio. Limiting it to Spore size or less might lead us into problems later.

I'm sure it will work for what we're trying to do.

roadkillguy wrote:

I'm sure it will work for what we're trying to do.

Again, experimentation is the best way to figure this out.

Yep. And I just got the ManualObject class working in OGRE. Time to write some loops.

roadkillguy wrote:

Yep. And I just got the ManualObject class working in OGRE. Time to write some loops.

Fun. Keep up the good work.

This be used to increase detail in the center of your vision, where you are looking - things in the corner of your eye wont be detailed, you have to look round to see what it is. What do you think?

That's what it's for. Yes.