I traced into the SV_HullForEntity(edict_t *ent, vec3_t mins, vec3_t maxs, vec3_t offset) function, it check whether the ent is a SOLID_BSP, if not , It will create a BOX bsp . I guess, all entity other than SOLID_BSP has been treated as a BOX, is that too Coarse for a Monster.
Announcement
Collapse
No announcement yet.
Monster is treated as a box?
Collapse
X
-
A Quake BSP contains 3 separate bsp trees.
the point-sized (render) bsp tree, the player-sized bsp tree, and the shambler-sized tree.
SV_HullForEntity just selects which of those trees (aka: hulls) to use.
The offset argument is a return value that keeps things aligned to the bottom-left of the entity, so that entities with a different height can avoid being shot or whatever, but still stand on the ground properly.
It doesn't do the collision itself.
Anyway, each tree/hull is generated from the brushes in the .map. The brushes are expanded on a per-hull basis before being clipped away, based upon the direction of the brush surface and the hull size (a brush being a solid convex set of planes).
monster-vs-monster collisions are also axially aligned bboxes. this is calculated by the 'box' hull, the planes of which are then basically hacked according to the the sizes of the two objects.
_ALL_ hull collisions are then determined as infinitely small points against a set of planes.
so yeah, point, player, or shambler axially-aligned bboxes only. no capsule collisions.
collision code is a nightmare.
-
thanks for the information, now I'm tracking quake's ray-vs-monster collisions, it is different from ray-vs-SOLID_BSP_WORLD , I think quake treats monster a box, and convert box to a bsp tree, so we can both use sv_move() function for the two scenario. I understand John want to keep the code tidy . but it's too coarse for ray-vs-monster collisions.
Comment
-
All the models are AABB....and the hitbox stays at the same angle with respect to world and the models angles. The client / player models being mostly an upright rectangle I think were the main reason behind the concept of AABB. Other models that are at different angles than that with respect to world all got the "point" treatment when sized, in order to not fall out of world if it can be a non stationary object.
I still say you ought to be able to come up with a forumla that "setsizes with respect to angles" and apply it every frame so that you have a more precise hitbox based on the size of the model....then no need to worry anymore about point, player or shambler. It would take a pretty high level mathmatician to devise that forumla. I quit college once I heard the term "pre-calc" - otherwise Id try it myself.
Comment
Comment