Putting clothes and armor on characters.
by Sanctus Legacy Online Admin · in Artist Corner · 02/10/2005 (7:56 pm) · 42 replies
Okay- as our team has been working on our project, we're starting to understand why other teams put up a new snapshot every time they get a model in game. It's darned near impossible. Between horrible exporting issues, few to no mainstream tools that support Torque's file formats... *rant, rant*
Anyway, we finally have a character model textured, rigged (mount nodes, level of detail), and animated, and in game. We have tested mount nodes by attaching a weapon to the character's animated arm, and all seems to be well. Thing is, there's a big jump between having a single weapon attached to a single node and what we want.
Before we press on, we really just need to hear from somebody who's done it before- get some advice, talk to some people who know what they're doing.
Our players will have their base model (the "naked" body), and then interchangeable clothing / armor, and we need to know what the best method of implementing this is. Assume, for our purposes, that the player will be able to customize their base model's texture, to allow for variations in skin color and things like tattoos, chest hair, scars- whatever.
Originally, we had envisioned just having everything mounted as seperate models over the body. The shirt would be a seperate model, mounted to the hip, chest, shoulders, elbows, and wrists. The pants would be a seperate model, mounted to the hip, knees, and ankles. Shoes would be seperate models mounted to the ankles and toes. You get the picture. Certain pieces would be layered: chestplates would be larger than shirts, and would also be mounted to the hip, chest, and shoulders, and would lay over the shirt.
If this method works, I would be enthralled. In theory, we could have some hidden-faces culling methods implemented to help out with the framerate, and as long as we have a clearly defined limit for how "thick" shirts can be and how "loose" armor has to be, we would be alright, ne? Again- we don't know, and we haven't tried. We're asking for your advice.
Another option that's popped up is having only a few certain things be mounted: armor, gloves, shoes, and headgear. Things like shirts and pants would be painted on to the body. Question is- is this feasible? We don't want to actually change the body's texture altogether- we still need the player's skin texture for parts that aren't covered by the shirt/pants/whatever. Is it possible to use multitexturing to paint the shirt over the skin texture? If so, what is the FPS damage done?
If this method works, I would not be extremely disappointed, although I think that having "baggy" clothing adds a good deal of style and quality to characters. Of course, we could always have parts of the clothing mounted- like fluffy sleeves or loose collars. The advantage to this method is that we don't have any sort of limitation on how "tight" armor can be.
The last option we considered was simply condensing the shirt, chest armor, and pants into one thing- a "suit" or an "outfit". If this is the case, then we can just have interchangeable bodies altogether, and have parts of the body that are not covered by clothing/armor be UVmapped to the player's skin texture, and the rest UVmapped to the clothing/armor texture sheet. This does allow for both customizable skin tone/design and customizable clothing/armor. We could also add in mounted accessories, as well as gloves, shoes, and headgear.
If this method works, we'd probably save it as a last resort, though. I mean, condensing equipment down that much seems like you're killing the idea of personalization altogether, and we wouldn't want that.
Anyway- your input on each of these ideas, as well as any ideas you may have or methods you have used in the past would be appreciated. We have modelers ready to work on this, as soon as we figure out the process. Thank you very much for the help.
Anyway, we finally have a character model textured, rigged (mount nodes, level of detail), and animated, and in game. We have tested mount nodes by attaching a weapon to the character's animated arm, and all seems to be well. Thing is, there's a big jump between having a single weapon attached to a single node and what we want.
Before we press on, we really just need to hear from somebody who's done it before- get some advice, talk to some people who know what they're doing.
Our players will have their base model (the "naked" body), and then interchangeable clothing / armor, and we need to know what the best method of implementing this is. Assume, for our purposes, that the player will be able to customize their base model's texture, to allow for variations in skin color and things like tattoos, chest hair, scars- whatever.
Originally, we had envisioned just having everything mounted as seperate models over the body. The shirt would be a seperate model, mounted to the hip, chest, shoulders, elbows, and wrists. The pants would be a seperate model, mounted to the hip, knees, and ankles. Shoes would be seperate models mounted to the ankles and toes. You get the picture. Certain pieces would be layered: chestplates would be larger than shirts, and would also be mounted to the hip, chest, and shoulders, and would lay over the shirt.
If this method works, I would be enthralled. In theory, we could have some hidden-faces culling methods implemented to help out with the framerate, and as long as we have a clearly defined limit for how "thick" shirts can be and how "loose" armor has to be, we would be alright, ne? Again- we don't know, and we haven't tried. We're asking for your advice.
Another option that's popped up is having only a few certain things be mounted: armor, gloves, shoes, and headgear. Things like shirts and pants would be painted on to the body. Question is- is this feasible? We don't want to actually change the body's texture altogether- we still need the player's skin texture for parts that aren't covered by the shirt/pants/whatever. Is it possible to use multitexturing to paint the shirt over the skin texture? If so, what is the FPS damage done?
If this method works, I would not be extremely disappointed, although I think that having "baggy" clothing adds a good deal of style and quality to characters. Of course, we could always have parts of the clothing mounted- like fluffy sleeves or loose collars. The advantage to this method is that we don't have any sort of limitation on how "tight" armor can be.
The last option we considered was simply condensing the shirt, chest armor, and pants into one thing- a "suit" or an "outfit". If this is the case, then we can just have interchangeable bodies altogether, and have parts of the body that are not covered by clothing/armor be UVmapped to the player's skin texture, and the rest UVmapped to the clothing/armor texture sheet. This does allow for both customizable skin tone/design and customizable clothing/armor. We could also add in mounted accessories, as well as gloves, shoes, and headgear.
If this method works, we'd probably save it as a last resort, though. I mean, condensing equipment down that much seems like you're killing the idea of personalization altogether, and we wouldn't want that.
Anyway- your input on each of these ideas, as well as any ideas you may have or methods you have used in the past would be appreciated. We have modelers ready to work on this, as soon as we figure out the process. Thank you very much for the help.
About the author
#2
Edit: I would think about maybe editing the last post though. It may be a little too personal.
02/10/2005 (8:20 pm)
I emailed him recently and haven't heard anything back either. Maybe he's just taking a break for TorqueEdit: I would think about maybe editing the last post though. It may be a little too personal.
#3
I have thought about this issue before though, and talked with professionals about how they did it. And I have modeled, rigged, and animated a lot of characters, so I have some experience with the process. In my opinion, if you try to use any "mount"-ing methods, you will be cursing the decision for ever more.
With all the different armor, clothing and accesories you will have (from what it sounds like) it is impossible that your meshes will line up efficiently (that probably sounds very cryptic... I'm going to try to explain). I understand that you plan on culling out the hidden faces, which is a good idea that I hadn't thought of before, but probably harder to impliment than you think. You would have to make a separate "case" for every combination of character model and accessory, and calculate which faces would be hidden, and if you have multiple layers like you are saying, it becomes even more complicated.
Also, when it comes to rigging, your modelers or animators or whoever is doing it will tear their hair out. Trying to rig a mesh or meshes with mutiple layers is difficult if not impossible to do without ugly penetration. Well, thinking about it just now I guess that only applies to areas like the chest(spine) and shoulders.... If you had a 'bracer' model mounted to a forearm it might work well since it doesn't need to flex.....
In my opinion your best option is to do your models similarly to the Q3A models, which used separate pieces for head, body, and legs. For your game you could break it down further and do the arms separate, or maybe even break all the limbs into upper and lower sections. This way you can model a torso with armor on, with a shirt on, and with nothing on, and interchange them depending on the player's choices. You can also combine this with interchangeable textures for the same models, and get even more options. With faces, too, you can have almost unlimited variations on the same character just by changing out the head model.
As far as I know, Torque out-of-the-box doesn't support mutiple textures on the same model, so you would either have to impliment that yourself or just have your texture artists do the skin and clothing on separate layers, and make several different versions or each texture, with different skin color or whatever, according to your needs.
Another issue you will have with this is that you will want different body types, with different proportions... I'm not sure what the correct solution is, but probably you can dynamically scale the models according to the specific skeleton of the character.
As for the tattoos... you could either do them in the textures on separate layers (but now we're talking serious amounts of textures to keep track of...) or you could possibly use decals. But I don't know much about that. I think decals are traditionally used only for environmental models... not sure if this is true or why.
Well, I hope I helped. I could tell by your post that you're smart and obviously putting a lot of thought and effort in to this project, and as someone who has been in the same place before and knows what it feels like... I really just hope I helped.
Peace
Jeff
02/11/2005 (10:29 pm)
First, a disclaimer: I'm not an expert. Never shipped a game.I have thought about this issue before though, and talked with professionals about how they did it. And I have modeled, rigged, and animated a lot of characters, so I have some experience with the process. In my opinion, if you try to use any "mount"-ing methods, you will be cursing the decision for ever more.
With all the different armor, clothing and accesories you will have (from what it sounds like) it is impossible that your meshes will line up efficiently (that probably sounds very cryptic... I'm going to try to explain). I understand that you plan on culling out the hidden faces, which is a good idea that I hadn't thought of before, but probably harder to impliment than you think. You would have to make a separate "case" for every combination of character model and accessory, and calculate which faces would be hidden, and if you have multiple layers like you are saying, it becomes even more complicated.
Also, when it comes to rigging, your modelers or animators or whoever is doing it will tear their hair out. Trying to rig a mesh or meshes with mutiple layers is difficult if not impossible to do without ugly penetration. Well, thinking about it just now I guess that only applies to areas like the chest(spine) and shoulders.... If you had a 'bracer' model mounted to a forearm it might work well since it doesn't need to flex.....
In my opinion your best option is to do your models similarly to the Q3A models, which used separate pieces for head, body, and legs. For your game you could break it down further and do the arms separate, or maybe even break all the limbs into upper and lower sections. This way you can model a torso with armor on, with a shirt on, and with nothing on, and interchange them depending on the player's choices. You can also combine this with interchangeable textures for the same models, and get even more options. With faces, too, you can have almost unlimited variations on the same character just by changing out the head model.
As far as I know, Torque out-of-the-box doesn't support mutiple textures on the same model, so you would either have to impliment that yourself or just have your texture artists do the skin and clothing on separate layers, and make several different versions or each texture, with different skin color or whatever, according to your needs.
Another issue you will have with this is that you will want different body types, with different proportions... I'm not sure what the correct solution is, but probably you can dynamically scale the models according to the specific skeleton of the character.
As for the tattoos... you could either do them in the textures on separate layers (but now we're talking serious amounts of textures to keep track of...) or you could possibly use decals. But I don't know much about that. I think decals are traditionally used only for environmental models... not sure if this is true or why.
Well, I hope I helped. I could tell by your post that you're smart and obviously putting a lot of thought and effort in to this project, and as someone who has been in the same place before and knows what it feels like... I really just hope I helped.
Peace
Jeff
#4
Faces: Yup- our faces are, indeed, seperate models, giving us the benefit of heavy customizability.
Body Types: Yes- this is another issue we're waiting to test. We are hoping to have a handful of bones in key areas (arms, stomach, chest, legs) to allow the user to shape those areas of the body. Again- only our hope. We still need to test it, which requires our Torque-savvy coders to get online before 2am, or us to get a hold of Gonzo. ;)
So, yeah. Most of what we're talking about is dependent upon us using multitexturing in Torque. Definitely not hard to implement by any means- if I can implement it, anyone can. It's mostly a question of framerate sacrifice vs. quality.
Anyway- thank you very much for your advice. ^____^
02/12/2005 (9:41 am)
Ah, yes- interchangeable body "parts". We actually did consider that one, but we really found very few advantages to that as opposed to the second method I detailed: which is used by Everquest 2 and WoW.Faces: Yup- our faces are, indeed, seperate models, giving us the benefit of heavy customizability.
Body Types: Yes- this is another issue we're waiting to test. We are hoping to have a handful of bones in key areas (arms, stomach, chest, legs) to allow the user to shape those areas of the body. Again- only our hope. We still need to test it, which requires our Torque-savvy coders to get online before 2am, or us to get a hold of Gonzo. ;)
So, yeah. Most of what we're talking about is dependent upon us using multitexturing in Torque. Definitely not hard to implement by any means- if I can implement it, anyone can. It's mostly a question of framerate sacrifice vs. quality.
Anyway- thank you very much for your advice. ^____^
#5
I've thought about this myself, but the question is why you think there would be so few advantages to that method?
I could be way off base here, but my thinking has always been "why should I allow a shape that isn't being seen to even occupy memory space?"
It just seems like unecessary additional overhead to me to "stack" meshes on top of one another.
Then there's the issue of aesthetics. Being an artist first and a programmer second, I tend to get nitpicky over this stuff (admitedly), but there always seems to be something just, well... off when I look at a character who has a coat (for example) layed over the top of the body mesh as opposed to being modelled that way.
Personally, I think this "mesh-swap" method would offer numerous advantages (though I have no empirical data to back this up.)
For one, there's no overhead asociated with the additional memory storage, or having to run a culling routine for non-rendered faces (however negligable that might be??)
Also, you'd essentially have to break the textures up into smaller peices, allowing for smaller textures with a higher level of detail (because there's not as much space smashed into them) which also allow you to swap them out in memory a bit quicker when changing wearables.
In the end, I could be waaaay off base (and it wouldn't be the first time), but my thinking is that mesh stacking is done because it is easier than recreating whole meshes for clothed body parts, not necessarily because it's more advantageous.
Am I crazy or what? Seriously... it's something I've always been curious about. =)
02/12/2005 (9:54 am)
Quote:Ah, yes- interchangeable body "parts". We actually did consider that one, but we really found very few advantages to that as opposed to the second method I detailed: which is used by Everquest 2 and WoW.
I've thought about this myself, but the question is why you think there would be so few advantages to that method?
I could be way off base here, but my thinking has always been "why should I allow a shape that isn't being seen to even occupy memory space?"
It just seems like unecessary additional overhead to me to "stack" meshes on top of one another.
Then there's the issue of aesthetics. Being an artist first and a programmer second, I tend to get nitpicky over this stuff (admitedly), but there always seems to be something just, well... off when I look at a character who has a coat (for example) layed over the top of the body mesh as opposed to being modelled that way.
Personally, I think this "mesh-swap" method would offer numerous advantages (though I have no empirical data to back this up.)
For one, there's no overhead asociated with the additional memory storage, or having to run a culling routine for non-rendered faces (however negligable that might be??)
Also, you'd essentially have to break the textures up into smaller peices, allowing for smaller textures with a higher level of detail (because there's not as much space smashed into them) which also allow you to swap them out in memory a bit quicker when changing wearables.
In the end, I could be waaaay off base (and it wouldn't be the first time), but my thinking is that mesh stacking is done because it is easier than recreating whole meshes for clothed body parts, not necessarily because it's more advantageous.
Am I crazy or what? Seriously... it's something I've always been curious about. =)
#6
You swap out the colors on the actual textures to create a different looks, Asheron call uses the method. Of course depending on what the item is there may be a bit of mesh altering involve but still its another technique to look into.
02/12/2005 (11:15 am)
What about palette swapping. I read in a MMORPG development book about the technique. You swap out the colors on the actual textures to create a different looks, Asheron call uses the method. Of course depending on what the item is there may be a bit of mesh altering involve but still its another technique to look into.
#7
02/12/2005 (5:54 pm)
@Johnny: Of course. Palette swapping is very easy to do, and an excellent way to allow for additional customization.
#8
02/12/2005 (9:10 pm)
Quote:multitexturing in TorqueTorque has the ability to do animated textures -- can't you just "play" a single frame from that animation?
#9
> can't you just "play" a single frame from that animation?
I think the term "multitexturing" was refering to layered textures rather than changing textures. For example, suppose you have 5 different skin types (caucasian, asian, reptilian, furry, amphibian) and 5 different skin features (pimple, wart, scar, wound, tatoo). With layered texturing, you could have a total of 10 textures, overlaying the features over the types (the feature textures would be mostly transparent). Without layered texturing, you would have to create 25 different textures to represent the various combinations. In addition to the extra work of creating these textures, programming becomes more work because you need to figure out which combo texture to use for each type/feature combination. Sanctus wants to combine a large variety of textures together to allow his players to customize their characters, so the ability to layer textures would be very helpful.
02/12/2005 (9:36 pm)
> multitexturing> can't you just "play" a single frame from that animation?
I think the term "multitexturing" was refering to layered textures rather than changing textures. For example, suppose you have 5 different skin types (caucasian, asian, reptilian, furry, amphibian) and 5 different skin features (pimple, wart, scar, wound, tatoo). With layered texturing, you could have a total of 10 textures, overlaying the features over the types (the feature textures would be mostly transparent). Without layered texturing, you would have to create 25 different textures to represent the various combinations. In addition to the extra work of creating these textures, programming becomes more work because you need to figure out which combo texture to use for each type/feature combination. Sanctus wants to combine a large variety of textures together to allow his players to customize their characters, so the ability to layer textures would be very helpful.
#10
Skin
Tattoos/Scars/Hair/Freckles
Clothing/Equipment
Additionally, the setup we're testing is a blend between the swappable parts and the second method I listed before.
The method is detailed on our forums, but for convenience, here's an excerpt from Paul Fassett, the character modeler who has been most involved with the decision:
(Continued...)
02/13/2005 (11:58 am)
@Eric: exactly. And after working it out with our coders last night, we did determine that we will, indeed, be utilizing multitexturing layers to allow for at least the following layers:Skin
Tattoos/Scars/Hair/Freckles
Clothing/Equipment
Additionally, the setup we're testing is a blend between the swappable parts and the second method I listed before.
The method is detailed on our forums, but for convenience, here's an excerpt from Paul Fassett, the character modeler who has been most involved with the decision:
Quote:
Ok, I felt that I needed to make a thread clarifying the procedures, and the things that need to be done in order to get a working armor and clothing system to work. So this thread is going to be dedicated to outlining the procedures we will be using to make our armor and clothing as good as possible. I will be updating this today with pictures diagrams and procedures as they come.
Can someone sticky this?
Diagram 1.1
Notice on diagram 1.1 that the body is sectioned by a major bend point or joint. This is because in each of these bend points a mount must be placed for armor mounting functionality. I illustrate this point in the diagrams below. When attaching nodes they must be placed in the center of the arm so that the mounted image or armor will rotate correctly when the bone moves. Or else the rotations will be offset and it will look like an invisible arm is moving the bracer.
Diagram 1.2
Each black box represents a mount point. I have numbered them and I will go into detail as to the function of each one by the numbers.
1. ShoulderMount: This mount is for shoulder pads. We put the mount point on the shoulder joint because it is a rotator muscle and the shoulder pads must shift and rotate with the shoulder.
2. BicepMount: This mount is for mounting plates that have things purtruding out like spikes or blades. Anything else should simply be textured on.
3. ForearmMount: This mount is almost always in use by an armor mesh. For instance even a leather glove may have a ring at the end for the bracer and we want the space between the elbow and wrist to have a large look and slightly exaggerated look to it so the characters look heavy handed.
4. HandMount: The hand mount should never be used, ever for mounting gloves or anything else. Glove images should be textured on. This mount point is for weapons and should be placed in the center of the hand by the bone so either a shield or a weapon can go in either hand.
5. ChestMount: This mount point is for sectioned chainmail and plate mail blends. Like for instance a lower level chainmail armor would be completely textured onto the base body replacing the nude skin, but higher levels of chainmail could have a chest plate mounted and chain dressing for the abs.
6. AbMount: This mount point is similar to the one above. These two mounts provide movement for bending motions between the chest and abs so the armor will move naturally without having to be seperatly animated. Peices of armor should be mounted here which wil cover the abdominal region.
(Continued...)
#11
The method, when implemented, looks much like this:
As a result of discussions past the time this thread was posted, we are not using meshes for the shoes. The shoes and the heads will be interchangeable meshes. As soon as we have a finished and textured rendition, I'll let you guys know.
Again- much thanks for your support and advice!
02/13/2005 (11:58 am)
Quote:7. WaistMount: This mount point is for belts and chainmail skirts dress skirts, and utility belts, anything that would go around or hang from the waist goes here.
8. UpperLegMount: This mount point is similar to the bicep mount in that this area should for the most part be textured for armor pieces and should only be used when mounting armor that has protrusions like spikes blades or large intersecting plates.
9. KneeMount: This area also should be textured, but it provides us the ability to add knee pads. Also should support some later animations for riding horses and other beasts.
10. LowerLegMount: Like the upper leg mount.
11. AnkleMount: This mount should only be used when adding intersecting plates for platemail boots so the plates move independantly of the foot and with the ankle bone. This mount should be placed and attachted to the joint between the leg and the foot.
12. FootMount: This is most obvious of all and should always have a mesh for its self. The foot wear in game should always be rather large and more prominant then other features.
Next we will move onto a sample diagram for a test armor set for the drinking knight model to be developed.
Diagram 1.3
In diagram 1.3 it shows the peices of armor that should be modeled, and it shows where they should be placed and on what node.
Diagram 1.4
See how the mesh actually lines up and looks good with just those mounted peices. Now multitexturing is a different animal and must be tackled soon along with the mount points. Look back at diagram 1.1. Those sections will most likely be the way the mesh will need to be divided in UVW in order to support the multiple texure layers needed for each section.
It would be helpful if each modeler would post a diagram like the two I posted for the drinking knight for each model they do so that we could approve the layout before hand.
EDIT: The next diagram illustrates the point that armor texturing will look good.
Diagram 1.5
Now as long as the texture is done well, this systems should work as it is the same system many games like WoW are using as well as most of their predecessors. It's easy and it looks good.
Feel free to comment anytime.
The method, when implemented, looks much like this:
As a result of discussions past the time this thread was posted, we are not using meshes for the shoes. The shoes and the heads will be interchangeable meshes. As soon as we have a finished and textured rendition, I'll let you guys know.
Again- much thanks for your support and advice!
#12
Jeff
02/13/2005 (1:17 pm)
Hey that looks good so far. It sounds like your plan will work... Definitely keep us updated as to how it's working and any problems you run into. This is very interesting!Jeff
#13
skirt made for base model
skin animated
skirt weighted
note legs poking through a little bit, paul was talking about making the under skin mesh invisible, so even if it poked through, it wouldnt be visible.
animated skin in show tools pro
skirt without skin, left with complete bone structure
skirt shown in the middle of the dsq animation that was made using the skin mesh, so the skin and the skirt are sharing this animation successfully
bones not needed for animating this clothing have been deleted
===============WALL=======================
the animations could not be shared between the skirt dts with just the necessary bones, and the skin dts, even tho the names of the bones that were left in the skirt dts, were the same as the names in the skin dts
so, what seems to be the case is. if the bone structure is exactly the same, then the animations can be shared
1. for each piece of clothing would have a duplicate of the entire rig. this may or may not result is excessive processing power. maybe if the bones arent controlling any vertices, then the processing power used is minimal. this would require us to not have to mount anything, as everything would be instantly in place.
2. new dsq's could be created for each clothing model. we would delete the uneccessary bones, and re-export each animation. mounting would be required.
NOTE: with method 2, if we changed any of our animations, we would have to reexport every animation for every clothing model created. not so with method 1.
using method 1, we have the skirt model with the skin model both in show tools pro at the same time (and perfectly aligned by just mounting the root of the skirt with the root of the skin). however, when i assign an animaton to the skin dts, the skirt dts doesnt animate along with it.
02/16/2005 (11:00 pm)
skirt made for base model
skin animated
skirt weighted
note legs poking through a little bit, paul was talking about making the under skin mesh invisible, so even if it poked through, it wouldnt be visible.
animated skin in show tools pro
skirt without skin, left with complete bone structure
skirt shown in the middle of the dsq animation that was made using the skin mesh, so the skin and the skirt are sharing this animation successfully
bones not needed for animating this clothing have been deleted
===============WALL=======================
the animations could not be shared between the skirt dts with just the necessary bones, and the skin dts, even tho the names of the bones that were left in the skirt dts, were the same as the names in the skin dts
so, what seems to be the case is. if the bone structure is exactly the same, then the animations can be shared
1. for each piece of clothing would have a duplicate of the entire rig. this may or may not result is excessive processing power. maybe if the bones arent controlling any vertices, then the processing power used is minimal. this would require us to not have to mount anything, as everything would be instantly in place.
2. new dsq's could be created for each clothing model. we would delete the uneccessary bones, and re-export each animation. mounting would be required.
NOTE: with method 2, if we changed any of our animations, we would have to reexport every animation for every clothing model created. not so with method 1.
using method 1, we have the skirt model with the skin model both in show tools pro at the same time (and perfectly aligned by just mounting the root of the skirt with the root of the skin). however, when i assign an animaton to the skin dts, the skirt dts doesnt animate along with it.
#14
Obviously, you've tested animations when it -wasn't- mounted.
So why mount it at the root? We can perfectly align the skirt and the skin very easily in code, without having to actually mount it. By simply rendering the skirt model right on top of the player model and assigning the same animation to both models, and not necessarily mounting the clothes to the skin, we get the same results without the trouble that is caused by mounting.
Confirm me on this'n, Luke [or anybody who knows], but wouldn't it be possible to just render the skin and the skirt seperately, but right on top of each other, without mounting one onto the other?"
02/16/2005 (11:05 pm)
"Okay. During the brief time that we spoke tonight[, Terry- our animator] , you mentioned that the skirt wouldn't animate because it was mounted to the root of the skin.Obviously, you've tested animations when it -wasn't- mounted.
So why mount it at the root? We can perfectly align the skirt and the skin very easily in code, without having to actually mount it. By simply rendering the skirt model right on top of the player model and assigning the same animation to both models, and not necessarily mounting the clothes to the skin, we get the same results without the trouble that is caused by mounting.
Confirm me on this'n, Luke [or anybody who knows], but wouldn't it be possible to just render the skin and the skirt seperately, but right on top of each other, without mounting one onto the other?"
#15
Ok, this whole duplicate rig thing, defeats the entire purpose of having mounts. We wanted to save time in animation, so what we set were mount points which didn't require us to do anything but animate one base model. Now what you have is an overly complicated system of duplicate rigs which try to share the animations of the base model. Keep it simple. If we have a skirt, or anything that hangs down off the waist, we will simply have to export a new animation called Skirt_Walk Skirt_Jump ect ect, and animate the skirt by hand, then when it's mounted in game, when the base model plays it's walk run animation you call the appropriate animation in game for the skirt. That is what is so great about mounting images, each mounted image can have it's own set of animations.
I stand firmly on the assertion that only having to animate one base model is the way to go. Skirts are fine if you animate them and give them their own animations. Remember, any mounted image can have it's own animations, and make sure our animators know that as well because they dont seem to (AKA they dont think we can have head rotations and facial expressions because the head is mounted). We will be fine with this systems we are just going to have to work on it to MAKE it work for us. So solution?
Give all skirts their own animation and leave everything else alone. If mount points work well with bracers, shoulder pads, and belts, I don't see why we would have to change it. If it's not broke dont fix it sorta thing :)
Now to clarify, we aren't mounting anything to the skin, we are mounting everything to the bones, so that when the bone moves or rotates, the mounted image will move and rotate with it, giving the illusion that the image is animated when in reality it is just a static image moving around on a bone.
02/17/2005 (5:19 am)
I saw this at the internet Cafe' and couldn't wait to get home to reply to this:Ok, this whole duplicate rig thing, defeats the entire purpose of having mounts. We wanted to save time in animation, so what we set were mount points which didn't require us to do anything but animate one base model. Now what you have is an overly complicated system of duplicate rigs which try to share the animations of the base model. Keep it simple. If we have a skirt, or anything that hangs down off the waist, we will simply have to export a new animation called Skirt_Walk Skirt_Jump ect ect, and animate the skirt by hand, then when it's mounted in game, when the base model plays it's walk run animation you call the appropriate animation in game for the skirt. That is what is so great about mounting images, each mounted image can have it's own set of animations.
I stand firmly on the assertion that only having to animate one base model is the way to go. Skirts are fine if you animate them and give them their own animations. Remember, any mounted image can have it's own animations, and make sure our animators know that as well because they dont seem to (AKA they dont think we can have head rotations and facial expressions because the head is mounted). We will be fine with this systems we are just going to have to work on it to MAKE it work for us. So solution?
Give all skirts their own animation and leave everything else alone. If mount points work well with bracers, shoulder pads, and belts, I don't see why we would have to change it. If it's not broke dont fix it sorta thing :)
Now to clarify, we aren't mounting anything to the skin, we are mounting everything to the bones, so that when the bone moves or rotates, the mounted image will move and rotate with it, giving the illusion that the image is animated when in reality it is just a static image moving around on a bone.
#16
===========Quote============
the animations could not be shared between the skirt dts with just the necessary bones, and the skin dts, even tho the names of the bones that were left in the skirt dts, were the same as the names in the skin dts
========================
1. I've had a couple of conversations with the guys here at GG in the past couple of days about this exact issue. It seems that there's really no reason this shouldn't work, but for some reason or another the player class is hard-coded to give an error if it finds a bone with animation (in the dsq) that doesn't exist in the dts shape. So if your coders are smart enough (which it seems they are) you could probably just let it throw that info away instead of returning an error, so you could in fact use method (1) as described above. Also, re-exporting these animations wouldn't really be much trouble, because you can define which bones' animation gets exported in the .cfg file, so you would just have to keep two (or more) copies of the cfg, one with all the superfluous bones in the NeverExport list.
The big problem with this method is that you will end up with every character having several different skeletons. It wouldn't be so bad except you're planning on having many (who knows how many really) characters on the screen at the same time, and you would essentially have at least double the overhead associated with skeletal deformation happening. Admittedly I don't know how much this would really affect the performance.
2. @Paul - I agree that you guys should keep it as simple as possible. The problem with what you wrote is that to have an animation you need to have a rig, which is the reason for the (partly?) duplicate rig. The other option is to do morph-style animations, but as an animator I would much prefer to have bones. It's the difference between moving a bone on two different keyframes (or none, since you're reusing the other animation that's already done) and moving every vertex on every other frame or so to make sure it all stays lined up right. Also, I don't know for sure but this method of animation would be much slower in the engine.
Hmm, thinking about it just now.... maybe you could still use the same animation and just take snapshots of the mesh every couple of frames and create a morph anim based explicitly on the bone anim.... it would still probably end up being more work than is necessary though...
Interesting topic, guys! Keep us updated.
Jeff
edit: when you couldn't get both animations to play in the show tool, did you have a thread running on both shapes separately, each playing the animation? it seems like that should have worked.
02/18/2005 (11:31 am)
OK===========Quote============
the animations could not be shared between the skirt dts with just the necessary bones, and the skin dts, even tho the names of the bones that were left in the skirt dts, were the same as the names in the skin dts
========================
1. I've had a couple of conversations with the guys here at GG in the past couple of days about this exact issue. It seems that there's really no reason this shouldn't work, but for some reason or another the player class is hard-coded to give an error if it finds a bone with animation (in the dsq) that doesn't exist in the dts shape. So if your coders are smart enough (which it seems they are) you could probably just let it throw that info away instead of returning an error, so you could in fact use method (1) as described above. Also, re-exporting these animations wouldn't really be much trouble, because you can define which bones' animation gets exported in the .cfg file, so you would just have to keep two (or more) copies of the cfg, one with all the superfluous bones in the NeverExport list.
The big problem with this method is that you will end up with every character having several different skeletons. It wouldn't be so bad except you're planning on having many (who knows how many really) characters on the screen at the same time, and you would essentially have at least double the overhead associated with skeletal deformation happening. Admittedly I don't know how much this would really affect the performance.
2. @Paul - I agree that you guys should keep it as simple as possible. The problem with what you wrote is that to have an animation you need to have a rig, which is the reason for the (partly?) duplicate rig. The other option is to do morph-style animations, but as an animator I would much prefer to have bones. It's the difference between moving a bone on two different keyframes (or none, since you're reusing the other animation that's already done) and moving every vertex on every other frame or so to make sure it all stays lined up right. Also, I don't know for sure but this method of animation would be much slower in the engine.
Hmm, thinking about it just now.... maybe you could still use the same animation and just take snapshots of the mesh every couple of frames and create a morph anim based explicitly on the bone anim.... it would still probably end up being more work than is necessary though...
Interesting topic, guys! Keep us updated.
Jeff
edit: when you couldn't get both animations to play in the show tool, did you have a thread running on both shapes separately, each playing the animation? it seems like that should have worked.
#17
Hence my quote in the last post :
02/18/2005 (6:09 pm)
Nononononono you read me wrong. He said in his post that they were going to animate every peice of clothing. Theres no need for that when we are using mounts points attached to the bone of the rig. When the arm rotates the armor will rotate giving the illusion of animation. This system already works, we have tested it, we are just working on the problem with skirts, and I suggest setting up a whole rig for the skirt and make specific animations for run and walk for just the skirt naming them skirt_run ect.Hence my quote in the last post :
Quote:
Give all skirts their own animation and leave everything else alone. If mount points work well with bracers, shoulder pads, and belts, I don't see why we would have to change it. If it's not broke dont fix it sorta thing :)
#18
02/19/2005 (10:05 am)
Good point. I guess i did read it a bit wrong. Obviously most armor doesn't flex in real life so you wouldn't want it to in-game. Skirts, shirts, pants, possibly headdresses that hang down on the shoulder area, are the only things I see needing animation.
#19
so paul, we will mix them yah? duplicate meshes and sharing animations for anything that needs stretching, and mounts for others?
shoes are a big one, they will always need stretch, we could use the duplicate mesh for them
and later just a portion of the mesh, once we get Jeff's suggestion working for sharing animations with only portions of the bones present (thanks Jeff!)
02/19/2005 (2:42 pm)
Didnt realise the conversation had stopped at our forums and continued here :/so paul, we will mix them yah? duplicate meshes and sharing animations for anything that needs stretching, and mounts for others?
shoes are a big one, they will always need stretch, we could use the duplicate mesh for them
and later just a portion of the mesh, once we get Jeff's suggestion working for sharing animations with only portions of the bones present (thanks Jeff!)
#20
02/22/2005 (5:38 am)
I think for shoes we need to change the feet entirely. I think we need to make the feet on the base model look more like a shoe so we can just retexture them. It's hard to imagine but the ankle mesh would be what we change for each shoe so like everything else we change the texture on the shoe, and mount a mesh above the ankle that either emulates a boot, high socks, straps, whatever. I dont think we need to cut off the feet and animate seperate or anything drastic like that. Besides, I dont think we want people running around barefooted anyway.
Sanctus Legacy Online Admin
If you happen to read this, Gonzo, please try to send me an e-mail at justinsmith@sanctuslegacy.com. You applied for a position on our team a couple of weeks back, and I replied, but got no further responses from you. You used to work with Paul Fassett, who is also on our team, and he has also tried to contact you- again, to no avail. He recently posted another problem in these forums, and you asked him to e-mail you so you could help him figure out the issue. He sent an e-mail from his account and another account, just to make sure the problem wasn't on our end. There is definitely something preventing you from recieving our e-mails. I sent you an "invite this member to your project" as soon as I recieved your e-mail, but that also remains untouched- presumedly because you recieve too many to be able to filter through them.
Regardless, we have been trying very hard to contact you, because we're very interested in having you on the team. We just can't seem to get a hold of you for one reason or another.
You [or anyone with some advice about this issue] can contact me at:
AIM- SanctusLegacy
YIM- SanctusLegacy
MSN- SanctusLegacyOnline@hotmail.com
Or via our development forums: http://forum.sanctuslegacy.com/