## Category: "R:WM Dev Blog"

## Hmm, sphere math that broke my head

May 16th

Now this was straight forward for projecting a planet sphere at a specific distance away so that, no matter what maximum distance the view area is set at, the planet is still visible and scaled appropriately. This all worked and has been working.

The problem I have been running into is the equation to know how much of the planet to show at any one time. The equation for determining the visible surface area angle is the ArcCosine of the Radius of the Planet divided by the Distance the observer is to the center of the planet (which would be somewhere, perhaps high above the surface of the planet, which of course the surface would be the radius). Ok, that works fine. Take the circumference of the planet, divide that by 360, that gives you the distance per degree and you multiply that by what you got from the ArcCos (Yes, typical ACOS gives you radians, not degrees, but the concept still applies). This gives you the distance of the visible arc. Meaning, from the center point that the observer is directly over, how much distance FROM there can that observer see of the sphere. That all works. To get the size of the original triangle from the isohedron is 26 degrees or the ArcTangent of 1/2 (look it up). Multiply that by the same distance per degree as above and you get how big the original isohedron triangles are based on the radius of the planet. Ok, that all works.

Now I wanted to know what subdivision level I should be at to cover that area with a specific set of “rings” of triangles. Keep in mind that all the subdivisions are of that original isohedron triangle. And this kept screwing me up. Here is the solving equation:

Distance of Visible Arc/Number of Rings = Distance of Original Isohedron Triangle/ 2 to the power of X (X being the amount of subdivisions needed based on the number of desired rings).

A little algebra later and you get this:

2 to the power of x = (Distance of Original Isohedron Triangle/(Distance of Visible Arc/Number of Rings))

Now I thought the way to solve this was:

X=Square root of (Distance of Original Isohedron Triangle/(Distance of Visible Arc/Number of Rings))

It isn’t. That doesn’t work. That isn’t how you solve it. It’s not squareroot. It’s LOG to the base of 2. So the answer is finally:

X=log2(Distance of Original Isohedron Triangle/(Distance of Visible Arc/Number of Rings))

Older C didn’t have Log2, but did have Log10. So to emulate it, it is Log10(Distance of Original Isohedron Triangle/(Distance of Visible Arc/Number of Rings))/Log10(2). But it seems newer C has Log2.

## Sub Div 9 Planets are working...

May 5th

In this still:

the "land" is being rendered from the outside (the red mesh). You can see the colored triangles that I used for debugging. The mini-triangles represent the points by color: red, green, and blue for points 1, 2 and 3 respectively. So as it subdivides down it is displaying two sets of triangles (Best seen here:)

This is showing the planet sphere in white at the lowest resolution (so you can see what is going on) from the inside out, so it's easier to see what is happening. The "red" main triangle is the point at which the player is to the planet (now behind us). The two sets of triangles represent the subdivisions from the 20 sided sphere (so flat against that first triangle), and the actual triangles ON the sphere as each subdivison is approximated on the real sphere.

This shows how it looks as the resolution of the real sphere goes up.

This matches the resolution of what I'm making te surface out of. Currently, Sub division 6.

This shows the planet at subdivision 9, with still sub division 6 "land". To do sub division 9 on that wide of an area would make the system choke (and doing the whole planet at sub division 9 kills the frame rate, obviously). But the point is, the red "land" represents the visible arc of the sphere at the distance we are from the planet. The monitor says that's 992 miles away. So at 992 miles, that land mass is what you can actually see of the planet (Mars), but because of the curvature of the sphere you can only see so much of that sphere. As one gets closer to the planet, the amount of area goes down drastically. At which point the resolution will go up of the land mass, but the area will go down proportionally. The idea is to keep doing this all the way down to subdivision 19 or 20. Subdivision 9, each triangle is between 2.5 to 5 miles I estimate, so to get it down to around 10 feet, that is subdivision 19. After Sub divison 9, it's going to use either a height map or a perlin noise generated heightmap to handle the points below. I'm working on that part. :)

## Planets are running...Kinda

May 2nd

I am showing a SubDivisioned Planet down to 9 subdivisions. I found the problem since Sub Division 0 looks like origami, but everything else looks fine. If you notice towards the end, you can see the heights embedded in the points. And best of all, no poles!

Note: This is not all of it by any means. I need to go down to subdivision 19, but I needed to get this running completely. Unlike the original "sphere" you saw, this actually has height information in it and can drill down.

## Issues around designing a planet

Apr 14th

While displaying a textured sphere is easy, getting to procede from high orbit to actual land fall and dynamically scale up isn't so easy. By definition, you are defining a whole planet which is a really big place. That means lots of memory or hardrive space to store something on that scale. The inital answer is just use a texture and that works to a point. The PROBLEM with that is, it really won't go down to "walking on the ground" level and it really starts to get distorted at the poles.

Down around the equator, the distortion is so minor you don't consider it, but as you can see at the poles of the planet, the idea of a texture can get messy. That isn't so much a problem (but still is) with a color texture wrapping a sphere, but when you try to do X and Y shifts the concepts no longer work. Even if you simulate it with spherical coordinates (theta and phi, ie. theta being lattitude and phi being longitude), close to the poles, you are litterially running around in circles when you go along the "X" axis.

The current "solve" for this is you don't use X and Y, but a isohedral format.

Now there are no "poles" per se. This is based on a isohedron. (think of a 20 sided die, although the picture is one subdivision down). While this works, if you noticed, some triangles are layed out in a hexigonal pattern and some in a pentagonal pattern. This creates it's own series of problems, so my original idea of just doing hexigons won't really work globally. The isometric triangles still will, however, but now the trick is to get them to play nice. I have an idea via linking triangles together, but again, on planetary scales, that gets very memory intensive. I have ideas for optimisation, but then things get unlinked, so there are still problems to solve.

Of course, none of this solves the issue when you get below the original heightmap threshold, which will have to be handled by something procedural like Perlin noise.

## New Ships

Mar 20th

Just smoothing out the normals for the new Cap Ship and working on the base model for the freighter.

Full story »

## Terrain Curved!

Mar 15th

This took a lot longer than it should have, but I have been working on other things too. What this is showing is the normal hexigonal terrain layout is now properly curved based on distance. You can't see that from the first picture that it's just the original hexigon. The second picture is just showing the heightmap is working. And the third just to show it is the hexigon (just from inside the planet so you can actually see it). The normals aren't correct right this second, but I want to get this posted. So next is alignment and proper approach positioning and scaling.

1112 13 »