Using D3 Heads

[ascottk]

Awesome, spar! Can't wait to try it out

[Springheel]

Does "offsetHeadModel" "0 0 0" go in the builder entity or the model? If it's the former, won't that be a problem, because it will offset our own perfectly-aligned heads?

 

It would be much more convenient if the variable could be applied to the model definition. Using the current system, if I want to have 3 different builders with unique heads in my map, I'd have to make three separate adtm:ai_builder entities. If you start adding in some other ai models to the mix, you could easily wind up having to make (and therefore scroll through in the entity browser) fifteen or twenty versions of the same three AI. And every time a mapper wants to create a new body/head combo, they'd have to make a new def file. That's going to get very messy.

 

If the offset could be added to the model definition, then it only needs to be added once, and it won't screw up our default heads. In the rare case that it needs to be offset by a different amount for another model, then we can create another modelDef. Since modelDefs don't show up in the entity browser, it doesn't clutter anything up.

[ascottk]

It would be much more convenient if the variable could be applied to the model definition. Using the current system, if I want to have 3 different builders with unique heads in my map, I'd have to make three separate adtm:ai_builder entities. If you start adding in some other ai models to the mix, you could easily wind up having to make (and therefore scroll through in the entity browser) fifteen or twenty versions of the same three AI. And every time a mapper wants to create a new body/head combo, they'd have to make a new def file. That's going to get very messy.

 

If the offset could be added to the model definition, then it only needs to be added once, and it won't affect our default heads. In the rare case that it needs to be offset by a different amount for another model, then we can create another modelDef. Since modelDefs don't show up in the entity browser, it doesn't clutter anything up.

Which reminds me, I started to separate the head models defs from the to tdm_ai_heads.def. Is that desirable? That way we don't have to look in each of the character defs in order to find a head.

[Springheel]

Yes, I was going to suggest that.

[ascottk]

Then we could have a modified version of d3's heads.def with the approriate offset.

[Springheel]

Exactly. If we can get the offset into the model definition, that is.

[ascottk]

"offsetHeadModel" "0 0 0"

 

It's already up on CVS, so you can download it.

 

I noticed a problem with this method though. The elite builder, that is in teh test_head.map works fine, but when the idle animation is playing and he turns his head sideways, then the head is not only rotated but also moved a bit. This causes it to clip through the armor. Quite noticeable when you stand right behind him and watch him with the torch to make him a bit brighter.

Also the idle anim seems to turn the head only to the right side. I watched it several minutes and it never turned left.

Yeah, the head clipped into the armor without the head separation as well. Also the idle animation isn't related to the separated head because all of the animations for the head are stationary.

[Springheel]

There's something that seems very non-random about the head-turning. I watched the AI in the warehouse map for quite a while once and they seemed to look at particular places very frequently. I've also noticed a noticeable trend for them to turn towards walls as opposed to away from them, which isn't terribly desirable.

[sparhawk]

Hmmm, I looked for the left turning issue, but the head on my guard did turn left...perhaps just not as much as he turned right. Will have to keep an eye on it though. I"ll post if anything pops up. Great work.

 

Maybe mine got a sore neck on the left side from all that head offsetting.

[sparhawk]

Does "offsetHeadModel" "0 0 0" go in the builder entity or the model? If it's the former, won't that be a problem, because it will offset our own perfectly-aligned heads?

 

Yes. That's the problem.

 

It would be much more convenient if the variable could be applied to the model definition.

 

I have to check if we have access to that code. I never saw this, but then I wasn't really looking for it either, so it might be that the code is in there. Maybe Ishtvan knows it directly, as he worked with the AI before. If not I look into it tonight.

 

Using the current system, if I want to have 3 different builders with unique heads in my map, I'd have to make three separate adtm:ai_builder entities.

 

That's nonsense. For now you can just put it in the entity definition on the map. In worst case a prefab can be constructed, but it should definitely not go in the def file.

 

If the offset could be added to the model definition, then it only needs to be added once, and it won't screw up our default heads. In the rare case that it needs to be offset by a different amount for another model, then we can create another modelDef. Since modelDefs don't show up in the entity browser, it doesn't clutter anything up.

 

I look into it.

[sparhawk]

There's something that seems very non-random about the head-turning. I watched the AI in the warehouse map for quite a while once and they seemed to look at particular places very frequently. I've also noticed a noticeable trend for them to turn towards walls as opposed to away from them, which isn't terribly desirable.

 

Maybe we can add some code that helps the randomization to better determine where to look. It might also be usefull to allow the mapper to determine where the AI doesn't need to look. Something for later.

[Springheel]

but it should definitely not go in the def file.

 

I agree, but I thought that's what the latest version did:

 

When I put offsetmodel 0 0 -7, in the entity def for the builder

[sparhawk]

Yes. You can do this for testing purposes, but not to submit it to CVS or such.

[sparhawk]

OK. So since I'm a lazy bastard, instead of coding this feature, I found out how to do this by looking into the code.

 

The good news is, the parser for the modeldefs is in the SDK, so we can change such stuff as well. The other good news is that there is also an offset parameter that does exactly what we need and it's already implemented.

 

I created a new head def by copying the original one and it works nicely. I also checked the collsionmodels and that's also fine. In fact I don't really think that there will be any command that can offset a model from it's collisionmodel, because that would be pretty pointless IMO.

 

model tdm_head_young
{
mesh							models/md5/characters/npcs/heads/h2.md5mesh
channel eyelids						( Ruplid Rlolid Luplid Llolid )

anim idle						models/md5/characters/npcs/heads/h2idle.md5anim
anim stand						models/md5/characters/npcs/heads/h2idle.md5anim
anim blink						models/md5/characters/npcs/heads/h2blink.md5anim
anim dead						models/md5/characters/npcs/heads/h2death.md5anim
anim IPN_News						models/md5/heads/young/marscity/IPN_News.md5anim
{
	frame 1						sound_voice sound/vo/video/video_ipn_news.wav								
}

offset							( 0 0 -7 )
}

 

Just put this code in a tdm_heads.def and of course you must replace the name in the map to tdm_head_young. I did it this way to be sure. And also remove that modelHeadOffset parameter. We can still leave it in the SDK, because this way a mapper can create a new def for a general head, or he can adjust that parameter just for a particular single entity if he wants to. Which gives the most flexibillity.

[sparhawk]

From reading the code, you can also use inherit like in an entity def, and there is another command "remove" which can be used to remove a named animation. Don't know if you knew this, I didn't. And the animation parser is also in the SDK, so we can also extend this thing if needs be.

[Springheel]

Well, damn, that's pretty cool. How often do we find out that something we're trying to do is already possible, there just isn't any damn documentation to tell us so?

[sparhawk]

Yup! That's the problem. You have to read the code, and probably in many cases interpret it correctly, to know what is already there.

[ascottk]

Works perfectly

[Springheel]

I can go through the heads and transfer the ones we can use to tdm_heads.def if you like Ascottk...I know you've got a lot of other stuff on your plate. Or if you've already gotten it mostly done, that's fine.

[ascottk]

I can go through the heads and transfer the ones we can use to tdm_heads.def if you like Ascottk...I know you've got a lot of other stuff on your plate. Or if you've already gotten it mostly done, that's fine.

Okay, go ahead We could start converting d3's heads too.

[Springheel]

Actually, that's what I meant, converting the D3 heads. I'll go through and find out which ones are actually useable (obviously the ones with the glasses or helmets are out) and then do up new definitions for them in our heads.def file.

[ascottk]

Yeah, I already committed our heads under tdm_ai_heads.

[sparhawk]

Do you also plan to make the boar head a head?

[Springheel]

I'm not sure it would work terribly well, since it probably doesn't have a 'back' to it. Even if someone went through the trouble of making it three dimensional and animating it, I'm not sure it would actually look very good on a humanoid body.

 

I had actually thought about trying to def_attach the werewolf head to someone as a proof-of-concept though. The ghoul's movement animations would world pretty well with it.

[sparhawk]

Well, maybe pink can finish it, so it can used also in other circumstances. Might be usefull, because you can also use the head just lying bloody on the floor or in some forgotten attic rotting.

 

You probably just have to model a small backpart that is cut off anyway.