Sunday, September 28, 2014
Thursday, September 25, 2014
I have been working at least somewhat on the surface exploration mode in the space game, but have nothing to really show yet. The system I have now allows various metadata to be associated with the colors on the map, things like “should we use the altitude value or just flatten this out,” “is this ocean,” “does this create a shoreline,” and so on. After some annoying wrestling and a throw-hands-up-in-the-air-and-say-forget-it attempt to use the busted-ass version of std::unsorted_map my OSX installation has, I’ve confirmed I can get that information all the way to planetary geometry construction. The next thing is, well, to take action based on that information. Yeah.
Away from the compiler, I’m also noodling around with for-reals designing the setting for the game. I may have finally come up with a reason to explore this big, empty solar system. We’ll see, though, I don’t exactly bat a thousand when it comes to pulling together game stories.
Sunday, September 21, 2014
Starting to work on proper surface geometry. For starters, I just made it so the surface triangles take on the altitude and average color from the relevant map points. This is obviously just slapped together, but it’s useful for a) making sure surface geometry is correctly lit by the sun, b) setting up proper mesh/shader usage, c) getting a sense of scale, and d) getting a sense of efficiency. For example, “30 fps” means I probably shouldn’t be rendering 5,120 individual surface meshes complete with all the associated OpenGL bureaucracy.
Saturday, September 20, 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.
Wednesday, September 17, 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?
Tuesday, September 16, 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.
Wednesday, September 10, 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.
Sunday, September 7, 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.
Thursday, September 4, 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.
Thursday, August 28, 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.
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.