While the terrain code is far from being in it's finished form, it's now functional enough for the buildings/installations to show up again.  Just to see them is an EPIC milestone accomplished!

What you are seeing are three different installations/cities of three different players (Two computer warmasters and a human player).  

While the asset screen still needs help in it's functioning (and honestly, a complete graphical overhall to the new UI/UX interface), as you can see, the buildings are fully operational.  They draw power, they produce!

Even creation of the AIs work!  (It's Cyborg #12 because I created the AI, but the other computer warmasters already created a series of AIs for their own uses).

Now to fix the seam problems... ;)

Quick test video of the ground turret. Still refining textures and pivot point

Solve one thing, find two more things that need to be redone.  Such is coding.

So the good news is, the Perlin Noise works, and you can see that terrain.  (What are you are seeing is a single color from the high-orbit color texture, accenuated by the local perlin noise height mapping.  So that works)  The bad news is, evidently I never finished the plantary location system.  So as you can see, I'm at the pole (North pole if you care).  Through a lot of thought, I know what needs to be done to solve the seam issue, one simple and one more annoying but accurate.  In ANYCASE, the REAL remaining issue before anything can be really solved is the location system needs to be updated for planets.  The inherant problem for doing a video game on such a massive scale is the number space really doesn't allow for it.  One way to get around it is you have different "spaces" that only care about so much accuracy.  (ie. Solar system space, deep space, plantary space, ship space, building space, etc.).  The way I handle it in deep space is in overlapping sectors.  So just like you have level "boundries", I have sectors with their limits.  When you traverse to close to the edge, the engine seemlessly moves everything over to the new sector without skipping a beat.  Those that are too far away (read 100+ miles), don't make the "cut" and are left in the old sector boundries, while everyone close by gets transported to the new sector.  In a space battle, you won't care if someone just "disappears" because if they are 100 miles away, they are too far away for you care about.  Long distance big things (such as cities) for navigation can still be tracked in deep space coordinates rather than sector coordinates, and if there is some inaccuracy, you'll never see it.  By the time you are close enough to care, the city will be in your sector anyway and therefore be tracked more accurately on sector coordinates.

Ok, so what does this have to do with planets?  Well, in high orbit, I didn't have to worry about orientation.  It knew where you were in relation to the center of the planet, and so I wrote code that only showed you that side in fine detail.  Ok, that all works.  The problem is, in low orbit, it generally makes sense to have the ground below you.  Which means no matter what, the ground is towards negative Y. That was the mentality with the old terrain system.  it was also layed in in grid form, and I never solved those problems so I brushed it under the rug to be handled later.  Well, it's later.  With going to a triangle based terrain system, rather than a grid one, I keep getting hit by grid limitations in the system.  So the location system for planets does need an overhaul so it knows what to display as ground (and when to "stop" you because you hit it).  However, even as I type this, I wonder if I should just do away with negative Y being ground and be done with it.  Regardless of the choice, the old style plantary reference location system has to be done away with.  It's not accurate to what I currently need and it's playing havok with displaying the terrain.  Regardless of which answer I choose, the location system needs an overhaul.

The problem with coding is, most of it is just lines that to the general public do NOTHING.  But they do.  However, towards the end, a LOT of things can be seen.  So I give you this, proof that the new terrain engine is doing what it's supposed to, at least in high orbit. 

Please note that the red triangles are the SAME in both pictures...you are just seeing them from opposite sides.  So everything on that level is working and even better, the frame rate problem disappeared when I did some code clean up.  Go figure.  :)  (I think it was a memcopy statement running too often, but I don't care right now).

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.

First test of the Perlin Noise field.  I'm not 100% happy with it, but that is just tweaking later on anyways. I want to get it integrated first.  (This is using the internal point dumpster rountine I made so that I can visualize points and objects more easily).

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

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.  

2 new styles of fighter ship 

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.