Baby steps – Planet and Stars

How do you wrap a 2D image around a sphere? Well, the most familiar way to me is what 3ds max calls spherical mapping; you’ll have seen this if you’ve looked at a 2D atlas. The top and bottom poles of the sphere get a much larger area of the image than the middle of the sphere. Without correcting for this in some way, the top and bottom seem very pinched. I found a way of correcting for this, for a (horizontally tileable) texture in Photoshop. You can download a little action I made to help with this here. I’ll try and illustrate what you get from it with an image:

Top left – front view of sphere’s geometry with yellow UV seams at poles; top right – UV layout; bottom left – a cheap 2D grid texture I photoshopped together using my action; bottom right: the resultant sphere with texture applied. Although the grid on top and on the sides doesn’t match up, at least the scale is relatively consistent, which for most textures will be the most obvious thing if standing out.

Another way of mapping spheres, with less distortion, is using a cube map. This is just 6 images representing the positive and negative of the 3 axes – front, back, left, right, top, bottom. I’m probably going to use this method for a static “spherical” environment of a star-field, to indicate far off, where there is no geometry. It’s very cheap on modern graphics cards, and you can generate them in 3ds max easily using an existing environment. Here’s a quick test I did in the engine:

The cube map starfield was created in about a minute using a pflow system in max. It is apparently possible to generate a “real-time” cube map starfield texture procedurally, but I doubt my skills will be up to it in the near future. I’ll probably just create something prettier in max and photoshop, or maybe not use cube maps at all and go with pure geometry.

In the above image, the planet is a geosphere (triangles and no geometric poles) with spherical mapping using the method above with a PS generated texture. Obviously the lighting and shading are really dull at the moment. The vertical poles look pretty good, except when the LOD mesh kicks in – probably a UV interpolation issue. Not yet sure whether to go with procedural planets, moons etc, or bitmaps. I’ll leave it to when I really want to overhaul the graphics!

Did I mention I wouldn’t update regularly?

You may have thought I’d given up by now – over a month without an update – but despite seeing such incredible similar indie projects as Infinity Universe (well worth checking out for the crazy scale – over 7 years of dev! and multitude of tech posts), and Salvation Prophecy (also awesome, and actually released), I’m still working on the game. Granted, I haven’t done as much as I would have liked, but then I never do.

Seeing the great projects linked above has filled me with amazement for how much one person can do, as well as depressed me by showing me how much I have left to learn. So I’ll try and keep the scope of this game pretty low, as I don’t want to be working on it forever! I also started watching the first season of Firefly, which I’m loving, but can’t believe how Mr Whedon stole half my ideas before I’d had them! Seriously though, that is almost exactly how I’d pictured the state of civilisation in my far-fetched fantasies about this game.

Ok, here’s some stuff I did in the last month in pretty much chronological order:

  • learned some of Zbrush 4R2 and figured out a new, better modelling workflow (along with 3ds max), which I’ll put up a video of in the future. It’ll be useful for any 3d modelling project, really, not just games. Did some spaceships with it.
  • Improvised and recorded a sum of around 10 minutes of guitar “music” for the game – who’d have thought your skills degenerate so much after a year of not playing? Tried out FL Studio.
  • Messed around a bit with Ogre, read articles/book on game programming, a bit of C++.
  • Started a clean framework for the game, using http://www.ogre3d.org/tikiwiki/tiki-index.php?page=Advanced+Ogre+Framework&structure=Tutorials
  • Started learning shader programming – all that maths screws with my head. The pain is not alleviated with this complicated (for me anyway) free book GPU Gems 2

I’ve been using FX Composer to write some shaders, such as this: Image

A 2-pass planet-y shader. Quite simple, I suppose; the atmosphere pass expands the vertices along their normals, and then colours using a “falloff” like pattern (if you’re used to max’s material system), and there’s a basic blinn shader as pass 2. Unfortunately the way I implemented the atmosphere (writing colour without depth) means it doesn’t work in Ogre when I ported it over. But I knew I’d have to re-write it anyway! I want to figure out a way of doing procedural noise-based planet textures – I’m pretty sure you can do lots of the work on the GPU. It seems everywhere I go for this sort of thing, this guy pops up as being a colleague of the writer: Inigo Quilez. I first came across him about a year ago; he seems to be a total genius having read the majority of his stuff!

Ok that’s enough for now. If you want any detail that I might be able to provide, don’t hesitate to ask.

Getting used to Ogre 3D

I’ve been using Ogre for a few days now, just going through the tutorials on the website and messing around, and I really like it. After the pain of programming a uni project directly in OpenGL, I was kind of dreading how much work it would be just to get a model into a real-time renderer. As an analogy, imagine wanting to cook a nice meal, and having to build the oven first – you know what you want the oven to be able to do, but actually going about it is a slow and painful process.

However, with Ogre 3D, the oven is built for you! If I don’t want to, I never need to go into quaternion maths, building a scene hierarchy system, frame listeners or any of the other complex engine necessities. After years of using 3dsmax, I found the Ogre workflow really simple and straightforward. There are lots of nice features and it seems robust. It is not too bloated in my opinion either – although the set-up process was rather long. The tutorials on the wiki website are really easy to read and learn from, although one was unable to compile on my computer. http://www.ogre3d.org/tikiwiki/tiki-index.php?page=Tutorials

Here are some screenshots of the demo scene I just made (having done Tutorials 1-6), using some example media and my own ships/ space-station:

You can read the code I wrote to create the scene shown in the screenshots here: http://www.evernote.com/shard/s121/sh/58d7c731-1507-4e4d-9e3d-8c9b14ef2005/71b5b5d250ca72c7173b8478e5b66395 – there’s exponential fog, texture shadows, a spotlight, a skydome, and some C++ structures like for loops to get me back into the flow! If you know some C++ and are somewhat familiar with making 3D graphics, I think the code’s pretty short and easy to read.

The structure of getting models into the engine takes some getting used to. There is a human-readable .scene file (which can be exported from Max, Maya, Blender, etc) and a dotSceneParser class. What this means is that scenes can be altered from within the .scene file, .mesh files and .material files without you having to recompile the source code. It’s amazing that you can use Max as your game editor almost, placing lights and objects, without having to constantly recompile your C++ code!

Here’s a screenshot of the “Easy Ogre Exporter” open-source Max plugin, http://www.ogre3d.org/tikiwiki/Easy+Ogre+Exporter, which is a really nice and simple way to get max scenes into the .scene format:

I had a really enjoyable few days taking it slow and learning all about Ogre – I don’t want to get disenfranchised by jumping in to making the game too quickly and doing everything wrong. Also I bought a load of expensive computer parts to make a new system, which will speed some things up a lot compared to working on my laptop – compiling and running the game takes about a minute, and those minutes sure add up. Hopefully I’ll start making the actual game soon though.

A Shaky Take Off!

I’ve been trying to set up the OGRE 3D engine for the last couple of days (you can read more about it here: http://www.ogre3d.org/tikiwiki/tiki-index.php?page=Getting+Started), and finally, after failing to build it from source, and install the Eclipse SDK, had some luck with Visual Studio 2008 – the default solution!

I might actually write most of it in Eclipse because I loved the features such as clever highlighting, version compare when I was writing Python scripts in Maya using it. I guess I’ll have to get used to Visual Studio though, because it is painful going through the Ogre installation process. I don’t want to try it again if I don’t have to!

It was the best feeling getting the sample browser file to compile after hours of failure on many fronts. I spent an hour absorbed in the samples in the engine, which demonstrate all kinds of pretty new features that the best games today have, and some that I’ve never seen (Real-time Julia fractal 3D volumetric textures?). It’s nice that you can switch in-game between OpenGL and DirectX as well.Image

It’s great being able to see the FPS impact for every feature and effect – I never knew bloom would halve the frame rate. The whole demo has given me the confidence that it’s possible to create a really spectacular game using the engine, so I’m excited. The thing now is putting in the time and effort! I have a lot to learn; as well as the book I mentioned in the first blog post, there’s a brilliant website that feels like exactly what I need: http://www.altdevblogaday.com.

I’ll try and update again soon with some programming tests.

Rendered 3D Ships

Here are a few prototype ships for the game. I tried to keep everything quads (for unwrapping and zbrush sculpting mainly), and each object as few separate elements as possible. The poly flow is a bit awkward in places, so they may need to be scrapped completely in future. Each ship is between 300 and 700 polys – obviously future iterations might be higher detail, but I’m thinking it might be possible to optimise this game for mobile devices – assuming I finish it before phones come with graphics cards.

I’m not sure on the limitations of the engine because I still haven’t decided on an engine. I’m looking strongly into Ogre 3D, because it’s free and open source, and shouldn’t take too long to get to grips with the workings of the useful features (unlike something like Unity I presume).

Render done in 3DS Max/ Mental Ray, with generic ceramic material from autodesk. The distances between ships aren’t equal, so shadows look a bit weird. I think the ships should be roughly around this relative scale. The bottom row is just the ships above, rotated 180 degrees around vertical axis so as to get a good view.

Image

Spaceship concepts

Well it’s been a few days since my exams finished, and despite a hectic new lifestyle of sunbathing on the beach, I’ve had time for some drawing. I came to it a bit scared – you can see my progress from never having designed a spaceship up to having drawn 80 or so ships. Drawing and design has never been my strong point though, from perspective/ drawing a straight line, up to anything more advanced!

There are a couple of stations and things in there as well. I found it tricky to think of novel designs, and I’m sure some of these will seem derivative from films, games etc. I initially thought I’d do about 10, so I surprised myself with how many unique concepts I could come up with. I will probably need to visually unify the various ship factions, such as giving the enemies a distinct style so as to be easily recognisable, so more design may be inevitable.

I’ve started modelling a few of them in 3dsmax for importing into the game engine, so expect an update with renders soon! I’d love to know which ships you think are the better ones.

Game design document

Here’s an imaginary path for each iteration of the game that I’m making. If you have any ideas that you would love to see in a game like this, I would love to know! I enjoy keeping the ideas quite freely moving and changing until I have to actually make that version.

Version 0.1

  • A couple of planets, with gravity forces.
  • A rudimentary ship with a thrust and mouse-controlled turning, that can collide with the planets
  • In deep space, thrust is needed to accelerate or decelerate; thrust is also needed to land on planets else you die.
Version 0.2
  • Static enemy turrets, that can fire lasers at the smuggler ship
  • Smugglable resources and fuel on planets; cost money
  • Multiple solar systems
  • An exponential thrust system for the smuggler ship to quickly cover large distances
  • Fuel supply and damage amount for smuggler ship
Version 0.3
  • Other solar entities such as asteroids/ asteroid fields, stars, non-inhabitable planets – all cause damage to ship.
  • large-scale enemy ships with AI to avoid asteroids and planets, and fire at the smuggler
  • improved graphics 🙂 sound effects.
  • Trade/ smuggling screens for each planet’s resources
  • save/ load games
Version 0.4
  • Guns on the smuggler’s ship
  • Physics collisions with parts of smuggler’s ship breaking off
  • Modular repairs/ upgrades for smuggler’s ship, with per-module damage amount.
  • Small enemy ships with AI to chase the smuggler quickly and shoot at it.
  • Directional boosters (left right up down) for smaller ships.
Version 0.5
  • Ability to call for ally backup a limited number of times.
  • Galactic map…
  • Distinction between options of trading legal substances for less money or illegal substances with higher risks
  • Nefarious pirate ships
Version 0.6
  • Shady repairs, and occasionally vendors of ‘legal’ goods/ supplies, can screw you over.
  • Shields/ cloaking devices that fail if you take damage
  • Fuel stations and repair stations as well as planets
  • Non -smuggling ‘missions’ – take down satellites, get bounty hunters/ assassins trying to kill you, team up with other smugglers and protect them from incoming fire, kill off other smugglers taking your business, low-level flying and bombing planets.
Version 0.7
  • Ground level chases from tipped off police ships when loading/ unloading cargo
  • Given option to switch sides if your ship crashes on a habitable planet – you start taking out other smugglers and shutting down illicit substance manufacturers.
  • Buy planets to gain a steady income from illegal substances grown/ mined/ purified, but with high risk
  • Possibly combat mechanics like slow motion, different weapon types

I’m trying to think of a catchier name for this project than “smuggler game”. Do you have any ideas for a unique and interesting-sounding name? Thanks!