A typical question that has been around for as long as I can remember is “How many polygons should I be using in a character/vehicle/environment?” Another common one is “How big should my textures be?”

There is only one answer that I can think of – “It depends.”

The reason for that answer is that the question is too vague – it’s like the old question “How long is a piece of string?”.

It depends. It depends on myriad things, such as the visual style of the game, the type of game, the capabilities of the engine and the target hardware. Some consoles can push vast numbers of polygons, and others can’t.

For example, a character for a 3rd person shooter like Gears of War on the Xbox 360 where you usually have a dozen models on the screen at once, in a small compact area of map would have a totally different target for polygons and textures sizes than you would if you were creating a character for a GTA game for the PSP.

The PSP simply doesnt have the processing power of the 360 to push around large numbers of polygons and it doesn’t have the memory to store large textures. The style of game is different too – GoW has smaller enclosed environments, whilst GTA is much more open. Compare both of those games to Fight Night Round 3 (on the 360 or PS3) where effectively all you have are 2 boxers moving around a small boxing ring. With these restrictions on the focus you end up with incredibly detailed boxers with muscles, tendons and sweat.

Finally, compare everything to Mario Kart on the Nintendo DS – there aren’t that many textures and lots of use of shaded flat colours. The hardware is less powerful, and the art is stylised.

So for those reasons, it’s impossible to answer a question as vague as “How many polygons do I use?”, which isn’t exactly much use to you.

So how do you figure it out? For one, you play games and have a look. Look at what details are modelled, and which ones are textured. Have a look at screenshots to see if you can spot repeating textures (remembering that most screenshots are ‘tweaked’). Have a look at game art forums where people not only display their work but usually an overview of it – and on those forums don’t be afraid to ask questions about the art.

An important thing to remember is that the polycount and texture sizes will fluctuate continuously through the project (usually getting smaller). Sometimes the programmers will come up with new compression techniques to allow more textures in memory, and all too often you’ll have to shrink or reuse textures to get them to fit.

We can encourage questions like “How many polygons should I use for the lead character in 3rd person hack and slash gladiator game for the PSP where I have wide open arenas and normally 2 other fighters on screen at once?” – but I think the answer would still be “It depends.”

As a game player, or an artist who modifies games, you will no doubt have heard of an engine in relation to games. However, many people are unaware what an engine actually is, what is does, and how it affects them as an artist. Many people confuse a game engine with the game itself. This is an attempt to explain what a game engine does and why they are used – but to stop this being a novel I’ll approach from the point of view of an artist.

Essentially, an engine is device for collecting, managing and using assets. You put art and sound and logic in one end, and a game comes out the other end.

There you go, that’s that cleared up.

More details?

As I mentioned, many people confuse the engine with the entire game – an engine is not a game, but the core around which a game is written. An engine contains no game, its a layer of abstraction, a layer of processing that sits between the game (fun, story, art, sound, controls) and the hardware.

In the old days games were essentially written for specific hardware. They were one off chunks of code – you came to your next game and you rewrote it from scratch. Quickly programmers built up a library of reusable code, so that, for example, once they written had a good system for handling sprites they could simply copy that code into their next game – perhaps verbatim, perhaps making minor or even major improvements.

Reusing code is a great idea – rather than starting everything from scratch each time, you get a major head start. Soon these little snippets of code build up, and then you realise that playing sound in your last game and playing sound in your next game is the same, it’s only the sounds that are different. Just record the new sounds, bung them in and hey-ho, away we go.

So, rather than writing a game from the ground up each time, an engine provides a core to work around. When developing a game, the artists export their models and textures and animations into a format that the engine can read, as do the sound engineers. The game programmers write a control system that maps buttons presses on a joypad or a keyboard to actions in the game, but the engine does the work of translating the signals from the joypad into something we understand, like ‘Up’ or ‘X Button’.

But what will all those programmers do now that we have engines? Lots of things – they’ll find and fix bugs in the engine. They’ll make the engine run faster. They’ll add new features (and then fix them. And then make them faster). And they’ll even write nice tools for us artists to make it easier to get our artwork out of our heads and into the game.

Hurray for engines!

It’s getting there. Adding in some of the alpha planes and trinkets has helped add character.

I’ve been chipping away at this beast, and hopefully by the end of the weekend I’ll have the hair complete.

I spent last night and this morning working on the feet. Feet are not fun to model.

Not much yet in the way of Thunderhawk, but plenty in the way of solid base model.

Gordon is working on an Evil Ryu, and Lobster/Bear is working on Makoto

See everyones work at http://boards.polycount.net/postlist.php?Cat=0&Board=contest

Polycount are running a new 30 day challenge to redesign, model and texture a Street Fighter character in 30 days. The rules are fairly simple, and I’ve chosen to work on Thunder Hawk.

Some time ago I realised that my ability to draw is somewhat lacking, and fortunately a dear friend has kindly offered to work up some concepts for me. These will be posted when he’s had the chance to clean them up.

People are always posting images of their models online and asking for feedback. Unfortunately at times the model is presented so poorly that it makes giving feedback nigh impossible. The main problems are tiny images with no contrast on the model but a huge contrast between the model and the background. Hopefully this will give you some points on how to present your work in a better way – because you’d rather people commented on your model than on your shoddy presentation skills.

Firstly, make the images big enough to see – a 200×200 pixel image just doesn’t cut it. The bigger the better, within reason, but remember to crop the dead space from the image as there is no point in posting an 800×800 pixel image and only using a tiny part to contain the artwork. With larger images come larger filesizes , so you’ll want to optimise it (Photoshop and ImageReady both do this well). Compression can be a problem, but if you save as JPG with 60-70% quality you’ll probably be fine.

To keep people focused on the artwork, make the background a neutral gray colour. Bright colours are distracting, and very light or dark backgrounds made it harder to pick out details, edges and contrast. Why do you think most 3d packages use a neutral gray background by default?

If you are posting on a website or a forum, try to embed the image into the discussion rather than using text links. It stops people having to click backwards are forwards.

There is always a debate over whether screengrabs or renders are better. I prefer renders, since I can drop a few lights in the scene to pop out the details, but they take time to set up.

If you do decide to render then you’ll want have at least 2 lights, one key light and one fill light so that the shape can be defined. You need lights to to pick out the shadows so that the form can be seen. Skylights are all the rage, but without at least one directional light they can make the model appear flat. There is an excellent tutorial on 3d lighting at http://www.3drender.com/light/3point.html which will help you understand what the key and fill lights do.

The lighting of a model is subjective, and depends on what you want to highlight – the geometry, the colour/diffuse textures, the specular/normal maps all require different presentation to pick out various aspects. It’s often much easier to read geometry when there are no textures applied and you have one or two solid colours. Colour/diffuse textures often benefit from very flat lighting, and showing off normal/spec maps usually requires a strong directional light. Experimentation is the key here, but experimentation takes time, which is another reason screengrabs are popular.

Whether you choose to screengrab or render, you really should use a perspective view – using an orthographic view will cause the model to look distorted as you’ll have no foreshortening or depth. Ideally you’ll also render or grab your model from several angles and either post separate images or compile them onto one larger image. As well as front/back views, a 3/4 shot is very useful.

Render/screengrab with and without a wireframe. The wireframes are essential if you want people to give feedback on the flow of your mesh, and they are easy to setup. The simplest method in many 3d packages is to duplicate your model and make the duplicate every so slightly larger, then apply a wireframe material to it.

Some final thoughts
If you want critique on a specific area, ask for it and provide a closeup shot of that area – remember you can crop it to just the part you want to highlight. Similarly if youwant an area to be ignored for the purpose of feedback, state that – but don’t be upset if people comment on it anyway.

Technorati Tags: feedback, 3d artwork, presentation skills

Gordons series on building a 3d character is cracking along. Go check out his second part on laying out UV maps.

Oh, Adam Bromell has joined the blogging games artist group – so check out his site.

Technorati Tags: 3d modelling, uv maps