CollisionProperty
January 2024
All entities that are collideable have a CollisionProperty
. There's an accessor in CBaseEntity
called CollisionProp()
that lets you access/interact with collision functionality. Here is an overview of some of the functionality contained in the collision property:
Entities that use VPhysics also have a IPhysicsObject
which provides additional collision properties related to vphysics simulation.
For the entity's motion, the collision property's solid type (CollisionProp()->SetSolid()
) determines what type of collision primitive to use for tests.
There is also unsigned int CBaseEntity::PhysicsSolidMaskForEntity( void ) const
which determines what types of contents are solid for the entity. Most things are CONTENTS_SOLID
, but there are a set of flags (mostly used by the BSP compiler) that can specialize contents to be filtered by certain traces or movement types. An example of this is CONTENTS_GRATE
which is applied to brushes textured with textures that should be solid for movement, but not for bullets or line of sight tests.
Otherwise CBaseEntity::m_CollisionGroup
determines which other entities will collide with this one. The rules for which collision groups collide are in CGameRules::ShouldCollide()
and can be customized to suit the needs of a particular mod.
Surrounding bounds
Surrounding bounds are used as a coarse test for many queries like collision and visibility.
For example, ray/box traces are first checked against the collision property's surrounding bounds to determine whether to then check for intersections with hitboxes on players. So a player's surrounding bounds need to be configured so that they always enclose any hitboxes that should be checked.
By default the surrounding bounds are computed as a box that surrounds the collision hull. If the collision hull is smaller than the hitboxes, the surrounding bounds must be enlarged to guarantee a proper hitbox test. It can be customized by calling:
CollisionProp()->SetSurroundingBoundsType( USE_GAME_CODE );
The parameter can be any of these:
enum SurroundingBoundsType_t
{
USE_OBB_COLLISION_BOUNDS = 0,
USE_BEST_COLLISION_BOUNDS, // Always use the best bounds (most expensive)
USE_HITBOXES,
USE_SPECIFIED_BOUNDS,
USE_GAME_CODE,
USE_ROTATION_EXPANDED_BOUNDS,
USE_COLLISION_BOUNDS_NEVER_VPHYSICS,
SURROUNDING_TYPE_BIT_COUNT = 3
};
USE_HITBOXES
will simply transform all hitboxes and build a surrounding box around those. This can be expensive to do every frame (players generally move every frame), but may be the simplest way to solve any hitbox problems.
USE_GAME_CODE
lets a programmer customize the bounds as needed by calling a virtual defined in the entity's class:
virtual void ComputeWorldSpaceSurroundingBox( Vector *pWorldMins, Vector *pWorldMaxs );
USE_SPECIFIED_BOUNDS
could also be used to solve this problem by specifying a constant box that is always larger than the space occupied by hitboxes in any animation. As a trade off, this will be cheaper than USE_HITBOXES
as the player animates and moves, but more a conservative boundary resulting in more hitbox queries happening against ray tests that miss. The highest performance method will depend on the mod's number of players moving vs. number of ray/box traces computed against players (and how many of those queries actually miss).