Look who came to dinner....

Look who came to dinner....
Look who came to dinner....
Look who came to dinner....
Look who came to dinner....

Another major milestone, the old shipbuilder is runnable enough to build new ships to run around and kill each other!  So now the NEW ships are available to be built into something.

As with such things, it showed other problems, since the Warmaster AI was trying to design ships without sufficient tech to actually make a ship able to get off the ground.  While the quick solve was to put their tech level super high and the problem went away, that isn’t the real answer, so I put something in there that it won’t let them try to design if they just don’t have the components yet.  This matters for when you, as the player, start from scratch too.

There was a problem with the ship exporter that had to be fixed since it was creating too many points, which of course tripped the shipbuilding routines, since they assume a cohesive ship.

Interestingly enough, the newer ships didn’t cause a system tank in a furrball any more than it did originally.  I suspect the issues are elsewhere, not in the to-hit calculations (not that they don’t need help) but it isn’t as terminal of a problem as I thought it would be.  I guess the real test is to try with the much higher polygon count of the cap ship and see how much that makes a difference, but I suspect it won’t make too much of one.

Ok, why no screen shots of the shipbuilder?  Because it’s still in the old ancient style.  I’m not going to fix the cosmetics of it, since the idea is to design a brand new interface.  However, this certainly shows the old autobuilder and auto-helper still work well.  Those automatically design a ship from scratch or finish filling in the missing pieces, respectively.  It is so players who don’t want to be anal about designing a ship can let the computer do it.  The auto-helper is for those that like to put in certain things, but then want the computer to do the heavy lifting for balancing thrusters and power!  I used the auto-helper to design what you see in the screen shots.  (And yes, I forgot to assign the weapon first points so they are firing from the center, oh well.  There is an auto-assigner, but I forgot to use it)

Now to build the far nicer interface!

 

 

 

My My My...Where have you been hiding these many months?

My My My...Where have you been hiding these many months?
My My My...Where have you been hiding these many months?
My My My...Where have you been hiding these many months?

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

Ground Turret

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

Close Terrain First look (Still a work in progress)....And yes, you can bounce on it.

Close Terrain First look (Still a work in progress)....And yes, you can bounce on it.
Close Terrain First look (Still a work in progress)....And yes, you can bounce on it.

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.

Things are accelerating

Things are accelerating
Things are accelerating

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

 

Hmm, sphere math that broke my head

Hmm, sphere math that broke my head

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.

 

Behold the field which I grow my....Perlin Noise?

Behold the field which I grow my....Perlin Noise?

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

 

 

Sub Div 9 Planets are working...

In this still:

Sub Div 9 Planets are working...

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

Sub Div 9 Planets are working...

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.  

Sub Div 9 Planets are working...

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

Sub Div 9 Planets are working...

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

Sub Div 9 Planets are working...

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

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 Fighters

2 New Fighters
2 New Fighters

2 new styles of fighter ship 

1 2 4