Using nodraw on character heads.

[Springheel]

I'm working on some character models at the moment, and had an idea about character heads I wanted to get feedback on.

 

Currently, the attachment system for hats/hoods is hit and miss at best. Because the position of the hat is based on the body model, regardless of which heads are attached, it's hard to get it positioned in a way that looks good. What is perfect for one head could be floating above another head or clipping into a third.

 

To solve that problem, I had an idea. We need new heads for our AI anyway. What if I made them with headgear already attached, but added a nodraw skin for the hat part? There would need to be two def entries (one for each skin), but only one model to rig/animate. That way, the hat can be positioned perfectly, but the author can also use a hatless version (it would have been cool to have multiple hat models attached and just swap them all with nodraw skins, but I'm not sure that's possible with the way nodraw works).

 

I don't think this will cause any problems with the hat registering as solid even when it isn't drawn--hats are set to be nonsolid to projectiles (and the blackjack), and I can't think of any other case where it would matter. But perhaps I'm missing something, or someone else can think of a reason why this wouldn't be a good idea.

[Crispy]

It's a shame that it's hard to make every piece of headgear fit every head, but in the absence of being able to do that I think this is a good idea.

[Baddcog]

-EDIT_read this first

I obviously didn't read your thread close enough.

 

Can't the attachment system be changed to make current stuff work correctly. It should be easy enough to attach something to a bone in the head models instead of the bodies.

 

Is there an issue with the head spawning?

 

--

hmmm,

 

I think no_draw would work fine with multiple hats. Just have to use no_draw on 4 of 5 slots in the skin right (5 hats)?

 

Collision I'm not sure. With the AI they have the AF's for the corpse, so that shouldn't be a problem, but I'm not 100% on how the aware AI's collision is so I'm not sure if the no_draw surfaces would be registered like they are with statics. I haven't tried it on moveables either.

 

Do the heads have a seperate collision?

 

Should the hats give shadows?

 

I was actually thinking, but didn't mention it because I thought the heads were ready to go, That it would be really cool to do the heads like Morrowind (Oblivion too I'm sure)

 

All the heads are bald. They have an attachment point that can be assigned, maybe a small cube in 3d program (no_draw).

 

Miss J's head would have an attachment point, probably right between the ears. It is animated to rotate, ect... with the skull.

Miss J's options are:

 

head1: brown hair tied in knot

head2: gold ponytail

head 3: gold ponytail with sombrero (should sombrero just be an attachment to head2?)

 

Anyway, all the hair cuts are an attachment too.

 

It might seem to be a pain having different hair/hat combos but I think it'll save alot of clipping and possibly shadow issues by not having overlapping haircuts/hats. It might also save performance by links and polycount.

Unless you want to remove a hat from an AI but not the hair. Knock them out and the hat falls off...

 

Morrowind rescaled helmets to fit a head type (ogre was 50% larger, elves had a 15% thinner face)

I think we could get by alot easier by just keeping the heads close in size.

We could even use fewer heads and by changing face skins, hair color skins, hair style/hat models. We could have like 2 male and 2 female heads to start. One wider/rounder and one for thinner AI of each gender.

[Springheel]

I think no_draw would work fine with multiple hats. Just have to use no_draw on 4 of 5 slots in the skin right (5 hats)?

 

I thought of that, but then there's that problem of not being able to change skins that *start* with nodraw. Maybe that won't be an issue if the head has a separate .def entry, I'll have to see.

 

Can't the attachment system be changed to make current stuff work correctly. It should be easy enough to attach something to a bone in the head models instead of the bodies.

 

The heads don't have a joint. Heads are attached to the body's 'head' joint, which is actually in the neck, so anything that has to move along with the head needs to be attached to the same joint. AFAIK it's not possible to attach things directly to an object without a joint.

 

The only thing I could think of would be something like the individual attachment values we use for AI, where a loot bag can be given different rotation and offset values depending on the AI model it's attached to. It might be possible to make a system like that for heads, although it could get pretty confusing to specify different values for all combinations of different AI and heads.

 

I'm not sure if the no_draw surfaces would be registered like they are with statics.

 

One thing I'm unsure of is what happens with thrown objects. If you drop a crate on an AI with an attached hat, what happens (both regularly and with nodraw)? The crate isn't considered a projectile, so I don't know if it just hits the hat and bounces off. It would be bad if the player tried to drop a heavy crate on an AI to knock him out, but his woollen cap protects him. It would be even worse if it hit an invisible hat and bounced off.

 

Should the hats give shadows?

 

They shouldn't if they're set to nodraw. Since the hat will be a separate surface, it could be set to cast shadows when visible even though the rest of the head won't (since it uses the simplified shadowmesh).

[Baddcog]

Don't they Ai's have bones for their eyes and mouths? Wouldn't they be attached to a 'master'(origin) bone for the head?

 

 

I think the hats could all be a drawn tex if using multiples on a head. Then the skins, not the base head, would all have only one visible hat.

[Springheel]

Don't they Ai's have bones for their eyes and mouths?

 

Probably, but if you attach a hat to the mouth joint it will move up and down every time the character talks.

 

I think the hats could all be a drawn tex if using multiples on a head. Then the skins, not the base head, would all have only one visible hat.

 

Hmm, that's probably a good idea. There's no need to make the base head useable, and each def entry could just point to a different skin.

[New Horizon]

Hmmm, in TDS...I think they added joints to the AI specifically for this purpose. Depending on what you wanted...you would have a 'hat joint', 'necklace joint'...etc. They did the same thing for binding locks and handles to their door models. It made attaching things VERY easy. You simply placed an object you wanted to attach anywhere in the map, linked them to the joint and BAM...they would snap right into place. We should definitely look into doing this too. It could make the process a lot easier.

[Springheel]

You simply placed an object you wanted to attach anywhere in the map, linked them to the joint and BAM...they would snap right into place.

 

I'm not sure how that would work, exactly, unless all possible attachable objects had their origins and orientation at exactly the same spot. Having an attachable joint on the head would be the most versatile option, definitely, but we'd need to check a few things:

 

1. Is it even possible to def_attach an object to a def_attached object (TDS heads were directly attached to the model, weren't they?)?

 

2. Do attached hats/hair register as solid to moveables? If so, that's a problem. I'm not quite sure how to test this, as I don't think moveables actually do anything to AI currently. Actually, it's not so much whether they register as solid, but do they 'pass along' collision information to the head they're attached to.

[New Horizon]

Yeah, that's an issue. Pretty sure the heads in TDS were attached directly to the models unfortunately. They just dressed them up with mustache, glasses, hair and hat attachments. It was a pretty good system.

 

As for the points you bring to light, I'm really not sure about those either. I wonder how costly it might be to have attachments on top of attachments? I think your no draw solution is highly effective and much easier to setup if it's possible.

[Baddcog]

As I thought,

 

ascottk_head.md5 has:

 

MD5Version 10

commandline "mesh models/ask/ask_head/ascottk_head.mb -dest models/md5/chars/heads/ascottk/ascottk_head.md5mesh -game darkmod -keep eyecontrol Leyeaim Reyeaim loneckcontrol Loneck neckcontrol headcontrol Head Jaw mouth4 mouth5 mouth6 mouth7 mouth8 tongue1 tongue2 Lbrow1 Lbrow2 Lbrow3 Lcheek Llolid Lnostril Lsmile Lsneer Luplid Rbrow1 Rbrow2 Rbrow3 Rcheek Rlolid Rnostril Rsmile Rsneer Ruplid mouth1 mouth10 mouth11 mouth12 mouth2 mouth3 mouth9 -scale 1.05"

 

numJoints 42

numMeshes 5

 

joints {

"origin" -1 ( 0 0 0 )

 

an origin bone, it also has a head bone which is probably what we want to attach to. The origin bone probably doesn't move. The head bone probably moves as would be expected to.

 

I never said we should attach to the mouth bone, obviously that would have funky results, my point was those bones HAVE to have an origin to be an md5 mesh so there's probably something that can be done.

[Springheel]

it also has a head bone which is probably what we want to attach to.

 

You don't attach to bones in D3, you attach to joints. The head joint is, as I said before, on the neck of the AI model, not the actual head itself. If there is already a non-moving joint on the head, I'm unaware of it. Ascottk rigged them, so he would know for sure.

[Baddcog]

The bone IS the joint.

 

A bone swivels at it's base, this is where the 'joint' is located.

 

I'm not sure how the head attachments work exactly. In Morrwind attachments like clothing had to be skinned to a biped so the mesh would move with the bones.

I'm not sure if the alternate heads for DarkRadiant use animation data from bones on complete skeletal systems or if they use anim data from the heads.

 

I suppose they could use the head animations ONLY for the face. Then the head movement comes from the complete skeleton?

If so attaching to the head joint should make the hat follow it just like the head does.

I still don't see why we can't attach a hat to a head's actual Head joint (bone). It exists as you can see in the above example from ascottk_head.mesh

 

The only problem I can think of is if the heads are spawned and attached on load game. Then the head itself (not AI) would need to spawn its own hat.

How does this work exactly?

[Ishtvan]

You don't need a joint to attach something, you should be able to specify the offset from the origin of the model. Use "origin" and "angles" spawnargs to specify the origin and angle of the object relative to the thing you're attaching it to.

 

However, if the entity being attached to is a class that does have joints, the attachment code does expect a joint and need one to function. For example, idAFAttachment are what a lot of heads are. If this is the case though, you know the object must have joints in its md5 structure, and I think all md5 structures must have an "origin" joint, that you should be able to use for attaching headgear to. At least, our heads have the origin joint:

 

I think this is the md5mesh that all of our attached heads are using (I didn't see other ones), found in /models/darkmod/chars/heads/ascottk

ascottk_head.md5

joints {
"origin"	-1 ( 0 0 0 ) ( -0.4999999404 -0.5000000596 -0.5000000596 )		// 
// ...

So use the origin joint for heads. Just make sure you put the attachment of the headgear in the head's def, not the AI's def.

[Ishtvan]

The only problem I can think of is if the heads are spawned and attached on load game. Then the head itself (not AI) would need to spawn its own hat.

How does this work exactly?

It's not a problem and it works exactly like that. The code parses through the entities, coming to the AI, reading the attachment spawnargs, spawning the head, reading the head's attachment spawnargs, spawning the hat and attaching it to the head, then attaching the head to the AI and exiting. The spawnargs attaching the hat to the head are in the head def, the attachment spawnargs attaching head to AI are in the AI def.

[Springheel]

If so attaching to the head joint should make the hat follow it just like the head does.

I still don't see why we can't attach a hat to a head's actual Head joint (bone). It exists as you can see in the above example from ascottk_head.mesh

 

That's the way it already works. Hats ARE attached to the head joint. But the head joint is not on the head model. The head model is ALSO attached to the head joint, which is located on the neck of the AI model. That's what allows us to swap different heads on the same model.

 

So yes, if you attach a hat to the head joint, it will move in relation to the head joint, just like the head. No problem there.

 

The problem I was originally talking about is that when you position the hat in relation to the head joint, it doesn't change position when new heads are attached. So something that is sitting perfectly on a very large head (because it's 9 units above the head joint) could actually be floating above a small head on the same AI model.

[Baddcog]

But are you attaching the hat to the AI.def head joint or are you currently attaching it the the head.def head joint?

 

My point being that the AI's head joint my not exactly match the head's head joint. Anyway, I'd think that the head's origin joint is attached to the body's head joint.

So if the hat is attached to the head's head joint instead of the body's it attach in relation to the head it was created on.

It's hard for me to say how the joints were positioned in relation the the heads. Was one set of bones used and rescaled to each head, then rigged?

 

It would be easier to figure out the hat offset to each head type than each head/body combo.

[Springheel]

But are you attaching the hat to the AI.def head joint or are you currently attaching it the the head.def head joint?

 

Heads don't have an entitydef, only the AI itself does. As far as I know, you can't def_attach something to a model, though perhaps someone knows otherwise.

[Ishtvan]

The head does have an entityDef at some point, because it is a separate entity. However, looking at Id's code, it looks like heads are a special case, where they just take a model argument and don't set up the entity spawnargs until runtime when the head is spawned and attached.

 

It's going to require SDK changes to do something as simple as put spawnargs on our head entities.

 

We could try and use the standard attachment system for heads so that it reads the entitydef like all other attachments. However, I think there is some other stuff that happens only to heads, like setting up the head animations, copying animation joints from the body, etc, that would probably have to be changed in that case. That may take some time.

 

Alternatively, we could add some code to copy over head-attachment spawnargs from the AI to the head. E.g., writing def_head_attach_* would set up attachments for the head by copying that spawnarg over to the head args before they spawn ingame. Id's code is already doing this for the sound spawnargs (snd_*). This would take less time to program, but would be uglier code.

 

idActor::SetupHead

	headModel = spawnArgs.GetString( "def_head", "" );
if(headModel[0])
{
// ...
	// copy any sounds in case we have frame commands on the head
	idDict	args;
	sndKV = spawnArgs.MatchPrefix( "snd_", NULL );
	while( sndKV ) {
		args.Set( sndKV->GetKey(), sndKV->GetValue() );
		sndKV = spawnArgs.MatchPrefix( "snd_", sndKV );
	}

	headEnt = static_cast<idAFAttachment *>( gameLocal.SpawnEntityType( idAFAttachment::Type, &args ) );

 

I'd vote for the first option, make heads read from an entityDef to start with, but I don't know how long it will take to find all the things that would be broken by this and fix them. I guess we should leave the setting up the head code alone mostly, and just change it so that it reads and spawns an entityDef instead of just reading the model. Of course this also means more work for people setting up the AI, since they'll have to make a head entityDef as well as modelDef.

[Springheel]

I'd probably vote for the first option, make heads a standard attachment and get rid of this special case crap, but I don't know how long it will take to find all the things that would be broken by this and fix them.

 

I don't think it's worth doing something that could potentially create that amount of mess. It's a pretty minor issue we're talking about, frankly--getting separate headgear positioned exactly right. Not exactly something to fret over.

 

I'll be able to provide a lot of variety by adding a couple different pieces of headgear to the new head models and then swapping skins--very easy for the mapper, not much trouble for me as a modeler, and no coding issues.

[Crispy]

I'd vote for the first option, make heads read from an entityDef to start with, but I don't know how long it will take to find all the things that would be broken by this and fix them

I shudder just thinking about it. I vote leaving well enough alone and going for the quick and easy fix.

 

As much as the code might need a refactor, we can't really afford to spend that much time and effort on something that won't yield very much practical benefit.

[Ishtvan]

I shudder just thinking about it. I vote leaving well enough alone and going for the quick and easy fix.

 

Actually I was looking at it earlier, and it's only about 20 lines or so where the head entityDef is created from scratch and given a model from the AI spawnarg. If we just make a change that it searches for an entityDefDecl instead of making one from scratch, I don't think anything outside of those lines should be any different. We'd have to make sure that we get the spawnargs of that entityDef before spawning, and copy in the stuff that needs to be copied on to the heads, but I think that's possible. I would do it right now, but I have to go to work right now.

 

Finally, with that system in place, we'd have to go thru and make entityDefDecls for all the head types and put in the right "model" keyword, spawnclass idAfAttachment. Old D3 monsters would be broken, unless we added in a switch to fall back on the old method if it can't find an entityDef by that name, but can find a model.

 

I'm thinking we'll probably need to do this, since there are other things we'd like to add as spawnargs on the head, in addition to just attaching headgear. For example, they're supposed to be made to frobhilight along with the AI, and that also requires exposing the head entityDefs. Some FM authors might want to put a stim or response on the head separate from the body, etc.

[Springheel]

Old D3 monsters would be broken

 

What about our AI that don't have swappable heads (spiders, belcher, etc)?

 

This would mean having to rerig the existing heads to add a new stationary joint as well, wouldn't it?

 

Seems like a lot of fuss at this stage of the game for a pretty minor issue, IMHO, but perhaps it's easier than it sounds.

[Ishtvan]

What about our AI that don't have swappable heads (spiders, belcher, etc)?

They wouldn't be effected at all, since they don't have the def_head spawnarg in the first place

 

This would mean having to rerig the existing heads to add a new stationary joint as well, wouldn't it?

No, as I understand it our heads already have a stationary joint called "origin" that things attached to the head may be referenced to.

 

Seems like a lot of fuss at this stage of the game for a pretty minor issue, IMHO, but perhaps it's easier than it sounds.

Well, I think we're going to need it if we ever want AI heads to frob hilight along with the body (which we do). Otherwise we would have to add even more special-case code for that rather than using the general method for setting up frobbing.

[Crispy]

Actually I was looking at it earlier, and it's only about 20 lines or so where the head entityDef is created from scratch and given a model from the AI spawnarg. If we just make a change that it searches for an entityDefDecl instead of making one from scratch, I don't think anything outside of those lines should be any different. We'd have to make sure that we get the spawnargs of that entityDef before spawning, and copy in the stuff that needs to be copied on to the heads, but I think that's possible. I would do it right now, but I have to go to work right now.

Oh, I see what you mean now. Yeah, that should be OK.