Hitboxes rework

[Alicecomma]

Some issues with hitboxes:

1. Some textures have artistic interpretations of what they represent, meaning the hitbox derived from the texture includes a lot of space that shouldn't actually be hit
2. Pawns' textures can only be so small before they become hard to see, meaning realistically small pawns like rats are disproportionally sized and so are their hitboxes
3. Textures with things like spikes have huge hitboxes because the algorithm for downscaling doesn't recognize them as spikes, and it'd be hard to code it to do so

Some solutions:

1. Add the BodySetDef expansion that was in-development ages ago so there's a way to notify the resizer that a fraction of the sprite should be ignored, e.g when there's a tail
2. Allow BodySetDef to select different heights of body groups, then allow the resizer to scale to specifically that part of the sprite as well so different body part heights are hit differently
3. Somehow scale the reported value for very small things, so they are reported as being say 10 cm instead of 50 cm due to sprite size limitations

[Alicecomma]

Some original intentions:

• Too many bodySize are at sizes like 0.05 using the BodySetDef values, such that some pawns become virtually unhittable. This was in part due to poor aiming/projectile intercept code which has since been fixed
• Modders would need to assign very specific values to pawns to get them to "work" with CE. They still need to do so by assigning BodySetDef, but it's not as complex as checking their texture sizes. Adding the body height distinctions and resizing textures based on that would be ideal, requiring much less patching
• Since pawns can turn on a whim, projectile impacts should assume the pawn is a perfectly round column. Not a square (too much advantage for diagonal shots), not a rectangle/oval (turning randomly misses the shot)
• Lots of caching between pawns, since textures are shared between many pawns and life stages
• Allows for handling dessicated graphics perfectly, something which would otherwise be a pain with BodySetDef stuff

[kbatbouta]

erode the texture for area larger than k else dilate, or use the second directive of the texture to get the "content width of the sprite" if it has a contour or a shadow-like thing.

https://www.mathworks.com/help/images/morphological-dilation-and-erosion.html

[jtgibson01]

IMO the biggest reason that CE is so widely love-hated is because it is incompatible with anything unless someone writes a specific patch for it. Here it seems like the ideal strategy would be to use the sprite graphic calculator for any pawn race definition that lacks a body size def (which might even be better as a modextension, so manual support could be added as a patch instead of as a load-on-demand def that swells the def database and bloats the cross-referencing pass).

With a hybrid system, non-manually-adjusted mods would retain basic compatibility, and any behaviour that isn't "good enough" out of the box can be fixed with an enhancement pass by a patch author.

[Alicecomma]

That is more or less the current system, however it could be expanded to handle ALL cases also handled by the texture-based approach.

The texture approach distinguishes between the following:

• Male, Female, neither-textures
• Dessicated and non-dessicated
• Variable textures between lifeStages

So, the Def-based approach would need to hold information for each of those -- and be kept at least moderately up-to-date to the RaceDef changes

[Alicecomma]

I think the texture erosion stuff would not be performant enough for loading a few thousand textures on startup, although I wouldn't know. I thought before of requiring a separate mask texture for each pawn with exact hitbox boundaries, so it'd be a more visual thing, although perhaps that'd also increase loading times significantly.