This application relates to detecting collisions of virtual three-dimensional (3D) models.
A virtual 3D model (hereinafter, simply “3D model”) includes a virtual skeleton, comprised of virtual bones arranged in a hierarchical tree structure. Surrounding the bones are polygons, such as triangles, which represent the skin of the 3D model. Movement of the polygons is tied to the movement of the bones so that the 3D model approximates real-life movement when the bones are repositioned.
When a 3D model collides with another 3D model, the resulting collision may affect the position and shape of one or both models. That is, the models move and/or deform in approximately the same manner as corresponding real-life characters would in a real-life collision.
Like reference numerals in different figures indicate like elements.
The process described herein detects collisions between bounding volumes associated with a 3D model and bone of another 3D model. In this regard, a bounding volume is a 3D space that encompasses the bone or model. When a collision is detected, the process can stop and apply a collision response using information determined from the collided bounding volumes. Lower level testing (e.g., at the polygon level) beyond this point is optional and may be performed if the user wants a more accurate collision detection and response.
If more accurate detection is desired, then the process transforms only the vertices associated with the collided bone and performs polygon level collision testing with the other model's bounding volume. In this way it is not necessary to transform an entire model's vertices in response to collision.
The 3D data for model 10 also includes bone data. The bone data defines a rigid skeletal structure of model 10, which corresponds to the bones of a living being. The “bones” 13 of model 10 are Cartesian XYZ-space vectors in the 3D data (
The bones of model 10 may be linked together in a tree-like hierarchical structure, with “child” bones branching off from “parent” bones. Vertices of polygons 12 are associated with one or more bones such that motion of the vertices is tied to motion of the bones. The association is defined in the 3D data that makes up 3D model 10. A polygon deforms around a bone that the polygon is associated with much the same way that skin surrounding living bone deforms in response to an applied force, such as a collision. The bones may change location in response to force, but do not change shape.
The movement of 3D model 10 is defined by a sequence of frames, which constitute snapshots of the 3D model at intervals of time. Each frame contains information about the position of a bone in 3D space at a particular instant in time. This information includes the displacement of the start of the bone from the end of its parent bone, the orientation of the bone relative to the orientation of its parent bone, one or more scaling factors that define the scale of the bone in 3D space, and the time of the displacement, orientation and scaling. Displacement and scale are represented as 3D vectors (e.g., Cartesian XYZ-space vectors). Orientation may be represented by rotation data, such as rotation matrices, Euler angles, or unit magnitude quaternions.
Matrix transforms are generally used to change the position of a bone from frame to frame. Matrix transforms may also be used to change the positions of polygon vertices to correspond to changes in positions of the bones.
Movement and deformations of a 3D model in response to a collision are determined based on the mechanics of the bone structure controlling the model. For example, as the leg of a biped (human-like) model collides with a ball, the leg will generally move in response, as will the ball.
Referring to
Process 20 transforms (26) bones in duck 22 and ball 24 to reposition the two 3D models (e.g., for a collision). It is noted that inanimate objects, such as ball 24, may contain bones that provide structural support, even though their “real-life” counterparts would not contain real bones.
Process 20 obtains (28) a bounding volume for duck 22 and ball 24. In this embodiment, the bounding volume is a sphere that encompasses a maximum extended range of motion of a 3D model. For example, in the case of 3D model 10 (
Returning to the duck/ball example, process 20 determines (38) if the bounding volume of duck 22 intersects the bounding volume of ball 24. Intersection of the two bounding volumes is shown in
If process 20 determines (38) that the two bounding volumes intersect (i.e., process 20 detects a collision), process 20 obtains (42) bone bounding volumes for one or more bones of duck 22 and ball 24. As shown in
Bounding volumes for all of the bones of a 3D model may be obtained beforehand and stored in memory. Thus, obtaining (42) the bounding volume may simply require retrieving the appropriate bounding volume(s) from memory. Alternatively, bounding volumes for the bones may be determined “on-the-fly”, i.e., during run-time as process 20 executes.
For simple models, such as ball 24 (
Accordingly, process 20 obtains (42) a bone bounding volume of duck 22 and determines (52) if that bone bounding volume intersects (i.e., comes into contact with) the bounding volume of ball 24. If there is an intersection, process 20 proceeds. If not, process 20 returns, obtaining (42) a new bone bounding volume for duck 22 and determining (52) if the newly-obtained bone bounding volume intersects the bounding volume of ball 24. This is repeated until process 20 determines which bone bounding volume(s) of duck 22 intersect the bounding volume of ball 24, thus indicating a collision.
By using bone bounding volumes to detect a collision, process 20 provides an advantage over other collision detection techniques. That is, other such techniques test the polygons in a 3D model in order to detect a collision. Process 20 may only test bounding volumes, and not polygons, thereby reducing the amount of calculations required to detect, and simulate, a collision.
Once process 20 determines which bone bounding volume(s) of duck 22 intersect the bounding volume of ball 24, process 20 transforms (53) bones (i.e., applies a collision response) in response to the collision and transforms (54) polygon vertices to coincide with the bone transformation performed earlier. These transformations are performed in accordance with associated vertex weights in order to reposition the polygons (“skin”) to correspond to the new positions of the bones. Although shown in
Process 20 scales well because it is possible to determine the collision response solely from the intersection of the bone bounding volumes, rather than going to the polygon (e.g., triangle) level. That is, the polygons need not be tested. Polygons may, however, be tested, if a user wants the increased accuracy that may result from lower-level testing.
For example, process 20 may identify polygons in the bone bounding volume(s) that intersect the bounding volume of ball 24. This may be done by comparing coordinates of vertices of polygons in the bounding volume to the coordinates of the bounding volume of ball 24. A comparison of some, or all, of the polygons in the bounding volume(s) that intersect may be performed. As noted, testing at the polygon level is not necessary, a collision may be detected, and the collision response applied, solely using bounding volumes.
Process 20 applies a collision response only to the polygons that intersect the bounding volume of ball 24. This collision response may include transforming vertices of, and/or normal vectors to, the affected polygons to achieve movement of those polygons in response to the collision. The transformation simulates movement resulting from a collision. For example, leg 60 (
Using process 20, it is possible to transform only the vertices associated with the collided bone and perform polygon level collision testing with the other model's bounding volume. In this way, the process need never transform an entire model's vertices during collision detection.
On the other hand, process 20 may also identify which polygons in the bounding volume of ball 24 intersect the bounding volume(s) of duck 22. This may be done in order to apply a collision response to the ball. These processes are identical to those above. So, for example, ball 24 may bounce off of leg 60 (e.g., direction 66—
Process 20, however, is not limited to use with the hardware and software of
Each such program may be implemented in a high level procedural or object-oriented programming language to communicate with a computer system. However, the programs can be implemented in assembly or machine language. The language may be a compiled or an interpreted language.
Each computer program may be stored on an article of manufacture, such as a storage medium (e.g., CD-ROM, hard disk, or magnetic diskette) or device (e.g., computer peripheral), that is readable by a general or special purpose programmable computer for configuring and operating the computer when the storage medium or device is read by the computer to perform process 20. Process 20 may also be implemented as a machine-readable storage medium, configured with a computer program, where, upon execution, instructions in the computer program cause a machine to operate in accordance with process 20.
Process 20 scales well because it is possible to determine the collision response solely from the intersection of the bounding volumes, rather than going to the polygon (e.g., triangle) level. That is, the polygons need not be tested. Although less accurate, scaling process 20 in this manner makes process 20 more usable on less-powerful computers and faster for those requiring less accurate results.
Other embodiments not described herein are also within the scope of the following claims. For example, the blocks of
Number | Name | Date | Kind |
---|---|---|---|
4600919 | Stern | Jul 1986 | A |
4747052 | Hishinuma et al. | May 1988 | A |
4835712 | Drebin et al. | May 1989 | A |
4855934 | Robinson | Aug 1989 | A |
4901064 | Deering | Feb 1990 | A |
5124914 | Grangeat | Jun 1992 | A |
5163126 | Einkauf et al. | Nov 1992 | A |
5371778 | Yanof et al. | Dec 1994 | A |
5611030 | Stokes | Mar 1997 | A |
5731819 | Gagne et al. | Mar 1998 | A |
5757321 | Billyard | May 1998 | A |
5786822 | Sakaibara | Jul 1998 | A |
5805782 | Foran | Sep 1998 | A |
5809219 | Pearce et al. | Sep 1998 | A |
5812141 | Kamen et al. | Sep 1998 | A |
5847712 | Salesin et al. | Dec 1998 | A |
5894308 | Isaacs | Apr 1999 | A |
5929860 | Hoppe | Jul 1999 | A |
5933148 | Oka et al. | Aug 1999 | A |
5949969 | Suzuoki et al. | Sep 1999 | A |
5966133 | Hoppe | Oct 1999 | A |
5966134 | Arias | Oct 1999 | A |
5974423 | Margolin | Oct 1999 | A |
6054999 | Strandberg | Apr 2000 | A |
6057859 | Handelman et al. | May 2000 | A |
6078331 | Pulli et al. | Jun 2000 | A |
6115050 | Landau et al. | Sep 2000 | A |
6175655 | George et al. | Jan 2001 | B1 |
6191787 | Lu et al. | Feb 2001 | B1 |
6191796 | Tarr | Feb 2001 | B1 |
6198486 | Junkins et al. | Mar 2001 | B1 |
6208347 | Migdal et al. | Mar 2001 | B1 |
6219070 | Baker et al. | Apr 2001 | B1 |
6201549 | Bronskill | May 2001 | B1 |
6239808 | Kirk et al. | May 2001 | B1 |
6252608 | Snyder et al. | Jun 2001 | B1 |
6262737 | Li et al. | Jul 2001 | B1 |
6262739 | Migdal et al. | Jul 2001 | B1 |
6292192 | Moreton | Sep 2001 | B1 |
6317125 | Persson | Nov 2001 | B1 |
6337880 | Cornog et al. | Jan 2002 | B1 |
6388670 | Naka et al. | May 2002 | B1 |
6405071 | Analoui | Jun 2002 | B1 |
6437782 | Pieragostini et al. | Aug 2002 | B1 |
6478680 | Yoshioka et al. | Nov 2002 | B1 |
6559848 | O'Rourke | May 2003 | B1 |
6593924 | Lake et al. | Jul 2003 | B1 |
6593927 | Horowitz et al. | Jul 2003 | B1 |
6608627 | Marshall et al. | Aug 2003 | B1 |
6608628 | Ross et al. | Aug 2003 | B1 |
6747651 | Tan et al. | Jun 2004 | B1 |
20010026278 | Arai et al. | Oct 2001 | A1 |
20020101421 | Pallister | Aug 2002 | A1 |
Number | Date | Country | |
---|---|---|---|
20030184603 A1 | Oct 2003 | US |