A question about 3D enemies and hitboxes

[hardcore_gamer]

So one of the advantages of using 3D enemies in games instead of sprites is that you can use hitboxes for specific body parts. Gzdoom supports MD3 model enemies, so is it possible to take advantage of this? Would it be possible for example to give the arms their own hitboxes and then have those hitboxes turn 90 degrees if the enemy itself does so?

 

How do hitboxes work for 3D enemies differently than they do for sprites if they do at all that is?

[scifista42]

Graphics are completely independant on physics. Appearing as a sprite or a model doesn't change anything related to physics, such as how hitboxes work.

Edited May 18, 2018 by scifista42

[Barry Burton]

Yeah, you're still limited to one bounding box, as scifista was alluding to. Someone was working on model collision, and had a demo of it working IIRC. Here's a link to it: https://forum.zdoom.org/viewtopic.php?f=122&t=59069&p=1035288&hilit=model+collision#p1035288

[hardcore_gamer]

Ok, but is it still possible to do some kind of trick like Brutal Doom where you have each enemy spawn an extra actor that you can't see at different heights/angles that have their own hitboxes? Something like this:

 

This is how Brutal Doom did it right? The thing is though I have no idea exactly how this was implemented. All I know from what I can gather is that in Brutal Doom each monster supposedly consists of more than 1 actor, with the other actors being basically "fake monsters" that spawn at specific locations around the parent actor/monster but have no actual sprites, and yet can still be killed by damaged thus playing a specific death animation.

 

Or at least I think that is how it works. I would be extremely interested in understanding this process better and then hopefully find some way to implement it for my 3D models.

[Arctangent]

Through use of ZScript, it should be pretty simple to have a single hitbox be the "primary" actor, which then creates the rest of the "secondary" actors through an PostBeginPlay() override and maintains their position in its own Tick() override - you'd want to do it that way specifically as otherwise you run the risk of desyncing some hitboxes by a tic.

 

Furthermore, proper locational damage multipliers would be a lot easier than in Decorate, as the secondary actors could override DamageMobj() to intercept the damage dealt to them, then deal it altered to the primary actor.