AF File Issues

[Ishtvan]

Since Melee combat is using the AF collision bodies as an initial guess for where the weapon hit, some problems with the AF files have come to light.

 

Head problems

-Most importantly, the head AF is not tracking the head/neck animation! When they tilt their head down, or look to the side, the AF body does not update and stays in place. This causes a disparity between the visual model and the AF body which makes blackjacking fail more often. It needs to be anchored to the same joint that the head attachment is anchored to, so it tracks in these animations. It looks like it's currently anchored to the wrong joint.

 

-Head AF not centered on head in the forward/back direction. This might also be related to being anchored to the wrong joint.

 

-Head AF is an octahedron: We might get better results with a rectangle. We need to tweak the shape and size until it fits most closely around the visual model. Right now the octahedron does not fit well at the top of the head and at the cheeks.

 

Body Problems:

-Torso and pelvis are octahedrons: This does NOT work well and causes huge holes in the AI's sides where things can just pass right through. It also messes up the "is this AF body on the ground" test when dragging AI, and means you can't drag them into a sitting position easily. Look at the zombie for comparison, its body is made up of mostly rectangular prisms and works pretty well.

 

We need to do some serious tweaking of the AF bodies. The AF joints are fine I think, but the bodies should be made more like those of the zombie (which uses a D3 AF, you can extract it from the D3 pk4s). Does anyone want to do this or have any experience with the ingame AF editor?

[Domarius]

I agree these things sound like a big problem. I don't know how to do any of it but if no one can do it, I'll learn. I'm devoting a heap of time to this mod now.

[Ishtvan]

I think there are guides to using the AF editor online, at the iddevnet site. The file is plain text and easy to edit by hand, but it might be hard to tell what joints to use and what offsets/orienations to use without a visual aide link the ingame editor.

 

One thing I forgot to mention: It's better to make the size of the AF body completely relative to joints if possible. Since we're doing short & tall AI now, this means the AF bodies will auto-adapt if you say "the lower leg goes from the ankle joint to the knee joint" instead of "the lower leg starts at the ankle joint and goes up 20.45 doom units." For more complicated polygons it's probably not possible to make it completely relative, but some of the ones in ragdoll_guard (the one nearly all of our AI are using) are already set up like that.

[Domarius]

Well the character bodies are just a tree that sprouts from the hips, so surely it would be possible to do it all relative, everything only has one parent.

[Ishtvan]

Some things still have to have dimensions specified when there's no joint to describe the extent of teh body. Like the AI's torso must be sized in the horizontal direction according to how fat an AI is. Unless you put in a belly button joint.

[Ishtvan]

I attempted to fix the head AF in ragdoll_guard and committed it. The head body is now attached to the head joint, so it follows the head turning animations now, but in trying to fine-tweak it to fit the head, I realised there's a problem:

 

The different attached heads on different AI sharing the same AF file have different offsets from the head joint. The AF file has no way of knowing about these different offsets, so you're never going to be able to fit one AF body in the AF file to all different AI using different heads.

 

Now, there is a way we could do it, using our dynamic AF attachment system, but it would take some work. First, we'd have to add simple clipmodels to the head models (like we do for moveables). This clipmodel will be dynamically added to the AF structure when the head is attached, so it will always fit the head. We would remove the head body from the AF file and let it always be dynamically added to match the head. [EDIT: As an added bonus, we'd be all set to make moveable heads. Severed head basketball, anyone?]

 

However, that requires some things:

1. If we have any AI that don't use an attached head, they would have to use a different ragdoll/AF file that still had the head on there.

 

2. By default the dynamic attachment system sets the mass of the attachment to 1. We would need to set it to whatever we want the mass of the head body to be. (Which is based on the total mass of the AI and the fraction of the weight we want in their head). This is easy, we could parse it from spawnargs.

 

3. By default, the dynamic AF attachment system adds a constraint of type "fixed," i.e., it glues the AF you've added rigidly to whatever AF body you're attaching it to. This is not what we want for the head. We want there to be a neck joint connecting the head and the torso that lets the head flop around believably. This shouldn't be too hard to set up, the functions for adding the constraint data are all exposed, we just have to figure out where we're going to store that constraint data (it can no longer be in the AF file, since the "head" body wouldn't be around yet at the time the AF file was parsed, and we don't have access to the source code for AF parsing). I guess we could put the neck constraint in the spawnargs of the head or the AI. probably the AI, since some might have different collars and pauldrons and whatnot that would constrain how far the head can go before it hits something.

 

Does this sound like an approach we should take? The alternatives are to keep the "one sized fits all" head body, relative to the head joint, but things will break and the head will clip into things if it deviates too much from that. Or, we could have a different AF file for widely different heads, but with all the other data in the AF file, that could become a nightmare to maintain.

 

What do people think?

[Crispy]

Is there a way to move the existing head AF body based on the offset data for the attached visual head model?

 

If not, your suggested approach sounds better than the alternatives, at least in the long run.

[Ishtvan]

I thought about that, but it's rather difficult because the system is basically designed to add the AF body once and then not touch it. I think to adjust the coordinates of the AF body relative to the joints and constraints and get it to load again into the AF matrix solver, you'd basically have to destroy the AF body and add it again. But it's even more of a pain, because the offsets are defined when the AI is in the T pose, so you'd have to "virtually" put the AI in the T-pose, destroy the head and add it again with new offset coordinates, then put the AI back in whatever pose they were in. [EDIT: Plus, when you destroy a body that's used in constraints, it automatically deletes those constraints constraining that body, so you'd have to add the neck joint again.]

 

It seems like it would be just as much work as starting out without a head and dynamically adding the head body based on the head clipmodel when it's bound on. I could be wrong, but I think that's how it works.

[Ishtvan]

Actually, I guess we could keep the neck constraint data in the AF file if we do the following:

 

Start out with a "best guess" head body. If a head is def_attached (actually def_headed), save a copy of the old neck constraint, delete the old head body (this will delete the neck constraint too), add the new head body and copy in the old neck constraint information to a newly added neck constraint.

 

However, we might actually want to set the neck constraint in the AI spawnargs, since right now for example, the Builder's head can clip into their metal collar thingy, it might be nice to adjust it on individual AI without needing a whole separate ragdoll for them. Maybe it's too small a detail to spend a lot of time on though, I dunno.

[Crispy]

Just so we're all clear on the available options, is the following an accurate summary?

 

Option A

* Add clipmodels to heads (Maybe 1-2 hours for a modeller who knows what they're doing? How many heads do we have?)

* Set head AF mass based on spawnargs (~1 hour for a coder with AF experience, most likely Ishtvan)

* Implement some code and spawnargs to change the neck joint and its constraints (~1-3 hours of programming?)

 

Total cost: 1-2 hours of modeller time, 2-4 hours of coder time

 

Option B

* Implement code to put the AI in a T-pose, delete/add the head AF-body based on an attached def_head offset (with copying of neck constraints), and restore the AI's old pose (~3-5 hours of programming? including getting all the bugs out)

* Continue to live with the current situation where neck constraint data can't be set per-AI

 

Total cost: 3-5 hours of coder time, ragdoll heads would still clip into metal collars

 

Option C

Have head AFs in the wrong place compared to the visual head model, making blackjacking weird

 

Total cost: Frustrated players

 

Option D

Make separate AF files for each different attached head (and presumably rely on mappers to switch in the correct AF? like that's going to happen 100% of the time, mappers have enough to remember already )

 

Total cost: Frustrated AF file maintainers and frustrated mappers (or players)

 

 

Is that correct or have I missed something / wildly mis-guessed the times required to implement?

[Ishtvan]

Yeah, that sounds about right to me.

 

Option A seems pretty promising. You can model whatever you want for the head CMs, as long as it's a good fit. I would recommend a box (rectangular prism) CM for the head, it worked well when I set it up manually for the Builder. Octahedrons seem like they're always going to either stick out too far at the points or go too far in at the top/bottom. The only issue is the nose. A box either covers the nose but extends too far out on the rest of the face, or it fits the rest of the face and allows slight clipping at the nose. I think I like the latter option better.

[Crispy]

Cool. I agree then, Option A sounds best.

[Springheel]

The different attached heads on different AI sharing the same AF file have different offsets from the head joint

 

I don't know how this impacts what you're talking about, but as I go through the heads I have been setting them to all use the same head skeleton, which means they will be in the same place relative to their origin. Right now the heads vary quite a bit, which is why there are so many offset values. Once I'm finished, an AI needs only one offset value (at most; some don't need one at all) that works for all the heads, and that offset value tends to be quite small--1 or less for the AI I've looked at so far.

 

Add clipmodels to heads (Maybe 1-2 hours for a modeller who knows what they're doing? How many heads do we have?)

 

It would take a bit longer than that, as the heads are md5meshes. The clipmodel would actually have to be weighted to the head skeleton (can a regular cm be animated?), and then the model would have to be exported as an md5mesh.

 

As for how many we have, there are at least 15, not counting the placeholder ones.

[Ishtvan]

I don't know how this impacts what you're talking about, but as I go through the heads I have been setting them to all use the same head skeleton, which means they will be in the same place relative to their origin. Right now the heads vary quite a bit, which is why there are so many offset values. Once I'm finished, an AI needs only one offset value (at most; some don't need one at all) that works for all the heads, and that offset value tends to be quite small--1 or less for the AI I've looked at so far.

I think that will help a lot. Still, some AI will have all heads attached with a different offset from the head joint than others? If it's just 1 unit, that might be enough to just use the same AF body for all. Although 1 unit in the forward/back direction was still significant for blackjacking.

 

I can look into reading the head offset spawnarg and trying to move the existing head AF body, rather than attaching a new one. I think it would be pretty painful code-wise as mentioned above, but I can doublecheck and see if there is some hack we can do to make it easier. [The main step we want to skip is having to put them into the T pose again, if they're not still in it at the time when heads are attached]

 

It would take a bit longer than that, as the heads are md5meshes. The clipmodel would actually have to be weighted to the head skeleton (can a regular cm be animated?), and then the model would have to be exported as an md5mesh.

Hmm, having the head be an MD5 mesh may complicate things when it comes to using a modeled CM. In that case, we should probably just try the process with one head first and see if it even works. Out of curiosity, in all the head anims, would the CM around the head actually move relative to the origin of the head?

[Springheel]

Although 1 unit in the forward/back direction was still significant for blackjacking.

 

I can almost guarantee that heads won't be moved 1 unit forward or back, unless the head joint on the character is wildly misplaced (and then it would be better to change the skeleton).

 

The most common offset is the up and down one, since some AI have slightly higher necks built into the body, but again that's less than plus or minus 1.

 

Out of curiosity, in all the head anims, would the CM around the head actually move relative to the origin of the head?

 

It depends what it's weighted to. In all likelihood we'd just weight it to the head joint, so it would move with the rest of the head. But the origin of the head mesh is usually weighted to the neck joint, so there's a chance that it would not always line up exactly the same.

[Ishtvan]

If it's only +/- one unit up or down, that might be okay. We can try it and see if it works. What's the current status of the head origins? Have they already been modified and it's just the AI-specific head offsets that need changing, or are the origins still changing?

[Springheel]

We can try it and see if it works. What's the current status of the head origins? Have they already been modified and it's just the AI-specific head offsets that need changing, or are the origins still changing?

 

I've lined up the origins on the new heads that I've made to match the builder guard, but so far it's only 5 heads that are properly lined up (I haven't looked at the builder priest but it probably is too). There will only be 4 heads used in the release map, and I know three of them (the beggar and the 2 builder heads) are consistent.

 

It's possible that when the new skeleton is ready, the characters will need slightly new z offsets--depends if the neck/head joints change much.

[Ishtvan]

The AF file I uploaded was set up for the Builder guard's head. Is that one of the ones with a corrected origin?

 

What about heads that are, for lack of a better word, "fatter" than other heads? If there's variation in head size or shape that would cause it to extend outside the bounding box fit around another head, there could be trouble. We might to code a slightly new system where the head CM gets read from spawnargs on the head entity or something, if we can't put it in the model file.

[Springheel]

The AF file I uploaded was set up for the Builder guard's head. Is that one of the ones with a corrected origin?

 

Yes, that head is going to be the base of all the other heads. All the heads I've worked on (with the possible exception of the citywatch) are already lined up with that head.

 

What about heads that are, for lack of a better word, "fatter" than other heads?

 

What happens, technically, if the head is larger than the AF head box? If it just means the weapon would miss if it hits the mesh sticking out, I don't think that's a big deal. Heads aren't going to vary by size very much, except perhaps when it comes to hair or headgear (and if you just skim the hair that shouldn't really cause a bj anyway). Do you think players are likely to notice if there's a small difference between the head size and the AF size?

 

 

My suggestion is to try it out in St. Lucia, since all the heads are synced already. If it turns out not to work, then we can look at alternatives.

[Ishtvan]

Yes, that head is going to be the base of all the other heads. All the heads I've worked on (with the possible exception of the citywatch) are already lined up with that head.

Okay, that's good news. That means we're already set up to try the "close enough" approach (where we assume the offset is only going to be +/- 1 unit up or down and see how well it works).

 

What happens, technically, if the head is larger than the AF head box? If it just means the weapon would miss if it hits the mesh sticking out, I don't think that's a big deal. Heads aren't going to vary by size very much, except perhaps when it comes to hair or headgear (and if you just skim the hair that shouldn't really cause a bj anyway). Do you think players are likely to notice if there's a small difference between the head size and the AF size?

For blackjacking, it doesn't matter. As long as the AF is centered on the head center, blackjacking should be fairly accurate regardless of whether the mesh extends out of the AF (the code pulls back by 8 units before doing the trace to see if it hit the model, so as long as you don't extend out more than 8 inches beyond the AF body, it should still work).

 

What it does matter for though is clipping. When the AI is unconscious, the AF body for the head really is the collision model, so any parts that extend outside that CM will clip into the ground (or any other object that contacts it). Same goes for resting a moveable on the head, it will clip into any part outside the AF (the nose is actually outside the AF already, but I thought minor nose clipping was better than hovering above the rest of the face because the CM extended out to the nose).

 

The AF is also used as a CM when moveables collide with living AI, but that's probably less of an issue, unless you absolutely have to balance a teacup on a friendly AI's head, and don't want it to clip in.

[Springheel]

What it does matter for though is clipping. When the AI is unconscious, the AF body for the head really is the collision model, so any parts that extend outside that CM will clip into the ground (or any other object that contacts it).

 

Ok, that doesn't sound like a severe problem. If a particular head winds up being larger than the default ones, it may clip a bit, but I don't think that's anything to get concerned about. Some parts of AI will always clip anyway--helmets, pauldrons or other bits that stick out from the rest of the mesh.