Oh my. As you can see, I’ve built a new girder module, and it’s a million times more interesting than the last one. The trick, it turned out, was to stop trying to use software built for artists and instead find software built for engineers. OpenSCAD could be a game changer for me.

The cool thing about this tool is you build model files by writing code. There’s no clicking and dragging and getting lost in a maze of modes and menus, just line after line explaining how the model is built. Given that’s exactly how my original 2D graphics worked I find this far, far more intuitive. I’m excited.

What module should I do next?

<3
Farbs

Oh my!

For the next two weeks you can pick up the Card Hunter basic edition for around half price ($12 or more), and get a bunch of other card games as a free bonus. We launched Card Hunter in late 2013 and have since then published a ton of updates, with lots more to come. If you haven’t seen Card Hunter yet, or haven’t logged back in for a while, head on over and check it out.

<3
Farbs

Coinciding with a long phase of working on something else* has been a long phase of figuring out where The Dawn Star’s 3D art will come from. And what it will look like. And how it will be made to look like that. I intend to keep the basic Captain Forever silhouettes and simply extend those ideas into the third dimension, then add extra detail. My original plan was to manually greeble the models, as shown in the command module here:

The problem was, that didn’t result in very much surface detail and grew increasingly complex as I added more detail. Manual modeling just didn’t seem feasible, especially since I have almost no experience with it.

This week I’ve looked into kitbashing, which might yield much better results. The idea there is to take many little pieces from other models and cut and arrange them to make new ones. This can be a very fast and effective way to greeble a model, so should work quite well here. It can also result in highly unoptimised models, which are slow to render and generally unusable in a game. However, since I’m pre-rendering all of my models into sprite sheets I don’t need to worry about that much at all. Hooray!

My next step is to figure out what software to use. I’ve had a lot of success using Sketchup for simple models, but it gets unwieldy as I add detail. 3D Coat on the other hand seems to work well for blatting on techno-greeble-chunks but hasn’t been useful at all for fine detail. So, my new plan is to build very simple and precise outlines in Sketchup and then detail and texture them in 3D Coat. Wish me luck!

<3 Farbs * Adding co-op to the Card Hunter campaign, which will hopefully be finished soon.

Hi!

I released a new build a few days ago, this time featuring an actual in-game module being rendered by the actual in-game module renderer! There was a lot of behind-the-scenes work involved in this, and I’ve never built anything like it before, so I’m incredibly relieved that it works.

Build #8, right here. Clicky clicky!

The renderer uses Multiple Render Targets, or MRTs, which are a new feature in flash. They are pri-tee cool. Now when I draw a screen full of modules I can render out an image showing their diffuse colours (what colours are painted on them), an image showing their lower frequency circular harmonic light radiance (how much light hits each pixel from every direction), and an image showing their higher frequency circular harmonic light radiance (more detail for the lower frequency stuff). Here are some pictures!

Diffuse

You can see here that I haven’t actually painted the command module yet – it’s just flat white, so everything you see in game is lighting detail

Radiance low harmonics

I might be using the word “radiance” incorrectly. I’m pretty new to all this!

Higher harmonics

It’s not really obvious what’s happening here, but trust me it’s cool and useful.

Accumulation buffer

This is where all the lights are added together. Since light brightness isn’t proportional to pixel value, this looks a bit funny until…

Backbuffer

This shows the accumulation buffer translated to pixel values, and is what finally appears on screen. Pretty!

So, what’s the point of this? The point is lights. Many, many, many lights. Lights from thrusters, lights from muzzle flashes, lights from explosions, and lights from missiles and torpedoes and laser bolts. With this information stored in buffers already it becomes incredibly efficient to draw lots of little light sources, which should be perfect for a game like this, and would have been impossible with regular forward rendering. I, uh, don’t actually have any of these lights in the game yet, but I expect they’ll look awesome. PEW PEW!

—

I ran into quite a few issues getting this working, mostly due to a an apparent absence of documentation. I couldn’t find a single article from Adobe about how this works, so had to cobble together an understanding via other people’s source and hours of trial and error. If you’re also looking to use the new flash MRT feature you might find these notes useful:

• MRTs are only available in Context3DProfile.STANDARD, which you pass as a parameter when you requestContext3D
• setRenderToTexture has a new parameter colorOutputIndex, which you set to 0, 1, 2 etc for each of your targets
• Each target used in a single draw must have the same texture format
• Your pixel shader should output to each of the targets, using registers oc0, oc1, oc2 etc to reference them
• Older versions of the AGALMiniAssembler won’t recognise oc0, oc1, oc2 etc. I couldn’t find an official Adobe source for this file but found a more recent version here
• If you render to any other textures later, first call setRenderToTexture with a null target for each colorOutputIndex you are no longer using

I hope this helps someone out there.

<3
Farbs