[x3d-public] candidate feature: display bounding box; collision rules

[Don Brutzman]

On 1/21/2020 9:39 AM, John Carlson wrote:
> Is the bounding box what is collides against or the visible shape?

Definitely a FAQ, thanks for asking.  References of interest:

----

* X3D Architecture, 10.2.2 Bounding boxes
   https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/group.html#BoundingBoxes

> Several node types include a bounding box specification comprised of two fields, bboxSize and bboxCenter. A bounding box is a rectangular parallelepiped of dimension bboxSize centred on the location bboxCenter in the local coordinate system. This is typically used by grouping nodes to provide a hint to the browser on the group's approximate size for culling optimizations. The default size for bounding boxes (−1, −1, −1) indicates that the user did not specify the bounding box and the effect shall be as if the bounding box were infinitely large. A bboxSize value of (0, 0, 0) is valid and represents a point in space (i.e., an infinitely small box). Specified bboxSize field values shall be ≥ 0.0 or equal to (−1, −1, −1). The bboxCenter fields specify a position offset from the local coordinate system.
> 
> The bboxCenter and bboxSize fields may be used to specify a maximum possible bounding box for the objects inside a grouping node (EXAMPLE  Transform). These are used as hints to optimize certain operations such as determining whether or not the group needs to be drawn. The bounding box shall be large enough at all times to enclose the union of the group's children's bounding boxes; it shall not include any transformations performed by the group itself (i.e., the bounding box is defined in the local coordinate system of the children). Results are undefined if the specified bounding box is smaller than the true bounding box of the group.
----

* 10.3.1 X3DBoundedObject
   https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/group.html#X3DBoundedObject

> X3DBoundedObject { 
>   SFVec3f [] bboxCenter 0 0 0    (-∞,∞)
>   SFVec3f [] bboxSize   -1 -1 -1 [0,∞) or −1 −1 −1
> }
> 
> This abstract node type is the basis for all node types that have bounds specified as part of the definition.
> 
> The bboxCenter and bboxSize fields specify a bounding box that encloses the grouping node's children. This is a hint that may be used for optimization purposes. The results are undefined if the specified bounding box is smaller than the actual bounding box of the children at any time. A default bboxSize value, (-1, -1, -1), implies that the bounding box is not specified and, if needed, is calculated by the browser. A description of the bboxCenter and bboxSize fields is contained in 10.2.2 Bounding boxes.

----

* X3D Tooltips, Anchor, bounding box
   https://www.web3d.org/x3d/content/X3dTooltips.html#Anchor.bboxSize

> [bboxSize accessType initializeOnly, type SFVec3f CDATA "-1 -1 -1"]
> Bounding box size is usually omitted, and can easily be calculated automatically by an X3D player at scene-loading time with minimal computational cost. Bounding box size can also be defined as an optional authoring hint that suggests an optimization or constraint.
> Hint: can be useful for collision computations or inverse-kinematics (IK) engines.
> Hint: precomputation and inclusion of bounding box information can speed up the initialization of large detailed models, with a corresponding cost of increased file size.

----

For collision, there are two types.  Primary is camera-to-object which is controlled by NavigationInfo/avatarSize and Collision.  Secondary is object-to-object collision which is much more involved, sometimes with Rigid body physics component, DIS component or custom  prototypes.

* 23.4.4 NavigationInfo
   https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/navigation.html#NavigationInfo

[...]
> The avatarSize field specifies the user's physical dimensions in the world for the purpose of collision detection and terrain following. It is a multi-value field allowing several dimensions to be specified. The first value shall be the allowable distance between the user's position and any collision geometry (as specified by a Collision node ) before a collision is detected. The second shall be the height above the terrain at which the browser shall maintain the viewer. The third shall be the height of the tallest object over which the viewer can move. This allows staircases to be built with dimensions that can be ascended by viewers in all browsers. The transformation hierarchy of the currently bound Viewpoint node scales the avatarSize. Translations and rotations have no effect on avatarSize.
> [...]
> The speed, avatarSize and visibilityLimit values are all scaled by the transformation being applied to the currently bound X3DViewpointNode node.

----

* 23.4.2 Collision
   https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/navigation.html#Collision

> The Collision node is a grouping node that specifies the collision detection properties for its children (and their descendants), specifies surrogate objects that replace its children during collision detection, and sends events signalling that a collision has occurred between the avatar and the Collision node's geometry or surrogate. By default, all geometric nodes in the scene are collidable with the viewer except IndexedLineSet and PointSet. Browsers shall detect geometric collisions between the avatar (see 23.3.4 NavigationInfo) and the scene's geometry and prevent the avatar from "entering" the geometry. See 23.2.4 Collision detection and terrain following for general information on collision detection.
> 
> If there are no Collision nodes specified in a X3D file, browsers shall detect collisions between the avatar and all objects during navigation.

and

> The collision proxy, defined in the /proxy/ field, is any legal children node as described in 10.2.1 Grouping and children node types that is used as a substitute for the Collision node's children during collision detection. The proxy is used strictly for collision detection; it is not drawn.

all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman