There’s enough different things I want to work on in the space engine that it’s hard to pick any one thing. So instead I’ll yammer unproductively.
Quick menagerie of gas giants. Although it’s subtle, I also fixed some issues with the galactic nebula in the background that were bugging me — basically, it was projected onto a sphere, which caused the 3D texture to generate artifacts around the galactic equator. Now it’s just a cylinder, no more artifacts.
It’s been fun fooling with the space engine again for a bit. Not quite sure if I’ll do more on it right now, as I’m a little hazy about where I’m going with the whole thing.
Okay, that’s the lighting issues sorted out. Which is to say that’s not the lighting issues sorted out, because if there’s one fundamental thing I’ve learned about 3D graphics it’s that the lighting issues never, ever get sorted out.
Bitterness aside, the real problem with my lighting system was philosophical: namely, it tried to be a comprehensive solution without the needed systems support. A major part of most 3D renderers is the scene graph, which is a fancy term for “all the stuff we want to render this frame” and infrastructure which lets you query that. My little engine has an extremely rudimentary scene graph: basically just a list of objects (and object hierarchies) independently floating in the world. Trying to run a query of objects that might get lit, vs. objects that might light them, is a bewildering pain. The original “lighting system” I wrote — I hesitate to even dignify it with that term — had several light types and a vague wishful methodology for keeping a list of most influential lights on the world itself and sorting them based on distance and brightness. Needless to say it didn’t work even a little bit.
And you know? That’s fine. Not every engine needs to have a fancy lighting system. The stuff I’m writing with my little toy renderer is generally designed to produce very specific, tuned effects. So I’m gonna just run with that. The various planets and moons and whatnot happen to be organized hierarchically under a cSolarSystem parent object. I just put some accessors on that object which return a point light position and color based on the primary star. Good enough for government work.
As a side note, there’s a nice touch to how the rings are lit. A planet’s rings are made up of millions of tiny particles that just look like a single object from far away. So the overall color of the rings will be the color you’d expect to see from light bouncing off a round particle to your eye: if you were closer to the sun than the particle, you’d see a bright particle as most light was reflected directly at you, while if you were farther away you’d see a dim particle as most of the light reflected away from you. In this case, I’m taking a dot product of the vector from the light source to the ring system center, and the vector from the camera to the system center. This isn’t physically accurate, but computing the lighting on a per-pixel basis would create gradient effects and the fundamental principle of this graphical style is NO GRADIENTS!!! The single color I’m computing this way is a good approximation that delivers the result I want.
Anyway. With the lighting temporarily sorted, that means there’s no obstacle to making tomorrow Gas Giant Day. I’m very excited!
Okay, this bit of the space engine is sort of working again too, emphasis on “sort of.” There should be a shadow on the rings, and there kind of is, except the lighting direction in the engine is simply broken and so the whole thing looks dark. Man, there’s nothing I love more than fighting with broken light direction calculations in OpenGL/GLSL. Wait a minute, not “love,” what’s that word…
As a side note, the Jovian planet generation isn’t nearly as sophisticated as the terrestrial planet stuff. Yes, it does use a 1D texture for cloud bands and a 3D texture for detail and blah blah blah, but the actual color/noise parameters are hardcoded right now. It would be fun to add code for generating Jovian planets which took into account the size of the planet and the heat delivered to the planet (or even generated by it) to come up with the cloud bands. Off the top of my head I’d judge that a larger planet receiving more heat from the sun will have a more dynamic atmosphere, with larger, more contrasty cloud bands containing more swirly detail. As the planet got colder and smaller, the atmosphere would be less active until you reached largely featureless gas giants like Uranus. As for color, that would be mostly random (the varying colors of gas giants in our own Solar System are due to trace gas proportions) but as we edged up towards brown dwarf category the planet would become more red due to its own radiation.
It’d also be good to add a system for generating a few storms, Great Red Spot-style; way back in the day when I was fooling around with ray-traced planet generation in a more realistic style, I had some nice tricks that should drop right in to a shader for adding good-looking storms. Like here, see?
There’s actually a huge variety of things I’d like to do in this engine now. That may be a bad thing as I could just be paralyzed between them and go do something else. Gonna wager on that being the final outcome here.
Aw, you caught me. I’ve been spending an hour each night or so getting that old painterly space engine I was working on up and running again, which also involved fixing bugs in code that hadn’t been exercised by A. CYBORG.
(Protip: you need to explicitly call a function to generate mipmaps in OpenGL these days. Also it’s not enough to just know that, you have to actually do it.)
To recap, what you see here is a system which generates the planet textures entirely in pixel shaders by combining 3D noise with a definitional texture that indicates the colors to use for various altitudes and latitudes. The definitional texture itself can be generated procedurally based on the planet’s size and insolation (heat received from the sun) so you can have Mercury, Mars, Pluto, Earth, or anything in between. Meanwhile, clouds are defined by another 3D noise texture which moves slowly “through” the planet, creating the illusion that they grow and move over time.
It’s risky to make any predictions given my past performance, but there’s definitely a lot of stuff I’d like to do once I’m sure the rest of this functions. I’d like to use glDepthRange to allow optimal draw order and make render queries useful even with multi-world scenes, so the scene can blow out when you look at the Sun. It might be fun to actually implement stencil shadows from scratch for the player’s ship, which will also involve busting out Blender again to make a proper cockpit. Getting more space-y, I have some thoughts for swirling the texture coordinates to make clouds that look more like from-space-clouds and less like weird amoebae. Oh, and also that galactic nebula in the background looks like poo. Eh, we’ll see what happens.
I’m on Christmas break from my real job right now, and had hoped to spend much of it on gamedev. Yeah, that didn’t happen. I suspect I’ve been burning the candle at a bit too many ends, judging by all the lying in bed until noon and accomplishing nothing that’s been going on up in here. That aside, I’ve at least added some infrastructure for tracking score and mission progress to A. CYBORG. Really basic stuff, but it needed to get done. Enemies are now divided into types, a particular type and quantity can be set as the current mission target, and progress is tracked as the player shoots down enemies of that particular type. With that in, it would seem to make sense to get the UI stuff I was working on a little while ago functional and wire it all together.
Feelin’ that dangerous urge to switch projects again, though…
Did some A. CYBORG stuff today, specifically trying to implement a KO/death/whatever state. Yes, sad as it may be to contemplate, our daring heroine can get shot down — don’t worry, though, she’s a cyborg after all! A couple hours in the shop and she’s good as new. The real sad part of this situation is that I have to code it, and it’s been more difficult than anticipated. There are two reasons for this:
I think that if I can get the tick function into some sort of tolerable state, I’ll feel a lot better about the rest of it. All the random stuff going on in there needs to be split away and a proper state machine set up for handling and blending player motion, as well as camera behavior, under different conditions.
I had to return Mr. Eldridge’s gesture and draw a picture of Stevie from Frost - Bone - Ember. It turns out that I am only drawing pixels these days! And furthermore, it was a lot of fun.
As a side note this character could not be more ’80s if she was wearing leggings and listening to a Mister Mister album.
I was messing around at work the other day and busted out a few quick fan art sketches for A. CYBORG! My take skewed a little bit more sci-fi then I think Mr. Sachs is going for. I’m really looking forward to it though and hope is has a chance to finish it!
Check out A. CYBORG and Mark Sachs’ other projects on Mayfly Studio’s tumblr! http://mayflystudio.tumblr.com/