Go Back   AC3D Forums > Resources > AC3D Tutorials and How-To's
Register FAQ Members List Calendar Search Today's Posts Mark Forums Read

Reply
 
Thread Tools Display Modes
Old 23rd September 2008, 02:21 PM   #1
headerko
Junior Member
Member
 
Join Date: Jun 2008
Location: Slovakia
Posts: 20
Lightbulb Charater Creation for games - the whole process (by Lisa)

Here is a great complex guide to character creation for games, by Lisa who was kind enough to spend so much time writing this after i asked for her help. And here by i would like to thank her.

So thank you very very much Lisa. I am in your debt.

The next few posts will contain the super guide that is so long that it actually does not fit into one post.

Last edited by headerko; 23rd September 2008 at 02:37 PM.
headerko is offline   Reply With Quote
Old 23rd September 2008, 02:24 PM   #2
headerko
Junior Member
Member
 
Join Date: Jun 2008
Location: Slovakia
Posts: 20
Default Charater Creation (by Lisa) - PART I

Hi headerko!

I'd be happy to share some tips!

Quote:
Originally Posted by headerko
The thing is me and my friend would like to, at least try to, make a mmorpg game. It will take ehm at least 2 years to realease the first playable version and i am well aware of that. You could say we are doing more "learning" for now.
Two years is pretty good for an MMO, even for a pro team. FWIW, nearly every game I've worked on has taken somewhere between 18-24 months, and none of them had any massively-multiplayer components except Tiger Woods which had the "Play Against the Pros" thing. MMOs often take quite a bit longer.

Don't feel like you have to wait on a "playable" until you have the whole thing though. The best thing to do is set small milestones for yourself, where each milestone is a playable--albeit very incomplete--game. Pick one feature for each milestone and see it through to completion. The first "build" of Speeding Ticket was literally a car and a lamppost. Ditto for Splashdown, a jetski in a puddle. Seeing something working is a great way to keep up enthusiasm when it gets tough! But more importantly, it means you always have a working build. As they say "100% of the features 80% complete is of no use to anyone, but 80% of the features 100% complete might well be a perfectly shippable product."

Quote:
Originally Posted by headerko
Anyway, he needs some character he could start practising with. And thats whats supposed to be my role, heh, and thats where i need your guidance
The game will be made in java 3d (he is obsessed with it, so theres not much i can do about it).
Java3D isn't such a bad choice if you wanted to make it a browser-based game... Runescape for example may not be sexy, but they did manage to sell quite a few subscriptions and got other good gigs from it, like the Hello Kitty MMO. Java's not the fastest thing in the world but if you plan your art carefully you can still do a lot with it, and the learning curve is not too bad.

Again, just plan around what the engine can and can't do. Remember, your wrist watch has more computing power than most of the older consoles and handhelds, but look what great games there are for those systems!

Quote:
Originally Posted by headerko
To the point... the things i would like to know are what "Steps" one has to make when creating a character for a game. The most important part is, how do you specify how the parts of the model will animate in the game. I see everywhere some model rigging, like creating a simple skeleton like structure in the model and then somehow gluing them together? That's where i am a bit confused And can this rigging be done in AC3D as well, or do i have to use something else (e.g. Blender?)
Hmmm... this is terrifically over-simplified, but here goes:

- Concept art. Always, always, always have a concept before you start. It's a lot easier to fix an idea than it is to fix a model. It's not just about having cool ideas, it's also about planning how you're actually going to achieve the character. How many polys? What features? i.e. Older games have an awful lot of characters wearing kneepads and elbow pads not because kneepads are so cool, but because you don't have to skin the joints if the armor is placed carefully. Is your engine really good at something? Think about how you can show that off, too!

- Think about what parts are going to animate in the concept phase. Some people sketch the skeleton, too, as a series of balls where each joint goes with a line connecting them showing the heirarchy. Once you've done a few models you probably don't need to sketch the skeleton every time, but it's important to have an idea of what you're going to do. Another important thing, especially for MMOs, is deciding whether or not you are going to share skeletons between multiple characters. This cuts down on animation data *a ton* so it's a really good thing, but it's often hard to retarget a skeleton from one character to another if their proportions are radically different. If you plan on sharing skeletons, you'll want to plan which characters can share. Fat and thin doesn't matter (to a point), but you'll want to watch things like the distance from the pelvis to the shoulders or from shoulders to the elbow.

- Build the model. There are of course a million opinions on how to go about this part. I'm partial to box-modeling myself, but it doesn't really matter which technique you use as long as it gets the job done. Important things to watch for if you want to animate, especially for games:

a) Interior faces. If a surface can't be seen, delete it. That goes for the bottoms of coffee mugs, the backs of buildings, parts of the character underneath their clothes, etc. This saves polys, and it also saves time when you go to assign surfaces for animation.

b) No t-joints. A t-joint is where you have to faces meeting together with a third face that spans the top edge of the other two faces so it looks like a letter-T. These tend to crack and mess up your texture mapping. http://escience.anu.edu.au/lecture/c...age/tjoint.gif

c) Joint deformations. This guide has really good pictures: http://www.pig-brain.com/tut02/tut02_01.htm Sometimes depending on your engine, you may need to make some variations. The legs on my dog, for example, use the same basic layout shown in the tutorial with a "pyramid" on the back of the joint so they collapse properly. But, my joints also have a slice across the front--normally a bad thing--becauseI knew both the engine I'm targeting and Poser weight the joints differently than other tools and I needed to split the joint into two materials because of that. It's also not obvious from the picture, but the dog has a large number of dummy joints especially in the head specifically to control how the different parts blend together. For example, there's a dummy joint between the head and the eyes, so that when I move the head it doesn't cause the eyes to move or deform. Ditto for the ears, jaw, and tongue.

I *highly* recommend just building some basic joints and animating them until you get a feel for how it works. Make a tubeworm with a really long spine for your game.

d) Edge loops. This sort of falls under "joint deformations", but basically anywhere you have muscle groups that can deform you want smooth rings around the area so it flows from one part to another. This is especially important around mouths and eye sockets. http://cube.phlatt.net/home/spiraloi.../modeling.html Also: http://www.et.byu.edu/~csharp2/index_files/image043.jpg / http://www.et.byu.edu/~csharp2/#G_Edgeloop

Now, ironically, the second tutorial link there says this is impossible with box modeling. Not so. "Make hole" is fantastic for starting a loop from a model created with the box method. Make a hole, then use "create ordered surface" to fill it. You have your first loop. Select the ring around the surface you just created. You can use divide loop as many times as you want to create a series of concentric rings from which to build as many loops as you need to sculpt it out. It's also possible to do this by extruding and then scaling the extrusions back smaller than the original surface.

- Do a motion test. (optional) If you're not sure if your joints are going to work, you might want to pull a work-in progress version of your model into your animation software to test the joints. (More on how to do this in a moment.) You don't need to "rig" the model completely to do this... a couple of bones, even if they aren't adjusted properly, will usually tell you if a joint is going to pinch or tear without spending a long time making a rig that you'll have to throw away. Make any adjustments to your geometry until you're confident its exactly as you want it. If possible, import it into your game engine and make sure it looks okay there, too.

- Texture map your model. Some animation software makes you start *completely over* if you don't uv map your model before you rig it, so I generally try to do at least the texture layout *first* even if I don't paint the actual maps right away. A few texture tips:

a) Most game engines require square-powers-of-two for the textures. (1x1, 2x2, 4x4, 8x8... 256x256, 512x512, etc.) Even when it's not required, square power-of-two generally performs much better.

b) Most games use "unified maps", meaning everything for the entire model fits on one texture map. (Unlike film where one model may have dozens of textures.) Occassionally for characters the face/hands and the uniform will be different maps, especially when the uniform can be swapped or shared between multiple characters.

c) Give the most space to the parts of the model that are most important versus the parts that are largest. i.e The face might take up as much as a quarter of your map, but the bottom of the shoe only a few pixels.

d) Leave a little border between parts and around the edge of your texture if you're going to use mip-mapping. If you don't leave a border and you turn mip-mapping on, the colors on your textures will bleed together and you'll get visible seams or "sparkling" along the edges. For a 256 map, I usually use 240 pixels. This gives an 8-pixel border, which means it can mip-map all the way down to 16x16 before the colors start to spill all over each other. If you can't afford space for borders, try to put similar colors next to each other so if it spills it won't be so obvious.
headerko is offline   Reply With Quote
Old 23rd September 2008, 02:28 PM   #3
headerko
Junior Member
Member
 
Join Date: Jun 2008
Location: Slovakia
Posts: 20
Default Charater Creation (by Lisa) - PART II

- Finally, time to rig your model! So... question one... which animation software to use? There's lots of options there, and it's largely a matter of personal preference to be honest. I usually use a couple of different things depending on what I'm doing. Models that can be animated procedurally (i.e. with physics) such as cars or ragdolls might not use any animation software at all... they can be animated entirely by the game, assuming your engine supports it. Other models might need keyframe animation (i.e. artist created animation) for which you will need animation software.

Blender is one option, and it's free which is nice, although I've always found Blender much too difficult and slow to be practical.

As far as inexpensive software goes, I'm partial to Poser and Milkshape in that order. Poser takes a little more setup, but once rigged it's really easy and supports inverse kinematics, joint channels and a lot of other nice stuff. Poser will also let you re-use skeletons between multiple models, so if you spend some time making a really nice one it's easy to re-use not just the joints but poses and animation libraries. The new version will let you overlay timelines, too.

Milkshape on the other hand is much easier to setup--especially if you use the AC3D "Export to Milkshape with Skeleton" it will export a model that's basically ready-to-use--but Milkshape's animation tools are a bit spartan at best. There's no IK, and you can only animate one character at a time which makes it difficult for things where characters interact. Without IK, things like walk cycles will take a verrrry long time to do, so I usually only use it if I'm doing something brain-dead like a windmill. It also tends to crash a lot. But again, it's super-quick to use if you're not doing anything complicated.

As far as high-end stuff goes, I like Lightwave, but I'm weird that way. Most people seem to like Maya.

- The next step is generally to "carve up" the model in AC3D. Select all the surfaces that will be assigned to a particular joint, and then click "cut away object". You should be left with one mesh for each part: hip, hand, forearm, upper arm, collar bone, chest, etc. Don't worry about the fact that all the parts are disconnected, this will get fixed in your animation software or in your game engine.

- Give each object a unique name. Some software, like Poser, will let you use tools like the walk designer if you follow their naming convention. Also, some game engines use joint names to know which parts are "mount points". ie. The engine knows that a gun can be attached to "righthand". So, check with your animation software or game before naming your parts. Here's a chart for how Poser expects a model to be carved up: http://my.smithmicro.com/tutorials/i...97-600x900.jpg

- Assign pivot points. For Poser you can skip this step and do it later inside Poser, but for Milkshape and most game engines you'll need to assign the centers for each joint while you're still in AC3D. You can do this with "adjust object centres" on the tools menu. I also wrote a plug-in for more detailed manipulation: http://www.independentdeveloper.com/...in_pivot_tools You want to assign your pivot point so that the center of the joint is the center of rotation. ie. For the forearm, you want the joint center to be at the end near the elbow, not at the center of the forearm. The red dots in figure C in this picture show a good example of joint centers: http://www.jneuroengrehab.com/conten...0003-3-6-3.jpg You can test your joint centers in AC3D by clicking "use object center" and rotating the part with the mouse. If it swings naturally, you know you have the center in the right place.

- Build the hierachy. You can open the hierarchy view from the Tools menu in AC3D. Again, for Poser you can do this step inside Poser instead, but for practically everything else you'll need to do this now. Select each part of your mesh and group it to its parent to form a chain. i.e. group the foot with the ankle, the ankle with the thigh, the thigh with the hip and so on until your model forms a proper "tree". ie. Like so: http://backroom.renderosity.com/~rhi...rfigure/02.jpg (This image is from Poser, but it should look exactly the same in AC3D.)

- Add a "null master" (optional). A null joint is a joint with no geometry; it is a dummy joint. For characters in games, I like to a null joint on the ground at 0,0,0 and make this the root node of the model instead of the pelvis. It makes programming immensely easier. The code no longer needs to know where the hips are, the programmer moves the null around and everything else just happens. It doesn't matter how tall or short the character is, you don't need a reference pose on frame zero even if they jump, and the programmer never has to worry about where to put the character... just stick the null to the ground and you're good. It also makes a convenient mount point for mounting characters to vehicles. Easy, easy. A lot of people make the hip the root, and truthfully I find this a huge pain. It's up to you, but again, I find this trick to be a huge time-saver. If you use the Milkshape exporter, anything in AC3D that you name "NULL_(whatever)" will be treated as a null pivot. This is optional in Poser, as it automatically adds its own null master named "Body". (although Body sometimes does some odd things if you use the auto-balancing tool)

- Export! If you're going straight to your game engine, this is probably everything you need to do. Ditto for Milkshape. If you've completed these steps and export to Milkshape with Skeleton, you'll have a working rig when you import it into Milkshape, ready to animate. (Be sure to weld vertices after you import into Milkshape so it skins properly.) For Poser, there are a few more steps...

- Import. If you're using Poser, you'll need to import your model as an obj. Make sure to tell it to weld identical vertices and it will make your model back into one solid piece. From there, take it into the "setup" room. I'm not going to go into too much detail as the Poser manual has a pretty good tutorial, but in short what you need to do is either a) choose an existing character from the library to use its' skeleton (recommended!) or b) draw a skeleton using the joint tool. After you draw each bone, name it. Then click the "group" tool to assign surfaces to each bone. If you grouped your model in AC3D, those groups should already show up in poser. (You might need to rename them.) Alternatively, if you assign materials in AC3D, those will also show up in Poser and you can group by material. In the worst case, you can click the surfaces in Poser to make your groups, but I find doing that a big pain so I avoid it as much as possible. After you've assigned all your surfaces to joints, open the heirachy and make sure everything is in the right order. If you've followed Posers' naming conventions, it has some tools that will build the heirachy and set the rotation order for you. Once that's done, leave the setup room and open the joint parameters dialog. This will let you tweak your joint blends until they are smooth. Anything that's inside the green lines will be blended. Anything that's inside the red lines will be excluded. This is the most time-consuming part. Keep sliding around the little lines until it blends smoothly. Once you're done, though, you can save this joint setup you can re-use it on future characters. Also, you only have to do one side! As long as the bones exist, you can use mirror symmetry to copy the joint setup from one side of the model to the other. Anything that starts with an "l" is treated as left side, anything that starts with an "r" is right side... even if you don't follow Poser's conventions because your model is non-humanoid (like the dog) using the symmetry is really helpful.

At that point, you're good to animate! I know its a lot, but it goes pretty quick with practice. Again, try making some really simple models before you try and do anything tricky like a person. A nice earthworm or a ceiling fan.

Heh heh. This was probably more of an answer than you were expecting. Certainly longer than I intended to write, lol. Feel free to share anything useful you get out of this with others!

Later!

-Lisa
headerko is offline   Reply With Quote
Old 24th September 2008, 03:36 PM   #4
lisa
Senior Member
Professional user
 
lisa's Avatar
 
Join Date: Mar 2005
Location: Phoenix, AZ
Posts: 917
Default Re: Charater Creation - the whole process (by Lisa)

You're welcome. Anytime!
lisa is offline   Reply With Quote
Old 24th September 2008, 10:16 PM   #5
lisa
Senior Member
Professional user
 
lisa's Avatar
 
Join Date: Mar 2005
Location: Phoenix, AZ
Posts: 917
Default Determining Polygon Count

Quote:
Originally Posted by headerko
got a question, how do you determine the level of your model details?
Is there a way how to set some vertex / surface limit per object / whole scene ?
I dont want to end up modeling and then having to redo everything just because the game runs at 5fps :P
Really, the whole question of how many polys comes to just one thing: How many polygons can you see *on-screen* per frame.

There is a physical limit to how many polygons a video card can draw. Most manufacturers publish this spec, although the number published is how many triangles the card could draw if that were the only thing your computer was doing. i.e. No AI, no sound, no physics, buffers perfectly sized, etc. Real-world, you'll probably get maybe 20-50% of the published numbers, maybe less, maybe more depending on the engine. Some types of geometry are easier to throw at the video card than others--basically anything that can be made into one long strip, like terrain or particles--so you might squeeze out more if your game is heavy on that type of geometry, but it's better to be conservative when estimating. You can always add more objects/higher detail later if it turns out you have room. Side note: most manufacturers list polygons *per second* not polygons *per frame*. Divide the number of polygons per second by your target framerate to determine the number of polygons per frame.

So, as you can see, the total number of polygons you can draw never changes. It's determined by your engine and your hardware.

Therefore your polygon budget per object is determined by the max polygons you can draw per frame, divided by the number of things you want to draw. For example, if you know your engine can render about 100,000 triangles per frame and you want 50 objects, that means you can have about 2000 triangles per object. (100000 / 50 = 2000) If you want 200 objects, that number drops to 500 polys per object. If you have 10 objects, you can spend 10,000 per object.

Of course, some objects don't need as many polygons as others so you can "rob Peter to pay Paul" to balance your scene. For example, if your budget is 2000 per object you probably don't need 2000 polys to make, say, a chair. But the stone lion next to the chair might benefit from a few more, so you might reduce the budget for the chair to 1000 polys so you can increase the budget for the lion to 3000. You want to be careful doing this so you don't accidentally cluster all your polygons in one spot, but this is really the key to budgeting your objects. You can also split the budget to have more of a certain object. Instead of one 2000 poly chair, you can make four 500 poly chairs.

Importantly, the number of objects you can *see* is not the same number as the number of objects in the *scene*. For most games, you can rarely if ever see the entire scene all at one time. The number of objects visible on-screen depends on your draw distance and any culling algorithms your engine uses to reduce the number of objects that are drawn. For example, some engines can remove objects that are hidden behind other objects, aka "occlusion"; other engines use "portals" to determine if a room can be seen from another room. (Note, these culling algorithms aren't "free" so they don't reduce the cost of objects you can't see 100%, but they help tremendously.) To re-iterate, your polygon budget per object is based on what you can see, not what's in the scene... it's only the number of polygons in the viewport that is important for determining how many polys your objects should have. The polygon budget in the scene is normally based on available memory. Some games may stream or "swap" chunks in and out so they can have scenes bigger than the amount of memory, but a surprising number load the whole scene up at once. Of course, you can go the other extreme as well: for example, since Speeding Ticket is a coin-op and we wanted *zero* load times, it loads *all* the scenes at boot and keeps them in memory all the time.

The other thing to take into account is LOD, or "level-of-detail". This lets you have many more objects on the screen without blowing your polygon budget. Many games have anywhere from three to fifteen versions of each model, each at a different polygon count. As the model moves further from the player, the game engine swaps out the high-polygon version with a low-polygon version. If you do it right, the player can't tell you did it. If you do it wrong, the objects will "pop" and the player will see the change. Make sure the object is far enough away when you swap, and that the silhouettes are the same and you'll avoid popping. You can find a great tutorial on building LODs here: http://www.ai-aardvark.com/modeling/...1/aia_LOD.html A little note on the tutorial: the author of this tutorial seems to advocate building a very large number of LODs. I'd say three to five is more typical, but like everything else it's a trade-off: more LODs gives you smoother transitions, but it eats a lot more RAM so you can have fewer objects overall. If your draw distance is really long, you'll want more LODs. If your draw distance is short, you can get away with fewer LODs. We use a different number of LODs for each model depending on where it will be seen or how it will be used.

Some games use a technique called CLOD, or "continuous" LOD, to avoid popping. CLOD is basically "on the fly" polygon reduction. It's an interesting technique, and it certainly has the potential to save a lot of work building LODs. The downside, of course, is more processor load and a less control over the final product. Jonathan Blow (Braid) has an old article arguing *against* both CLOD and progressive meshes: http://number-none.com/product/Rende...ast/index.html Even this many years later, I'd still have to agree. Sometimes simplier is better.

Incidentally, since I didn't mention this already, for 98% of cards\engines polygons = triangles, and only triangles. Anything that's not a triangle gets turned into a triangle when it gets sent to the card, so combining surfaces in AC3D from triangles to other shapes won't reduce your poly count in any way. Even engines that purportedly render "curved surfaces" generally convert the output into triangles when they send it to the card--in fact, it's almost impossible to do otherwise, with the exception of some DX10 cards with "geometry shaders". (But even then most are just doing the exact same thing on the GPU instead of the CPU.) So, when you're figuring out your polygon budget, always budget in *triangles* even if you plan to build your model with quads. 1 quad = 2 tris, of course. You can triangulate your model in AC3D to get an accurate count by clicking Surface > Triangulate.

One final note: I said earlier the number of polygons your engine can draw never changes. That's not entirely true. Some kinds of polygons draw faster than others. In general, unlit polygons draw much faster than lit polygons; opaque polygons draw faster than translucent polygons; and untextured polygons draw faster than textured polygons. If you're using shaders, some shaders are faster than others. Finally, the size of your textures can make a dramatic difference... textures can do more to effect rendering speed than geometry in many cases! A common mistake is to make something like a ladder out of a transparent texture on a quad to "save polys". Unless it's a ladder to the moon, a ladder doesn't have that many polygons and the alpha-mapped texture will cost you a lot more than a few triangles. For many engines, large alpha-mapped, heavily-textured objects tend to be the most expensive thing you can draw. Try to budget your texture memory as well as your polygons when planning your scene; the fewer things you have to swap in and out of texture memory, the faster your game will run.
lisa is offline   Reply With Quote
Reply

Tags
animation, character, joint, rigging

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off



All times are GMT -4. The time now is 05:20 PM.


AC3D Forum
(C) Inivis Limited 2020