Using D3 Heads

[ascottk]

Ugh, I finally figured out why the elite citywatch's head was a black box. It was a conflicting def file from one of my earlier experiments The problem now is that the head joint is too low on the main body & any head I attach to him looks too low.

[Springheel]

I've discovered that we are going to have to have multiple model definitions for the head after all. While 0 0 -7 looks good on the builder guard, it is way too high for the city watch (which needs to be around -10.5).

 

So I'm going to need to make multiple versions, like a head_young_builder, head_young_city_watch, etc.

 

Would it make sense to put all those into the same tdm_ai_heads.def file, or would it be easier if I made separate files for each? A tdm_ai_heads_builders.def, tdm_heads_citywatch.def, etc?

[ascottk]

I've discovered that we are going to have to have multiple model definitions for the head after all. While 0 0 -7 looks good on the builder guard, it is way too high for the city watch (which needs to be around -10.5).

 

So I'm going to need to make multiple versions, like a head_young_builder, head_young_city_watch, etc.

 

Would it make sense to put all those into the same tdm_ai_heads.def file, or would it be easier if I made separate files for each? A tdm_ai_heads_builders.def, tdm_heads_citywatch.def, etc?

The model definitions don't take much room but it'd be nice to separate d3 heads from tdm heads. We could separate them according to factions later if the need arises.

[sparhawk]

I've discovered that we are going to have to have multiple model definitions for the head after all. While 0 0 -7 looks good on the builder guard, it is way too high for the city watch (which needs to be around -10.5).

 

So I'm going to need to make multiple versions, like a head_young_builder, head_young_city_watch, etc.

 

I told you that this is what's likely going to happen. Doing all permutations of the heads is really a crap solution. It is much cleaner to use the head offset on the AI Model, because any head for a given model will always have the same offset, but you can't know which head is going where.

 

Would it make sense to put all those into the same tdm_ai_heads.def file, or would it be easier if I made separate files for each? A tdm_ai_heads_builders.def, tdm_heads_citywatch.def, etc?

 

Neither. Just put the offsetHeadModel on the AI entity def, and it should work, because you only do this once per model.

[Springheel]

I told you that this is what's likely going to happen. Doing all permutations of the heads is really a crap solution. It is much cleaner to use the head offset on the AI Model, because any head for a given model will always have the same offset, but you can't know which head is going where.

 

I was already aware that's what was going to happen. But putting it on the AI entity is an even worse solution, because you still can't use one value for all heads. You need at LEAST two values, one for our heads and one for the D3 heads. However, the D3 heads aren't all consistant either. Not to mention heads that may be created in the future, like the wolf or boar heads. They all require individual tweaking.

 

Making multiple model definitions is very little work and is very easy to organize. Making multiple AI entity defintions is messy and confusing.

 

In a related issue, there's also the consideration of what heads actually suit a particular model. Our builders, for example, are supposed to favour goatees and have red coifs on their head. There are some heads that just won't look appropriate for builders, but might work well for guards, etc.

 

Of course, mappers can do whatever they want, but by grouping the heads by faction we also have a way to suggest which heads are appropriate for our particular setting's "look and feel".

 

Anyway, I'll go ahead and take care of it. If people don't like the way I organize it, it's just a cut-and-paste job to rearrange it, and it won't have any effect on anything in-game.

[sparhawk]

I think what we should do is, to modify the offset command, so that it allows to specify a modelname to give it multiple parameters. Something like this:

model def head

{

...

offset ( 0 0 -7 ) // default

offset ( 0 0 -10) builder_guard

offset ( 0 -1 -6) builder_acolyte

offset ...

}

 

That would be much cleaner and also easier to maintain, because you just have to add a new entry if it doesn't work for one AI. If none is defined it doesn't use an offset. If no name is given, then it is the default for all AIs where the name is not specifically mentioned and if the AI is named it uses this value.

[Springheel]

I can see pros and cons to that idea. On the one hand, we'd need fewer model definitions for heads. On the other hand, it is more difficult for mappers to find out which heads are good heads for a particular model.

 

I imagine a mapper placing a bunch of city watch guards in his map, and he doesn't want them to look all the same. So he goes to the tdm_ai_heads_citywatch.def file, and there are listed every single head that we've decided looks good on citywatch models. He can just pick and choose randomly from the list if he wants.

 

If we have multiple offsets in the same model def, then the mapper would have to open the one tdm_ai_heads.def file, and scan through them all for ones that have a "offset (0 0 -10) citywatch" line.

 

There's also the possibility that we might want the head to play different animations depending on what body it is attached to. Perhaps if it were a builder, the idle animation would be a stern frown, where if it was a generic townsfolk we could set the idle animation as a blank smile. Not a great example, but you get the idea. If all the offsets are in the same model definition, then the animations will be constant for all characters. If we make separate model definitions, we could also specify separate animations depending on what AI it is attached to.

[sparhawk]

If you want to use multiple animations you can still create different defs for it. That doesn't change. And about the listing, since we have our own editor being built, we can ask Orb to include that feature, which would it even make it easier for the mapper to decide.

 

The solution is obviously transparent, so your current way is still working, even if I add this feature, but it makes it much easier to control which heads are already working for which AI models. And I can assure you that this would get out of hands really fast because you have to create essentialy H*M defs.

[Springheel]

Yeah, that's a good point--one doesn't immediately make the other not work. Ok, I'll continue to try and come up with the right variables for each head/body combo and just record them. If you can set up a multiple offset system them we can use that.

[sparhawk]

OK. I see what I can do tonight. Shouldn't be to hard, as this is only a little parsing and a mapping table per model.

[Springheel]

Hey, I just thought of something...would it be possible to do this for entities as well? It would be particularly useful for things like belt pouches or keys on a belt, because a perfect offset for one AI actually clips into the waist of other AI. I imagine we'll have the same problem with attaching swords to hips, etc. If we could add multiple offsets to entities, that would solve the problem nicely.

 

And in fact, if we could add them to entities, then it WOULD make sense to add the offsets to the AI definition instead of the head, because then the mapper can see at a glance which heads go well with that AI.

[sparhawk]

Yeah. That's even easier to do I guess.

[sparhawk]

Wow! I'm such a genius. I thought that I would have to implement a mapping table and look it up when the head is spawned, but instead I found such a simple and elegant solution to this problem.

 

So it works like this now. In the AI entity def you have a line where you set the default head for a model. If you do nothing than this head is used and no offset is applied. If you want to use a default offset, then you can specify offsetHeadModel and this will be applied to ALL head UNLESS there is a specific key. In order to use a specific value for a given head just use the heads model name as the key and specify the values as a vector. The nice thing is that this took only two lines to add to make it work.

 

If you don't need it you don't need to set the offsetHeadModel key, so in most cases it will be unneccessary, but since I already implemented it, we can just as well leave it in.

 

entityDef atdm:ai_builder_guard
{
"inherit"			"atdm:ai_humanoid"
"ragdoll"			"guard_base"
"model"				"builderguard"
"def_head"			"head_builderguard"
"head_elitecitywatch"		 "0 0 5"
"tdm_head_young"		"0 0 -7"
"head_joint"			"Head"

 

As you can see in the example, if you use head_builderguard as the head, which is the default for this AI, then there is no offset added, as there is no default value set, and also no specific key. If you use the head_elitecitywatch as the head, then it will be moved 5 units upwards, while the tdm_head_young will be moved 7 units down. Any other head will also not be adjusted as there are no keys for them. Of course these numbers are just examples and have to be adjusted. So I put the change up on CVS now.

[Springheel]

Great!

[sparhawk]

It's already on CVS so you can download it. You need to update the DLL and teh def for the builderguard. Well, not really, you can just use the DLL, but I put this example in the builderguard and you probably should fix it.

[Springheel]

Any chance this can also be used when attaching static models like belt pouches?

[Springheel]

Ok, I've gone through the list of D3 heads. Once you get rid of all the ones with modern helmets or glasses, we're left with about 7 useable heads (not counting the zombie heads which I haven't looked at yet). Not all of these heads would be appropriate for any kind of AI--the old bald ones probably wouldn't look great on a guard but might look good as a builder priest or nobleman, for example. In fact, unless we can dynamically attach helmets to them (more on that idea later), we really won't be able to use them for city watch (since they have a distinctive helmet). Several of them would be very effective for professional guards though.

 

Anyway, here they are. (I accidently included one twice, which is why there are 8 images)

[ascottk]

Ok, I've gone through the list of D3 heads. Once you get rid of all the ones with modern helmets or glasses, we're left with about 7 useable heads (not counting the zombie heads which I haven't looked at yet). Not all of these heads would be appropriate for any kind of AI--the old bald ones probably wouldn't look great on a guard but might look good as a builder priest or nobleman, for example. In fact, unless we can dynamically attach helmets to them (more on that idea later), we really won't be able to use them for city watch (since they have a distinctive helmet). Several of them would be very effective for professional guards though.

 

Anyway, here they are. (I accidently included one twice, which is why there are 8 images)

Wow, those guys are fugly! We should have static mesh helmets for attachments too.

[Springheel]

Yeah, I'd like to be able to attach helmets, but we'd have to solve two problems...how does the KO system detect a def_attached helmet, and how do we get it to register collisions from arrows and the like (actually, I can't remember if that last one is still an issue or not--I have this vague memory that def_attached objects are non-solid, but obviously the weapons aren't...

 

BTW, I think I can salvage a few more heads with some creative texture modifications...stay tuned....

[ascottk]

Yeah, I'd like to be able to attach helmets, but we'd have to solve two problems...how does the KO system detect a def_attached helmet, and how do we get it to register collisions from arrows and the like (actually, I can't remember if that last one is still an issue or not--I have this vague memory that def_attached objects are non-solid, but obviously the weapons aren't...

 

BTW, I think I can salvage a few more heads with some creative texture modifications...stay tuned....

I wondered about the KO system too.

[sparhawk]

Any chance this can also be used when attaching static models like belt pouches?

 

Sure. But I have to see how to do this. I need a map with such a setup, so that I can test it. It would be a bit harder for arbitrary places, as the object has to stay in place relative to the Ai. Or do you mean just to attach it to a bone with an offset? I must look if there is already something like this.

[sparhawk]

Nice work. Though the heads look quite knwon to me from Doom 3. Maybe it's just because I know the game though. Anyway, we have no other heads at the moment so these are as good as any others.

 

Maybe they could use a different skin with their hair though. They all look quite marineish with their short hair.

[Springheel]

Maybe they could use a different skin with their hair though. They all look quite marineish with their short hair.

 

Yeah, one of my next tasks is to start applying some skins to them to add even more variety and make them look less recognizable. I won't be able to change the length of the hair though. If we can figure out a way to attach helmets so they work with the KO system, then the hair won't matter anyway.

 

Or do you mean just to attach it to a bone with an offset? I must look if there is already something like this.

 

Yes, the current def_attach system allows you to set up an entity, like prop_belt_pouch, set a particular joint to attach it to and then use an origin command to offset the model until it's in the position you want.

 

Problem is, while (20, 4, 15) might be perfect for attaching prop_belt_pouch to the citywatch's belt, it needs to be (20, 10, 12) on the builder guard so it doesn't clip into his armour (as an example).

 

At the moment, that would mean we'd have to make two different prop entities. What I'd like to be able to do is something like the same thing we're now doing for heads:

 

prop_belt_pouch

 

"joint" "spine"

"origin" "0 0 12" // default

"adtm:ai_builder_guard" "origin" "0 12 12" //aligned for builder guard

"adtm:ai_citywatch" "origin" "0 10 12" // aligned for citywatch

 

etc.

[sparhawk]

Can you give me a complete example of a def where a puch or something is attached to an AI?

 

In that case I will change the fix from yesterday so that the name will be like:

 

"head_<modelname>" "offset"

"joint_<modelname>" "offset"

 

It is more consistent and this way you attach heads on the belt as well.

 

Do you also have joints on the hands?

[Springheel]

I'm at work right now, so I can't yet, but I think tdm_props.def is on CVS, and it has a list of objects that are set to be attached to AI.

 

I don't think the joint definition needs to be on the AI entity--with static meshes it is defined in the entity definition of the object. All the definitions for attached objects should be part of the entity definition for that object, otherwise we'd have to modify every ai.def each time a new carried object is created.

 

I'll post an example when I get home.