Jump to content
  • Advertisement
Sign in to follow this  
Norman Barrows

implementing animated interchangeable clothing - best methods?

This topic is 1216 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

implementing animated interchangeable clothing - best methods?

 

the game in question: caveman 3.0 fpsrpg, paleolithic setting.

 

game engine used: custom, built on dx9.

 

so i recently switched to skinned meshes for the player and NPCs. originally i used rigid body models for speed.

 

i've implemented interchangeable equipment using static meshes and models (weapons, hats, shields, etc).

 

now its time to implement interchangeable skinned mesh equipment such as torso armor and cloaks, which move with the character.

 

Two approaches come to mind:

 

1.  create the clothing and rig it to its own copy of the character's skeleton. if the clothing should be drawn, set the clothing's animation controller to the same time value as the character's animation controller, and draw at the same location as the character. draw the clothing first so underlying triangles of the skinned mesh are trivially rejected by zbuf test and never rasterized.

 

2. add the clothing as another mesh in the character's model.  male models currently consist of a single body mesh and a loincloth mesh, both rigged to the same skeleton. females add a bra mesh. the game engine code only added a single variable to the d3dmeshcontainer_derived structure found in the DX sample code, an integer for texture ID. this allows interchangeable pooled textures on a per mesh basis. a reserved value such as texture ID = -1 could be used to indicate "don't draw this mesh". the code sets the textures IDs, updates the combined transforms, then draws the mesh. when setting textures, -1 could be used to "turn off" drawing of clothing not equipped. a separate boolean "shoud_draw" added to d3dxmeshcontainer_derived would be the same idea.  since the underlying MS skinned mesh code uses drawsubset, manipulation of subset IDs in the modeling software would probably be required to guarantee and drawn clothing is rendered first, so underlying skin is not drawn.  note that splitting the mesh into sections is not really an option as seams will not always be hidden by clothing, and shading artifacts across visible seams can be an issue.

 

any other suggestions?

 

since its a custom engine, i can do anything i want. but i'm trying to use off the shelf components to the maximum amount possible, thus the use of dx9 skinned mesh APIs.

 

at first glance, method 2 might be the better way to go. clothing and skin can share the same skeleton. turning off textures is as easy as not drawing a separate skinned mesh - if not easier.   And from watching blender tutorials, i discovered you can rig clothing with empty weight sets, then copy the weights from the skin to the clothing - resulting in a quick perfect match. nice if you've tweaked weights after applying automatic weights - and probably more accurate than rigging and adjusting a piece of clothing to a separate copy of the skeleton.

Edited by Norman Barrows

Share this post


Link to post
Share on other sites
Advertisement

1.  create the clothing and rig it to its own copy of the character's skeleton. if the clothing should be drawn, set the clothing's animation controller to the same time value as the character's animation controller, and draw at the same location as the character. draw the clothing first so underlying triangles of the skinned mesh are trivially rejected by zbuf test and never rasterized.


Can't you just copy skin matrices from one mesh instance to another or use the same animation controller for both?

As for method 2, I suspect you'll need many combinations of meshes that way, meshes will be duplicated and they will become hard to manage.

 

IMO, art pipeline is the most important thing you should consider, not whether unseen pixels will be discarded early (as that can be hacked in at any time).

Share this post


Link to post
Share on other sites

Can't you just copy skin matrices from one mesh instance to another

 

in the DX9 code, a skeleton, its meshes, and their texture names/IDs, material names/ID, and skin weights, and all animations are are all stored together in a single file on disk.

in memory, the controller stores all the animations, and the skinned mesh data structure stores everything else, as well as the combined transform mats for the bones.

 

the main thing folks don't seem to like about the dx9 animated skinned mesh APIs is that its designed to store the skeleton, meshes, texture names, material names, skin weights, and all animations in a single file. this means to load a mesh with weights you also need a controller and a skeleton at the very least. to load an animation you need a controller, a skeleton, a mesh, and weights.

 
yes, it would be possible to copy all the combined transform mats from one skinned mesh to another, then draw the second mesh, and it would match up with the first.

but you'd still need a controller and skeleton for the second mesh - even if you never use them. and the second mesh would be a separate .x file

 

 


 or use the same animation controller for both?

 
the API seems to work this way:

one animation controller can be shared with multiple instances of the same skeleton/mesh, but they all animate the same.

two animation controllers are required to animate two different skeletons, even with the same animation, in sync.

so it would seem the answer is no, the dx9 code is not setup out of the box to share animation controllers between different skeletons. however there may be a way to do so with the lower level API calls.

 

 

so it doesn't seem to be designed to let you say "use this skinned mesh and weights with that transformed skeleton", or "use this controller with skeletons A and B".

 

it seems to be designed to let you say "use this controller with its current animation, its skeleton, and the skeleton's meshes, and their textures, materials, and skin weights with this world transform.".  and that's basically it.

 

i've managed to add support for use of a single pooled material for the model and interchangeable pooled textures for each mesh in the model by modding just a couple lines of code.  but that's the limit to which i've extended the capabilities so far.

 

for now, skeletons, meshes, weights, and animations are shared via copy/paste in blender.

 

so no sharing skeletons between multiple meshes in the game, i do that in blender instead.   and no sharing controllers between multiple skeletons. for that you'd probably use two sync'd controllers  (a la method 1 in the original post). 

 

but in the code to draw a mesh, its easy to check for a "should draw" flag of some type. allowing you to easily toggle clothing on/off. you set the flag when you set the textures before drawing. then you can create your clothing in the character mesh's blend file, and export it with the character into the same .x file, and then just draw it or not as needed.

 

 

 

 


As for method 2, I suspect you'll need many combinations of meshes that way, meshes will be duplicated and they will become hard to manage.

 

usually multi-part meshes or overdraw are use to avoid having to make a model of each possible clothing combo.  since multi-part meshes can show seams where clothing doesn't hide them, the game doesn't use multi-part meshes, in order to avoid seam artifacts. so for example, instead of interchangeable heads, there's a complete head and body model for each head and sex. so the game uses overdraw to draw clothing. the complete head/body mesh is drawn, as well as the optional clothing, and zbuf does the rest.

 

 

 

the number of meshes created doesn't change. just how many copies of what you load/have in memory.   since dx9 doesn't share much out of the box, i end up loading 5 copies each of two different skeletons (male and female) for 10 skinned mesh characters with different general facial features (5 each male and female). materials and textures are shared, but a master animation controller is required for each of the 10 skinned meshes, as well as a cloned controller for each instance of a character in the game, and EACH controller (mater AND clone) stores a copy of ALL the animations for its skeleton! and all the male animations are the same, and all the female animations are the same. and some of the male and female animations are the same. so i have like 10 copies of every animation in memory + 1 one additional copy for each active character! due to dx9 not sharing animations out of the box. 

 

 

with method 1 i have a skeleton for each piece of clothing as well as one for each character model. and a master controller for each piece of clothing, and a cloned controller for each instance of clothing in the game, as well as a master for each character model and clones for each model instance - and ALL those controllers EACH have a copy of ALL the character's animations. As for artwork, clothing would be made in the character's blend file, then the skeleton, clothing, weights, and animations would be saved as a separate file. 

 

with method 2, the clothing is just another mesh in the character's skinned mesh. only difference is drawing it can be turned on and off.   it shares/uses the same skeleton, master controller, cloned controllers, and animations. no redundant data, no controller sync'ing required.  As for artwork, clothing would be made in the 1st character's blend file, then copied to the remaining four models of the same sex, the same way the non-optional animated clothing (bra and loincloth) was when originally creating the character models. the main downside to this is that changes must be copied to all similar models. example: right now i need to clean up the scaling and UV map of the male loincloth. so i'll do it in guy1.blend, but then i'll have to copy the modified loincloth mesh to guys 2 through 5 .blend. a separate animated skinned mesh loincloth model would preclude the need for the copy, at the cost of an extra skeleton, an extra master controller, extra cloned controllers, and all those redundant copies of all the animations.

 

 

 

 

is there another method that's even slicker?   preferably without re-engineering the whole dx9 skinned mesh API like most folks do? <g>

Edited by Norman Barrows

Share this post


Link to post
Share on other sites


but you'd still need a controller and skeleton for the second mesh - even if you never use them

A skeleton is probably loaded with other mesh data, not much to do about that (unless you really want to make a custom mesh format).

 

But I don't see the point of needing a controller. All you need to animate a skinned mesh is an array of matrices that you pass to the shader (unless you use that weird mesh splitting for reduced constant usage, which should be unnecessary these days).

 


two animation controllers are required to animate two different skeletons

Obviously I'm assuming that the same skeleton (exact copy of it) is used. Copy can be verified at load time, throw an error in case of a mismatch. Seems easier than copying all animations to all characters all the time.

 


and EACH controller (mater AND clone) stores a copy of ALL the animations for its skeleton!

I don't see a reason for this. It seems to me that animations sets are separate from controllers.

Share this post


Link to post
Share on other sites


A skeleton is probably loaded with other mesh data, not much to do about that (unless you really want to make a custom mesh format).

 

doing it the dx9 way, a skeleton, its meshes, their weights, their texture names, their material names, and ALL the skeleton's animations are loaded from a single file.

the animations go in a controller, and everything else goes in a skinnedMesh data structure.

 


But I don't see the point of needing a controller.

 

a design constraint of the dx9 animation controller API.   the controller generates the bone transform matrices, given its current animation, and a delta time.   so to draw, you tell the controller to set the bone matrices, then concatenate the world mat onto those bone matrices, then draw using one of the supported skinning methods.

 


Obviously I'm assuming that the same skeleton (exact copy of it) is used. Copy can be verified at load time, throw an error in case of a mismatch. Seems easier than copying all animations to all characters all the time.

 

again, a limitation of the dx9 API - unless you want to get into low level copying around of data (assuming its possible) there's no sharing skeletons. i have 5 female models each with different face meshes. they all use the same skeleton and animations. i load 5 copies of the skeleton and 5 copies of the animations. skeletons are shared via copy/paste in blender. animations are shared by exporting models and animations to separate .x files, then using a batch file to copy+ concatenate everything together in the correct order.

 

implementing asset sharing with the dx9 API would probably go something like this:

1. load everything the dx9 way.

2. create a bunch of empty data structures (asset data pools) to hold everything - a list of skeletons, a list of meshes, a list of animations, etc. and some kind of "entity system" to say which models use which skeletons, animations etc.

3. copy all the loaded data to your asset memory pools

4. release all the loaded data

5. whenever you want to draw something, copy all the various bits (skeleton, meshes, animation etc) into the appropriate dx9 data structures (a controller and a skinned mesh), then draw as usual.

 


I don't see a reason for this. It seems to me that animations sets are separate from controllers.

 

nor do i, nor does anyone else apparently. animation sets are separate from controllers, but in the dx9 API, they are data owned by a controller for a specific mesh - with no apparent way to share animation sets between controllers except by copying data "behind the APIs back" so to speak.

Share this post


Link to post
Share on other sites

There is the easy way and there is the hard way.

 

The hard way is to do a "cloth simulation" where the clothing wraps around the character mesh, this is somewhat intesive compute work.

 

The easy way is to swap out a body mesh with a bit more bulky clothing mesh, each clothing has its own mesh that you draw instead of a body part. Add a handful of bones sticking radially out from the root bone (like an umbrella) which you can wave around somewhat. Saggy clothing vertices are then weighted to those bones.

Share this post


Link to post
Share on other sites

The hard way is to do a "cloth simulation" where the clothing wraps around the character mesh, this is somewhat intesive compute work.

 

yes, i've seen the physics cloth based methods, with the collision objects on the shoulders so it hangs down when you apply the cloth simulation, both for creating a realistic mesh which is then rigged to the skeleton, and for "rigging" the clothes themselves.

 

 

 


The easy way is to swap out a body mesh with a bit more bulky clothing mesh, each clothing has its own mesh that you draw instead of a body part.

 

yes, multi mesh. this is the conventional route. head, upper body, lower body, feet, hands as different groups (for example).  but there can be issues with seams being visible when they are not hidden by clothing.  in caveman, the basic dress is loincloth, or bra and loincloth.  i haven't found a solution to the problem of uneven shading across neck seams which are not hidden by clothing. so i've been forced to use a single full head and body mesh for each face. fortunately there are only 10 face meshes (for now).  i simply draw the bra and loincloth meshes over the head and body mesh. all three meshes are rigged to a single skeleton as a single skinned mesh.  i've been able to get away with static meshes or models rigged to a single bone for drawing eyes, hair, hats, helms, weapons, shields, leggins, boots, mittens, sacks, and waterskins. but tops (torso armor/jackets/vests), and cloaks (big furry Eskimo stuff) need to be animated.  to do them multi mesh, i'd need to split each of the 10 models into head, arms, top, and "everything from the waist down" to do tops. and head, cloak, hands, and feet to do cloaks. and i'd still need my 10 original models for the "no cloak or top" cases. i was hoping to avoid that by using overdraw and zbuf (sort of realtime CSG modeling using the zbuf - like coding POVARY v1.0).

 

 

 

 


Add a handful of bones sticking radially out from the root bone (like an umbrella) which you can wave around somewhat. Saggy clothing vertices are then weighted to those bones.

 

yes, i saw this technique too. bones for the cloth, quite clever. they used it on the skirt of a robe and linked them to the thigh bones as i recall. lots of drivers and fk and ik stuff.

funny thing was, i'd already gotten that part of the cloak working with a standard automatic weights rigging. all i had to do was split the front and back so the two lower halves could follow the legs during a very long stride sprint animation. a little massaging in weight paint, and it was done. 

 

overdrawing the arms of the cloak was giving me fits. the one hand (overhand) attack animation kept poking through at the shoulder, no matter what i did. in the end i removed the sleeves. then i found the solution:

 

rigging clothes is HARD!

http://blenderartists.org/forum/showthread.php?205295-rigging-clothes-is-hard!&s=8c0ac0179db7979e34c4195d8ddebaeb

 

the solution is reply number 7. if a picture is worth 1000 word, and a video is worth a million, then a working example file has got to be worth a least a couple jillion - and that's just what the guy posted in reply #7:

http://blenderartists.org/forum/attachment.php?attachmentid=124614&d=1293612493

 

the problem was insufficient subdivision of faces around the joint so the clothing would follow the arm nicely.

 

with this, i ought to be able to put sleeves back on the cloak if desired. the previous version of the game didn't really have sleeves on the cloaks. i plan to solder ahead with no sleeves for now. but i should now be able to add cloth simulated cloaks with sleeves and overdraw whenever desired.

 

i'm not sure how "multi-mesh friendly" the dx9 skinned mesh and controller APIs are. one way would be to have a skeleton and all your meshes (multiple hats, heads, tops, arms, hands, legs, feet) in a single skinned mesh with all the animations for the skeleton, then use a method similar to the one i described to flag the proper combo of meshes for drawing. as long as clothing hides the seams or any visible seam artifacts are considered acceptable, you're good to go.

 

the other way is one skeleton for each mesh (or set of meshes). i don't really see an advantage to that. redundant skeletons and controllers for - nothing - doesn't seem to get you anything.

 

so i guess all the multi-part meshes and a single skeleton in one file would be the way to go.

 

adding a "should_be_rendered" booelan to the D3DXFRAME_DERRIVED struct declaration is trivial. as is adding the line of code to DrawMeshContainer to check the boolean before setting texture and material and calling mesh->DrawSubset. so just a couple lines of code will mod the dx9 sample code to support multi-part skinned meshes. but then you have to write the code to set the booleans before drawing. since its all interchangeable multi-part meshes, any critters that share the same skeleton and animations can be implemented as a single multi-mesh model. so you'd probably have a single model for all human females and one for all males, unless you get into modeling body height and size. that might require additional skeletons. and yes, my focus groups are already asking for it. <g>. they want to play as themselves in the caveman world, right down to "my body build affects my hit points, strength, speed, and agility".

 

at this point, i've gotten overdraw working with both "copy the skin and scale it up" type clothing and "make model from scratch" type clothing (albeit with no sleeves for the moment) for the female models. since the top and cloak are the only things that need to be animated and rigged to multiple bones, and since i'm so close (copy to remaining 4 females, export females, copy to first male, edit to fit, rig, copy to remaining 4 males, export males, run batch file to append animations, mod the code, build, backup, run),  i think i'll stick with overdraw for the moment.  

 

going off on a tangent here...

i want to get these skinned meshes done quickly. action animations still need to be done, and then there's skinned mesh versions of all 50 or so animals in the game, but even more important are the gameplay issues of an open world, and the choice of setting for a game - a design question.  in a nutshell: the choice of setting limits what there is to do in a game world: is there magic? gunpowder? lightsabers, blaster, and lasers? civilization? fantasy monsters? zombies? modern tech? scifi tech? interstellar travel? vampires? werewolves? can you play as one? the choice of setting defines what can/should/does and does not exist in a game universe. i'm concerned that a paleolithic setting might be somewhat restrictive when it comes to high level play, which no amount of skinned meshes is ever going to fix.  take skyrim for example. love the game. Oblivion influenced the design of the unreleased caveman v2.0 which was similar to caveman 3.0 but not as advanced. i probably have over 1000 hours in playtesting and evaluation time in on skyrim by now.  but once you get past character development, quests, and dungeon, wilderness, and town adventuring (the staples of any RPG) the only objective in the game seems to be to buy all the houses and horses....?  (talking vanilla here- no mods).  this seems to turn it into a huge open world shooter with a leveling system, medieval fantasy setting, and optional quests, not a computerized version of classic tabletop dungeons and dragons where at high level you could build a castle, raise an army, and conquer the map. in researching this, i've come across the term "a mile wide and an inch deep" numerous times to describe skyrim. since i had to play through all the campaigns to evaluate the game as part of my gamedev work (know thy enemy, keep up with the jones,  all that jazz), and they're all hard coded, same every play through, i've looked for mods so i can actually play it for fun, since i sort of "used it up" as part of my job. but this lack of stuff to do at high level in skyrim hasn't been addressed too much by mods other than "more of the same" type mods (more quests, npcs, houses/castles to buy). only a few let you raise and equip an army - which is the key thing - something to spend your gold on. any idea how much 100 sets of banded iron armor costs? time to go advetureing and get some loot.  this is the fundamental flaw in bethesda's  interpretation of dungeon and dragons - they left out the high level part of the game. of course its totally understandable. the original scope of the game was D&D style arena combat. thus the original name. but arena experienced massive feature creep during development, adding dungeon, wilderness, and town adventure (apparently - i never played it). but they didn't implement the second have of volume 3 of 3 of the original d&d rule books - omitting basically 1/6th of the rules of the game - those pertaining to high level play. in my case, the paleolithic setting of caveman 3.0 sort of rules out the possibility to build a castle raise an army and conquer the world - caveman style.  basically i'm concerned that there just might not be a whole lot of interesting things to do at high level in a RPG with a paleolithic setting. but this is really a question for a different forum.

Edited by Norman Barrows

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!