Bounding box: Difference between revisions
m (Added Dimensions to See Also) |
TomEdwards (talk | contribs) (destubbed) |
||
Line 1: | Line 1: | ||
{{ | {{toc-right}} | ||
A '''Bounding Box''' is an invisible box that defines the rough size of an entity. It's used to perform [[cheap]] collision tests, often before moving on to more expensive ones: for example, bullets are only tested against [[hitbox]]es if they are first found to intersect with the given entity's bounding box. Bounding boxes are also used to calculate all non-[[vPhysics]] ("qPhysics") world collisions. | |||
While this optimisation is very worthwhile, it does mean that collisions with parts of an entity that protrude from a bounding box won't be properly detected. Bullets will pass straight through (''unless'' they hit the bounding box afterwards), and world collisions won't occur at all. It's therefore important for animators, modellers and programmers to all be aware of what each other are doing, and together come to the best compromise on bounding box size. | |||
== Rotation == | |||
One other caveat of bounding boxes is that they are always aligned to the world's axes, and never rotate. This is presumably because of their use for collision detection of players: it would be impossible to turn around in a tight corridor if the four corners of your bounding box rotated with you. Axis-aligned boxes are also far cheaper to compute. | |||
While this isn't a huge issue for objects that are roughly square from above, it makes oblong dimensions difficult to manage without switching to [[vPhysics]]. When vPhysics isn't an option there isn't much that can be done: a [[Day of Defeat: Source]] player who has gone prone has an oblong shape that can rotate through a full 360°, which Valve could only accommodate for by creating a 'squished' bounding box that leaves the head and feet sticking out at all times (an image of this would be nice). | |||
=== Object-aligned === | |||
There is an amount of code in the SDK for object-aligned bounding boxes, which rotate with their entity. It is unclear how well these work, if indeed they work at all. | |||
== Defining == | |||
Source will automatically create bounding boxes. But if you need to tweak the results: | |||
* Modellers use the [[$bbox]] QC command. | |||
* Programmers call <code>[[UTIL_SetSize()]]</code>, which assumes <code>[[SetSolid()|SetSolid]]( SOLID_BBOX )</code>. | |||
== Uses == | |||
* [[qPhysics]] collision detection (mainly NPCs and players) | |||
* [[Tracer]] collision detection | |||
* Line-of-sight checks | |||
* {{todo|Current [[PVS]]?}} | |||
==See Also== | ==See Also== | ||
* [[Anatomy of a Model]] | * [[Anatomy of a Model]] | ||
* '''Surrounding Bounds''' section [[CollisionProperty]] article. | * '''Surrounding Bounds''' section [[CollisionProperty]] article. | ||
* The [http://msdn.microsoft.com/en-us/library/microsoft.xna.framework.boundingbox.boundingbox.aspx BoundingBox Constructor] is a method for defining cuboid vertices. By specifying only the "min" and "max" 3D coordinates - representing two diagonally opposed corners of the box relative to a point origin - the other six vertices are implied. This method is used to define ''Axis Aligned'' bounding boxes, [[hitbox]]es, [[NPC Hull]]s and [[Player Hull]]<!-- Hulls = Movement Boxes ?--> in code, and is obviously a great deal simpler than listing [[SMD|SMD mesh triangles]]. | |||
* The [http://msdn.microsoft.com/en-us/library/microsoft.xna.framework.boundingbox.boundingbox.aspx BoundingBox Constructor] is a method for defining cuboid vertices. By specifying only the "min" and "max" 3D coordinates - representing two diagonally opposed corners of the box relative to a point origin - the other six vertices are implied. This method is used to define ''Axis Aligned'' | |||
* [[Dimensions]] | * [[Dimensions]] | ||
[[Category:Glossary]] | [[Category:Glossary]] |
Revision as of 09:30, 8 March 2009
A Bounding Box is an invisible box that defines the rough size of an entity. It's used to perform cheap collision tests, often before moving on to more expensive ones: for example, bullets are only tested against hitboxes if they are first found to intersect with the given entity's bounding box. Bounding boxes are also used to calculate all non-vPhysics ("qPhysics") world collisions.
While this optimisation is very worthwhile, it does mean that collisions with parts of an entity that protrude from a bounding box won't be properly detected. Bullets will pass straight through (unless they hit the bounding box afterwards), and world collisions won't occur at all. It's therefore important for animators, modellers and programmers to all be aware of what each other are doing, and together come to the best compromise on bounding box size.
Rotation
One other caveat of bounding boxes is that they are always aligned to the world's axes, and never rotate. This is presumably because of their use for collision detection of players: it would be impossible to turn around in a tight corridor if the four corners of your bounding box rotated with you. Axis-aligned boxes are also far cheaper to compute.
While this isn't a huge issue for objects that are roughly square from above, it makes oblong dimensions difficult to manage without switching to vPhysics. When vPhysics isn't an option there isn't much that can be done: a Day of Defeat: Source player who has gone prone has an oblong shape that can rotate through a full 360°, which Valve could only accommodate for by creating a 'squished' bounding box that leaves the head and feet sticking out at all times (an image of this would be nice).
Object-aligned
There is an amount of code in the SDK for object-aligned bounding boxes, which rotate with their entity. It is unclear how well these work, if indeed they work at all.
Defining
Source will automatically create bounding boxes. But if you need to tweak the results:
- Modellers use the $bbox QC command.
- Programmers call
UTIL_SetSize()
, which assumesSetSolid( SOLID_BBOX )
.
Uses
- qPhysics collision detection (mainly NPCs and players)
- Tracer collision detection
- Line-of-sight checks
- Todo: Current PVS?
See Also
- Anatomy of a Model
- Surrounding Bounds section CollisionProperty article.
- The BoundingBox Constructor is a method for defining cuboid vertices. By specifying only the "min" and "max" 3D coordinates - representing two diagonally opposed corners of the box relative to a point origin - the other six vertices are implied. This method is used to define Axis Aligned bounding boxes, hitboxes, NPC Hulls and Player Hull in code, and is obviously a great deal simpler than listing SMD mesh triangles.
- Dimensions