Sunday, September 21, 2014
Tweaked the atmosphere to be solarized (thus avoiding gradients) and to change colors between daytime, twilight, and night as the sun’s position changes. Along those lines the background stars and galactic nebula are faded out during the daytime.
Also, Clementine now orbits a gas giant (“Discordia”) because in science fiction there’s always gotta be a big ol’ ringed planet floating in the skybox.

Tweaked the atmosphere to be solarized (thus avoiding gradients) and to change colors between daytime, twilight, and night as the sun’s position changes. Along those lines the background stars and galactic nebula are faded out during the daytime.

Also, Clementine now orbits a gas giant (“Discordia”) because in science fiction there’s always gotta be a big ol’ ringed planet floating in the skybox.

Saturday, September 20, 2014
Ok, that’s enough for the night. I’m implementing more stuff for the surface exploration mode in the space game. The surface movement and camera code I’d started was an absolute trainwreck, so I threw it out and instead copy’n’pasted the code for flying and operating the ship in space with a hacked-on bit that sticks the ship to the surface of the globe. It couldn’t be farther from how I want surface exploration to feel, but it at least lets me move around without screwy glitches and singularities, which is good enough for now.
The main new feature is the atmosphere. It changes color based on the altitude of the sun above the horizon, and additively blends against the background environment. Speaking of which, that’s the same background elements seen in space: the sky is accurately rendered based on the player’s position on the globe of the world. If you fly from one side of this planet to the other, its moon will even move with parallax against the background stars in exactly the fashion one would expect.
Next steps? It’s important to get rid of those color gradients as soon as possible, of course. This project is ideologically opposed to gradients. Sometimes in my more eccentric moments I think I should even lock the color palette down completely to truly capture the retro Amiga feel. 32 colors should be enough for anyone, right?

Ok, that’s enough for the night. I’m implementing more stuff for the surface exploration mode in the space game. The surface movement and camera code I’d started was an absolute trainwreck, so I threw it out and instead copy’n’pasted the code for flying and operating the ship in space with a hacked-on bit that sticks the ship to the surface of the globe. It couldn’t be farther from how I want surface exploration to feel, but it at least lets me move around without screwy glitches and singularities, which is good enough for now.

The main new feature is the atmosphere. It changes color based on the altitude of the sun above the horizon, and additively blends against the background environment. Speaking of which, that’s the same background elements seen in space: the sky is accurately rendered based on the player’s position on the globe of the world. If you fly from one side of this planet to the other, its moon will even move with parallax against the background stars in exactly the fashion one would expect.

Next steps? It’s important to get rid of those color gradients as soon as possible, of course. This project is ideologically opposed to gradients. Sometimes in my more eccentric moments I think I should even lock the color palette down completely to truly capture the retro Amiga feel. 32 colors should be enough for anyone, right?

Wednesday, September 17, 2014
Got the player ship and control circuitry wedged into the surface state, so you (meaning me) can pilot the ship around on the surface and see the planet roll by underneath. Sort of. It’s actually really janky, but as is usually the case the hard part is getting things showing up on the screen at all and the rest is details.

Got the player ship and control circuitry wedged into the surface state, so you (meaning me) can pilot the ship around on the surface and see the planet roll by underneath. Sort of. It’s actually really janky, but as is usually the case the hard part is getting things showing up on the screen at all and the rest is details.

Tuesday, September 16, 2014
"Hey why does the cool fractal planet look all blurry and low-res now?" you might be irately asking. The answer is, this is not the fractal planet. This is a reconstruction of it with vertex colors on a low-res globe. It’s proof of concept for a surface exploration mode, where surface geometry is generated based on the landscape information that was drawn out of the surface shader and stored in the surface map.
The next step is to be closer to the surface than geosynchronous orbit, of course. But first I wanted to confirm that the planet was being reconstructed correctly and actually matched the map.

"Hey why does the cool fractal planet look all blurry and low-res now?" you might be irately asking. The answer is, this is not the fractal planet. This is a reconstruction of it with vertex colors on a low-res globe. It’s proof of concept for a surface exploration mode, where surface geometry is generated based on the landscape information that was drawn out of the surface shader and stored in the surface map.

The next step is to be closer to the surface than geosynchronous orbit, of course. But first I wanted to confirm that the planet was being reconstructed correctly and actually matched the map.

Wednesday, September 10, 2014
Messing around with the planetary generation function to see if it was possible to create a Lava Planet (tm). The answer is maybe!
I think the right way to go with planet generation is to have several broad categories of planets, each with their own generation function. In the past I was attempting to have a single function which could generate all possible planets, from airless to Earthlike, and while you sometimes got interesting results at the boundaries it was still limited in what it could deliver. I just need to go in and reorganize that small area of code to be more extensible and usable; right now I have to hack in more and more functions to make different planet types and that’s no good for anybody.

Messing around with the planetary generation function to see if it was possible to create a Lava Planet (tm). The answer is maybe!

I think the right way to go with planet generation is to have several broad categories of planets, each with their own generation function. In the past I was attempting to have a single function which could generate all possible planets, from airless to Earthlike, and while you sometimes got interesting results at the boundaries it was still limited in what it could deliver. I just need to go in and reorganize that small area of code to be more extensible and usable; right now I have to hack in more and more functions to make different planet types and that’s no good for anybody.

Sunday, September 7, 2014
Spent a bit of time this afternoon cleaning up the planetary climate generation, as it was an overgrown and hacky mess. 
To recap, the system works by generating a climate texture, as seen on the left side of the screen. The top of the texture represents the poles (latitude 90 degrees) and the bottom the equator (latitude 0 degrees.) The lowest altitude is on the left side, and the highest altitude is on the right. When the shader is drawing the planet, it computes the altitude of the pixel it’s currently working on and then uses that and the latitude to look up a climate pixel in the texture.
This is nice and flexible, and can create a huge variety of results just by tweaking the climate texture, which is what I was focusing on improving. Besides the plus of not being an unreadable jumble, climate generation now also has more explicit parameters than the old setup. The system formerly relied on emergent effects and it doesn’t do that quite as much now, but this also means I can adjust those parameters and be more confident of getting attractive results.

Spent a bit of time this afternoon cleaning up the planetary climate generation, as it was an overgrown and hacky mess. 

To recap, the system works by generating a climate texture, as seen on the left side of the screen. The top of the texture represents the poles (latitude 90 degrees) and the bottom the equator (latitude 0 degrees.) The lowest altitude is on the left side, and the highest altitude is on the right. When the shader is drawing the planet, it computes the altitude of the pixel it’s currently working on and then uses that and the latitude to look up a climate pixel in the texture.

This is nice and flexible, and can create a huge variety of results just by tweaking the climate texture, which is what I was focusing on improving. Besides the plus of not being an unreadable jumble, climate generation now also has more explicit parameters than the old setup. The system formerly relied on emergent effects and it doesn’t do that quite as much now, but this also means I can adjust those parameters and be more confident of getting attractive results.

Thursday, September 4, 2014
Cleaning up long-ago code that generated a 2D map of the 3D planet. I was doing it by flattening the actual sphere triangles onto the plane, but now that the planet is entirely generated by shader code there’s really no need for that — I can just draw a single rectangle which interprets its X and Y coordinates as latitude and longitude, then in the pixel shader converts those to the corresponding 3D point and runs the shader generation function to find what color it should be. The result is a perfect map. (Though not an interesting projection, map nerds; it’s still just a plate carrée.) The two oceans visible on the planet can be seen in the center of the map.
Now that’s all fine, but the genuinely interesting bit is we now have a data resource that tells us what sort of terrain a specific point on the planet’s surface might be — information that used to be locked away in the final rendered scene and inaccessible. That could be used for all kinds of irresponsible things.
Also it turns out that the reason my planets didn’t have ice caps was that there wasn’t enough temperature variation between the poles and the equator. I kind of feel that there’s more variation I could wedge into the climate texture, to get distinct desert zones in hotter regions. That’s worth investigating, as the homogenous terrain of these planets can get a little dull.

Cleaning up long-ago code that generated a 2D map of the 3D planet. I was doing it by flattening the actual sphere triangles onto the plane, but now that the planet is entirely generated by shader code there’s really no need for that — I can just draw a single rectangle which interprets its X and Y coordinates as latitude and longitude, then in the pixel shader converts those to the corresponding 3D point and runs the shader generation function to find what color it should be. The result is a perfect map. (Though not an interesting projection, map nerds; it’s still just a plate carrée.) The two oceans visible on the planet can be seen in the center of the map.

Now that’s all fine, but the genuinely interesting bit is we now have a data resource that tells us what sort of terrain a specific point on the planet’s surface might be — information that used to be locked away in the final rendered scene and inaccessible. That could be used for all kinds of irresponsible things.

Also it turns out that the reason my planets didn’t have ice caps was that there wasn’t enough temperature variation between the poles and the equator. I kind of feel that there’s more variation I could wedge into the climate texture, to get distinct desert zones in hotter regions. That’s worth investigating, as the homogenous terrain of these planets can get a little dull.

Thursday, August 28, 2014
Okay, so designing things before I implement them doesn’t seem to be working out. Therefore, I’ll violate my own arguments against speculative development and just implement something I think might be cool, and see where it goes. This is a basic system for identifying the nearby triangles on a planet’s surface so we could potentially draw surface features.

Okay, so designing things before I implement them doesn’t seem to be working out. Therefore, I’ll violate my own arguments against speculative development and just implement something I think might be cool, and see where it goes. This is a basic system for identifying the nearby triangles on a planet’s surface so we could potentially draw surface features.

Wednesday, August 27, 2014

Current Status

So many times the past few weeks I’ve charged over to XCode full of vigor and ideas, ready to CHANGE THE WORLD, and then was brought up short by the minor problem that I really don’t know where I want to go with any of these game enginey things I’ve been messing around with.

This is a recurring problem.

Thursday, July 31, 2014
Eh, not too bad. I adjusted her right arm and gun to create a more consistent directional feel to the image — it’s kind of typical of my half-assed approach to laying out artwork that I missed that in my original pencil draft, but the result is surprisingly interesting composition. Also added elbow gloves and somehow an enigmatic smile got on her face, which is very strange as I’d pictured A. CYBORG as a dour, cranky and humorless straight-man kind of character. Hmm, I may have to reconsider some stuff.

Eh, not too bad. I adjusted her right arm and gun to create a more consistent directional feel to the image — it’s kind of typical of my half-assed approach to laying out artwork that I missed that in my original pencil draft, but the result is surprisingly interesting composition. Also added elbow gloves and somehow an enigmatic smile got on her face, which is very strange as I’d pictured A. CYBORG as a dour, cranky and humorless straight-man kind of character. Hmm, I may have to reconsider some stuff.