Mayfly Studio

What’s with this fleet of space pinwheels??!! It’s successful test data, that’s what!

Although the models in this game (assuming arguendo that I ever make a game) would be quite simple and low-poly, they still would need to, you know, exist. Which means I have to make them. Which means I have to figure out how to make them. I found myself in much the same annoying spot I was with Neon Galaxy, where I needed some way to manufacture a reasonable number of simple models that didn’t make me want to kill myself. Back then, I first experimented with using Inkscape, which is nightmarishly awful and broken, and trying to decode the .svg format which is lousy with exceptions and additional elements and random stuff which a tool might decide to throw in for no particular reason, making a minimal-subset importer very hard to maintain. This went tremendously badly, and in the end I just wound up drawing the models on graph paper and typing them into a simple XML format I devised.

This turned out to be just fine for 2D vector models. 3D is a harder case, though. I experimented with sketching a few things and quickly realized it would be a giant pain to triangulate the models by hand. I took a brief stab at using Google Sketchup to make models. And to be fair, it would probably be fine to use Sketchup, although it was surprisingly easy to crash the tool by adjusting texture coordinates with a bit too much gay abandon. But then the question of getting the model from Sketchup into my game reared its ugly head. The only option, if I didn’t want to pay $100 for Sketchup Pro, was to use the Collada (.dae) format. A quick scan through the .dae file demonstrated to my satisfaction that I don’t want to write a Collada importer by hand, so with trepidation I put on my khaki vest and pith helmet and went out onto the Internet to see if there was a library I could use.

Now, you might accuse me of giving up quickly. You wouldn’t be inaccurate, I suppose. But when I downloaded OpenCollada DOM, perused its extremely simple instructions for compiling on OSX, followed them to the letter, and promptly got a bunch of incomprehensible errors from make, I had a vision of the future and that future included hours of fighting with the library and screaming at it to get it functioning at all, and further hours of baffled dredging through code after some trivial change somewhere breaks the library for no good reason, and further hours of wondering why something doesn’t work because it’s a random bug in the library interface that nobody’s going to fix because it isn’t as sexy as rewriting the internals for the billionth time or some loudmouth thinks that’s the way the design should really have been all along, and further hours of searching forums and finding only years-old inquiries from other people with the same problem who got no answer… and I said the hell with it. I’ve seen this movie before, I know how it ends.

Instead, I went back to the drawing board and reconsidered the problem. No doubt some effort will be required on my part to design these ships by hand, but how can I practically leverage the computer to make it as easy as possible? And I had a realization. These ships are all going to be fairly simple, geometry-wise. There’s no reason they can’t all be made out of elements from a list of standard shapes! I can break each ship into geometric pieces, define the pieces in XML relatively easily, and the computer can transform the pieces into place as per my instructions and take care of triangulating the model and computing the normals, and… everything will work out fine!

So far, it does. I’ve implemented one shape (a pyramid with an arbitrary number of sides) as a test, and ensured I can define it in XML including texture coordinates and request an arbitrary number of them be placed in an arbitrary fashion to build the final model. And that, frankly, is pretty great.

Further buttoning this up will require adding several more basic shapes (cubes, wedges, planes, hexagonal wedges…) and cleaning up the interface between the geometry data and the rest of the program; right now it’s violating some object orientation law or other I forget by leaking lots of state back and forth between the object and its client code. (Is it the Law of Demeter? No, not quite.) Also the shader might or might not be computing lighting correctly. But by and large, this is a satisfactory proof of concept and should suffice for getting all the models I want into the game.