News Archive
Currently viewing posts in the ‘Behind The Scenes’ Category.
May 16th, 2011

Thought we’d throw this out there – more behind-the-scenes tech tips. Here’s a little look at part of our texturing pipeline. So – it’s the classic problem: how to make lots of art assets with a small art team. A very small art team. So, we already know there’s going to be quite a few different cars, each with a different 3D mesh, and hopefully different versions of each car, like the Turbo version or the Bling version, each with their different mesh. And of course, it makes sense to have different paintworks for the cars as well – after all it, it should just be a different texture map, right?

But when you think about it – it’s not quite that simple. If we’ve got five different cars, and each car comes in five different flavours, and there’s going to be 10 different paint-jobs, each available on each car, we need 25 versions of EACH of the 10 paint jobs. Hmmm. So…time for a bit of texture-mapping wizardry.

For my next trick we’ll be using Nuke, which I absolutely love. It’s a node-based compositor – it’s usually used for Hollywood special FX, but at its core it’s a very powerful, flexible bit of image-manipulation software, and it’s super-useful for texture mapping problems like this one. You could also use Shake, Toxik or even AfterEffects, but Nuke’s my weapon of choice right now. There’s also a free learning edition, check it out, you should be able to pick it up in a few days if you already know the principles of compositing.

Right, so what we do is – we make it so the art team (in this case, me) can just make a single image which defines a sort of generic paint style or ANY car, and we’ll use Nuke to fudge it into loads of different shapes and sizes to build texture-maps specifically fitted to the UV layout of EVERY car.

Mmmm...tasty node-based compositing spaghetti....

so the flow is:
1. Generic texture that works for all cars is made in Adobe Illustrator and exported at reasonably high res, cos it’s gonna get warped and stretched all over the place.

2. Texture gets split into its component parts – base pattern, logos, trim colour, lights colour, etc.

3. For each different mesh (there’s only one in this example cos we, er, haven’t finished the game yet) the base texture elements are placed so they wrap seamlessly over the car. This is fiddly – if you think about it, it’s like trying to wrap a toy car in paper without folding the paper. Tricky. We’re using the excellent SplineWarp deformers in Nuke to squish the base texture around, distorting it as if it was elastic that tightly wraps around the car. This covers it seamlessly, but of course it’s distorted a little.

4. Then the other elements – logos, badges, details – are slapped on top of that. They don’t need to be seamless, which means we don’t have to distort them to fit the shape of the car, so circles come out circular and squares come out square. This actually looks pretty cool.

5. The car-specific details are slapped on top of that. Random aside: the way we did this is, just make details in illustrator – these can have transparency, and use normal, screen or multiply transparency. We export it twice, first with white behind and then with black behind, and by subtracting the two, we get a lovely alpha channel that lets us blend in the paint really nicely.

6. Another nice thing in Nuke is you can have 3D stuff in there as well. you can see we have an OBJ file of the car loaded in so we can check that the paintwork looks cool. And once we’ve got more cars in there, we’ll see the same paintwork across lots of different cars, which is going to be completely awesome.

Shiny! Might put the texture test pattern car in there as a secret unlock...

Works pretty well, we actually did something similar for the 100 different planes in MiniSquadron and MiniSquadron Special Edition.

Some quick tests with placeholder textures....

Ok, there you go – if you think that looks silly, you should see the nuke setup for converting the maya-generated spherical environment maps to the 32x32x32 environment cubes supported by the iOS hardware, but that’s a story for another day…

:-)

May 2nd, 2011

Ok. So, we know what we want our game to look like. And we want it to be 3D. So…er…how do we actually make a 3D game for iPhone?
Obviously there’s quite a few bits to this, but today we’re gonna look at making a 3D mesh and getting it to show up on your device. Now, this here certainly isn’t the only way to do it, and it’s probably not the best way either, but it’s quick and it works, and it’s what we’re using for Drive Forever.

This is quite an “asset-heavy” game – as in there’s tons of different cars, buildings, bonuses and so on, all of which need modelling and texturing. And because they’re all using fancy custom shaders, we need to see them on the iPhone as we’re making them, so we know how they’re going to come out (the other option was to write a custom viewport shader for our modelling software, which would have been pretty rad, except then we would have to make TWO versions of every shader that looked identical – nightmare).

So. We’re making our meshes in Autodesk Maya, although you could use whatever you want really, there ain’t gonna be millions of vertices or fancy NURBS surfaces or anything. We wanna see them on the iPhone. So we made a button in Maya that does it.

It’s the green one that says ‘build’.

Just press the button! Almost TOO easy!

Simple! Well, it is now, it was a bit fiddly making the button. So, the build button pops up the export window, which is just a standard maya window written in Python (could have used MEL but whatever). When you hit the Export button, another Python script runs, doing the following:

1. The Maya scene has already been set up in a neat, ordered hierarchy (you can see it in the Outliner window). When you hit export, it builds a directory structure on the hard drive that matches the maya structure. Super handy – we do NOT want to be manually moving files around, that’s how things get messed up!

2. Each object for export is actually a group consisting of: one ‘metadata’ node (actually just a NURBS curve with some custom attributes) and one or more geometry nodes. The script exports each object to a separate file using Maya’s DAE_FBX exporter (more on that later).

3. Then it creates a simple TXT file in the same folder, containing the object’s metadata. At the minute, that’s just an OBB and stuff like that, there’ll be more eventually.

4. Now it starts to get a little more involved. The Python script in Maya executes a second program, a C++ executable Tak wrote, called Meshbuilder, which does all sorts of fancy stuff.

5. First, MeshBuilder loads each DAE & TXT file pair and combines them to create an MSH suitable for use on the iPhone. It’s using the comically-named open asset import library, AssImp.

6. It replaces the Phong or Lambert materials that have been assigned in Maya with the crazy custom shaders. Interesting side note – this is super hacky! We just put a suffix on the NAME of the maya material to tell Meshbuilder what shader to use. So, for example, if a material name ends with “_matteEmissiveShaderRG”, MeshBuilder replaces the lambert material with a custom shader which uses the red channel of the texture map for the albedo, the green for the emissive, and then tints the material with a runtime-generated colour. There’s definitely a better way of doing that, but hey, this works and it was quick to code, so we can just get on with the game.

7. Then Meshbuilder looks through the DAE at all the textures on the meshes, and looks at which ones have changed since last time. Just for fun, MeshBuilder then calls another executable for all the modified textures, this time a free image convertor called PVRTexTool, which turns the uncompressed Targa textures into creates highly compressed textures that’ll run much faster on the iPhone, and generates mip-maps as well.

8. This is the cool bit. Now, there’s another program running on the iPhone, called MeshViewer. The phone needs to be on the same wireless network, and use something like Network Ping Lite to find out the IP address. Meshbuilder then sends the mesh to the phone over wifi, and it just pops up on the screen, which feels pretty frickin’ 2011. There’s some basic debug controls on MeshViewer, letting you pan, zoom and change lighting, that’s about it. It’s cool though. As well as practical applications, it could also potentially be used for comedy, wirelessly sending detailed 3D meshes of penises to people’s iPhones. Just a thought.

Where the magic happens, part 2

That’s about it. The texture compression step takes a while, often 20-30 seconds, but that isn’t necessary if you’re just editing the mesh. If you just tweaked the mesh and didn’t change the texture, it pops up on the phone about two seconds after pressing the button. Since there’s going to be around 200 assets, and each one will probably take 20 or so tweaks to get right, this little button is probably the only thing standing between the art team and total insanity….

:-)

April 28th, 2011

Right. We thought we’d kick off our series of behind-the-scenes posts with a look at how a game gets started. Drive Forever started in the usual way – we were just chatting, and then somebody used the magic words:

“Wouldn’t it be cool…if…”

Very soon after that, well – it was time to do some doodles. This sort of thing:

There we go. Pretty much done.


That was helpful, but to be fair, it still needed a little work. We talked some more, and it turned into something like this:

Drive Forever V0.001

You can see the basics elements there – a single car, driving along a sinuous road through a sparkling city. Needs a little more, though?

The more astute amongst you may have noticed that these are just drawings, they’re not an actual game – just to be completely clear, all the images here are quick concept sketches, rather than exactly what the actual ingame graphics will look like. The finished game will be shiny 3D graphics, rather than somewhat wonky hand-drawn images!

So, since this was to be a 3D game, we started playing around in 3D. This was interesting.

Hmmm...not quite right...

The thing about this was – it wasn’t quite there. Yes, it looked like a city. And yes, it looked like a racing game. And in a way, that was the problem. There are lots of racing games, and by and large, they tend to look fairly similar. But why?

One problem here is that we were trying to make it look kinda real. And so is everyone else. Since reality looks a particular way, all the ‘realistic’ games end up looking sorta samey. So, the obvious thing – reality is boring! We went back to the drawing board, trying to come up with something a little more…well…different.

What about something…more….like…

THIS?

Ok. Now, that looks DIFFERENT. Whether it looks good, that’s a matter of personal taste, but it definitely looks different. You know what? There was something about this that we liked. It had its own thing going – far from perfect, but a step in the right direction. Here’s where it’s useful to be an independent games company, because there’s nobody in a suit to walk in and tell us “what the hell, car games don’t look like that!”….

So…lets see where that takes us!

Check back soon, there’s plenty more behind-the-scenes action coming up! And feel free to leave comments!

:-)

February 25th, 2011

Screenshot of our new 3D engine....shiny!

Hey! We thought you might like to see what we’ve been up to. We’re working on a new iPhone game.

Our whizz-kids have come up with a new 3D engine using something called deferred rendering which basically makes everything look completely rad.
For the geeks among you: it handles diffuse and specular illumination for up to twenty dynamic, coloured lights, along with bloom and environment reflections, in real time. For everyone else, here’s a cool shiny car we made to test it. Check it out!



Big thanks to Static at Unit303 for the music!

Our new game is gonna be out in summer 2011. It’s got cars in, but it’s not really a racing game. Oh, and it’s going to be awesome. Check back here, we’ll keep you posted…

For the curious – full resolution screen grabs from the iPhone 4.0 are available for download here.

September 17th, 2010


Lots of you have been asking how they can keep in touch with the latest Supermono news – don’t worry, soon we’ll have RSS feeds and newsletters and all those things you people love.

For the moment, though, you can follow Tak on Twitter. You’ll get up-to-the-minute updates on all our games, plus ramblings about all kinds of other things…