JP5629704B2 - Physics simulation on graphics processor - Google Patents

Description

  The present invention is generally directed to a graphics processing device, and more specifically to performing a physical simulation of a game using a graphics processor.

  Applications such as video games running on computer systems may require both physics simulation and graphics rendering. For example, FIG. 1 illustrates a block diagram 100 of an exemplary pipeline for computing and displaying the motion of one or more characters drawn in a video game scene. In step 110, a physical simulation is performed to determine the motion of one or more characters drawn in the scene. Then, in step 120, the result of the physics simulation is rendered as a graphic for visualization by the end user.

  In general, the physics simulation of step 110 is performed by a physics engine that runs on a central processing unit (CPU) or a dedicated device of the computer system. The graphics rendering of step 120 is then performed by a graphics processing unit (GPU). Eventually, however, the results provided by the physics engine will be used to modify the graphics of the video game (or more generally the application) and thus in some form communicate to the GPU. Will be. Since results from the physics engine must be communicated to the GPU for rendering, latency and bandwidth problems can occur. Furthermore, unlike a general processing unit, the CPU does not have the parallel processing capability of the GPU.

  In view of the above, what is needed is a method, computer program product, and system for performing physical simulation on one or more GPUs.

  Embodiments of the present invention can include methods, computer program products, and systems, by utilizing the parallel processing capabilities available on the GPU, as compared to physical simulations executed on a general CPU, Allows for faster frame rates. In addition, such methods, computer program products, and systems prevent the relatively small time steps required in explicit integration techniques by utilizing implicit integration techniques in performing physical simulations. To do. Further, procedural forces and torques can be represented as shader programs executing on the GPU. In addition, GPU-based physics simulators may be able to automatically replace conventional software dynamics solvers, which typically perform physics simulations on computer systems. Embodiments of the present invention meet the needs identified above by providing methods, computer program products, and systems for performing physical simulations on one or more GPUs. Such methods, computer program products, and systems for performing physics simulations on one or more GPUs are executed on a regular CPU by utilizing the parallel processing capabilities available on the GPU. Allows higher frame rates compared to physics simulations. In addition, such methods, computer program products, and systems perform physical simulations by utilizing implicit integration techniques in the embodiments, thereby providing the relative required of explicit integration techniques. Prevent small time steps. Further, according to embodiments of the present invention, procedural forces and / or torques can be represented as shader programs executing on the GPU. In addition, GPU-based physics simulators according to embodiments of the present invention can be used to automatically replace conventional software dynamics solvers that typically perform physics simulations on computer systems.

  According to an embodiment of the invention, a method is provided for performing a physical simulation on at least one GPU. The method includes the following steps. First, data representing physical attributes associated with at least one mesh is stored in a plurality of video memory arrays to establish a system of linear equations that govern the motion of at least one mesh depicted in the scene. Next, a linear equation system with respect to time is solved by performing operations on data in a plurality of video memory arrays using at least one pixel processor. Here, the corrected data representing the solution to the linear equation system with respect to time is stored in a plurality of video data memories.

  In accordance with another embodiment of the present invention, a computer program product is provided, the computer program product comprising a computer usable medium having control logic stored therein and causing at least one GPU to perform a physical simulation. The control logic includes computer readable first and second program code. The first computer readable program code stores data representing physical attributes associated with at least one mesh in at least one GPU, in a plurality of video data arrays, and thereby for at least one mesh depicted in the scene. Set up a linear equation system that governs motion. The second computer readable program code solves a system of linear equations for time by causing at least one GPU to perform operations on data in a plurality of video memory arrays. Here, the corrected data representing the solution to the linear equation system with respect to time is stored in a plurality of video data memories.

  According to a further embodiment of the invention, a system for performing physics simulations is provided. The system includes a memory that stores a plurality of video memory arrays and at least one pixel processor coupled to the memory. The plurality of video memory arrays sets up a linear equation system that governs the motion of at least one mesh depicted in the scene by storing data representing physical parameters associated with the at least one mesh. At least one pixel processor solves the linear equation system for time by performing operations on data in the plurality of video memory arrays, resulting in modified data representing a solution for the linear equation system for time.

  Further features and utilities of the present invention, as well as the structure and operation of various embodiments of the present invention, are described in detail below with reference to the accompanying drawings. It should be noted that the present invention is not limited to the specific embodiments described herein. Such embodiments are presented herein for illustrative purposes only. Additional embodiments will be apparent to those skilled in the art based on the teachings contained herein.

The accompanying drawings are embodied in and constitute a part of this specification, illustrate the invention, and together with the description, serve to explain the principles of the invention and enable those skilled in the art to understand the invention. Allows you to create and use.
For example, the present invention provides the following.
(Item 1)
A method of performing a physical simulation on at least one graphics processor unit (GPU), the method comprising:
Setting a system of linear equations governing the motion of the at least one mesh depicted in the scene by mapping physical parameters associated with the at least one mesh to a plurality of memory arrays;
Solving a system of linear equations for a time by performing operations on data in the plurality of memory arrays using at least one pixel processor;
Including
The modified data representing the solution of the system of linear equations for the time is stored in the plurality of memory arrays.
(Item 2)
The method of claim 1, further comprising updating the motion of the one or more meshes depicted in the scene relative to the time based on the changed data in the plurality of memory arrays.
(Item 3)
Identifying at least one collision comprising the at least one mesh for the time;
The motion of the at least one mesh depicted in the scene relative to the time based on (i) the modified data in the plurality of memory arrays, and (ii) the identified at least one collision. And to update
The method according to Item 1, further comprising:
(Item 4)
Solving the linear equation system for the next time by performing operations on the changed data using the pixel processor, the modified data representing a solution for the linear equation system for the next time is: The method of item 1, stored in the plurality of memory arrays.
(Item 5)
5. The method of item 4, further comprising updating at least one mesh motion depicted in the scene for the next time based on the further modified data in the plurality of memory arrays.
(Item 6)
Identifying at least one collision comprising the at least one mesh for the next time;
The at least one mesh depicted in the scene for the next time based on (i) the modified data in the plurality of memory arrays, and (ii) the identified at least one collision. With renewing exercise
The method according to Item 4, further comprising:
(Item 7)
Performing an operation
Solving the system of linear equations for a time by implicitly integrating the system of linear equations by performing operations on data in the plurality of memory arrays using at least one pixel processor;
The method of item 1, wherein the modified data representing the solution of the system of linear equations for the time is stored in the plurality of memory arrays.
(Item 8)
The above storage is
Including setting up a linear equation system by storing data in a plurality of memory arrays, the linear equation system comprising:

Dominates the motion of at least one mesh given by and depicted in the scene, where

I is an identity matrix, M is an orthogonal matrix of the mass of the at least one mesh,

Is a vector representing the geometric state of the at least one mesh at t _k ;

Is a vector representing the velocity of each point in the at least one mesh at t _k ;

The method according to item 1, wherein is a vector representing a net force on each point of the at least one mesh at t _k .
(Item 9)
Prior to mapping, the method further includes
Capturing a scene from a software dynamics solver and converting attributes and fields attached to at least one mesh depicted in the scene into physical parameters mapped to the plurality of memory arrays;
Importing simulation results into the scene graph of the software dynamics solver;
Further including
The method of item 1, wherein the simulation result corresponds to a solution for the system of linear equations for the time calculated by the at least one pixel processor.
(Item 10)
The method of claim 1, further comprising representing a force acting on the mesh depicted in the scene as a shader executing on the at least one GPU.
(Item 11)
A computer program product comprising a computer usable medium having stored therein control logic and causing at least one graphics processor unit (GPU) to perform a physical simulation, the control logic comprising:
First computer readable program code, the code being mapped into a plurality of memory arrays by causing the at least one GPU to map physical parameters associated with at least one mesh to a plurality of memory arrays. First computer readable program code for setting a system of linear equations governing the motion of two meshes;
Computer readable second program code, the computer readable code for solving a system of linear equations at a time by causing the at least one GPU to perform operations on data in the plurality of memory arrays Second program code and
With
A computer program product, wherein modified data representing a solution to a system of linear equations for the time is stored in the plurality of memory arrays.
(Item 12)
Computer readable third program code, wherein the code is based on the modified data in the plurality of memory arrays, the at least one GPU having the at least one depicted in the scene for the time Item 12. The computer program product of item 11, further comprising computer readable third program code for updating the motion of one mesh.
(Item 13)
Computer readable third program code, the computer readable third program code for causing the at least one GPU to identify at least one collision including the at least one mesh at the time;
Computer readable fourth program code, the code based on (i) the modified data in the plurality of memory arrays and (ii) the identified at least one collision. Item 12. The computer program product of item 11, further comprising computer readable fourth program code that causes one GPU to update the motion of the at least one mesh depicted in the scene relative to the time.
(Item 14)
Computer readable third program code, which causes the at least one GPU to perform an operation on the changed data to solve a linear equation system for a next time; Further including program code,
12. The computer program product of item 11, wherein further modified data representing a solution to the linear equation system for the next time is stored in the plurality of memory arrays.
(Item 15)
Computer readable fourth program code, wherein the code is depicted in the scene for the next time on the at least one GPU based on the further modified data in the plurality of memory arrays. 15. The computer program product of item 14, further comprising computer readable fourth program code that causes the movement of the at least one mesh to be updated.
(Item 16)
Computer readable fourth program code, the computer readable fourth program code for causing the at least one GPU to identify at least one collision including the at least one mesh for the next time; ,
Computer-readable fifth program code, the code comprising: (i) the further modified data in the plurality of memory arrays; and (ii) the at least the computer-readable fourth program code identified Computer-readable fifth program code that, based on one collision, causes the at least one GPU to update the movement of the at least one mesh depicted in the scene relative to the next time;
The computer program product of item 14, further comprising:
(Item 17)
The computer readable second program code is:
Code to cause the at least one GPU to perform operations on the data in the plurality of memory arrays, thereby implicitly integrating the system of linear equations to Including the code to solve,
12. The computer program product of item 11, wherein modified data representing a solution to a system of linear equations for the time is stored in the plurality of memory arrays.
(Item 18)
The computer readable first program code is:
Code comprising: setting a linear equation system by causing the at least one GPU to store data in a plurality of memory arrays, the linear equation system comprising:

Governs the motion of the at least one mesh given by and depicted in the scene, where

Where I is an identity matrix, M is an orthogonal matrix of the mass of the at least one mesh,

Is a vector representing the geometric state of the at least one mesh at t _k ;

Is a vector representing the velocity of each point in the at least one mesh at t _k ;

Item 12. The computer program product of item 11, wherein is a vector representing a net force on each point in the at least one mesh at time t _k .
(Item 19)
Computer readable third program code, which causes the at least one GPU to capture a scene from a software dynamics solver, and includes attributes and fields attached to the at least one mesh depicted in the scene; A third computer readable program code for converting to the physical parameter mapped to the plurality of memory arrays;
Computer readable fourth program code, the computer readable fourth program code for causing the at least one GPU to import simulation results into a scene graph of the software dynamics solver;
Further comprising
12. The computer program product according to item 11, wherein the simulation result corresponds to a solution to the linear equation system with respect to the time.
(Item 20)
Item 12. The computer program product of item 11, further comprising computer readable third program code that causes the at least one GPU to simulate forces acting on the mesh depicted in the scene.
(Item 21)
A system for performing a physical simulation, the system comprising:
A memory, comprising a plurality of memory arrays storing data representing physical parameters associated with at least one mesh, for setting up a system of linear equations governing the motion of the at least one mesh depicted in the scene , Memory,
At least one pixel processor coupled to the memory for solving the system of linear equations for a time by performing operations on the data in the plurality of memory arrays;
With
The modified data representing the solution of the linear equation system for the time is stored in the plurality of memory arrays.
(Item 22)
Item 21. The rendering engine further comprising a rendering engine that updates a depiction of the at least one mesh depicted in the scene relative to the time based on the changed data in the plurality of memory arrays. The system described.
(Item 23)
The pixel processor identifies at least one collision comprising the at least one mesh for the time;
A rendering engine comprising: (i) the modified data in the plurality of memory arrays; and (ii) the at least one collision identified at the time and depicted in the scene for the time 24. The system of item 21, further comprising a rendering engine that updates the representation of at least one mesh.
(Item 24)
The pixel processor operates on the modified data to solve a linear equation system for a next time, and further modified data representing a solution for the linear equation system for the next time includes the plurality of data The system of item 21, stored in a memory array.
(Item 25)
A rendering engine, further comprising a rendering engine that updates a depiction of the at least one mesh depicted in the scene for the next time based on the further modified data in the plurality of memory arrays. 25. The system according to item 24.
(Item 26)
The pixel processor identifies at least one collision comprising the at least one mesh for the next time;
A rendering engine in the scene for the next time based on (i) the modified data in the plurality of memory arrays, and (ii) the at least one collision identified at the next time 25. The system of item 24, further comprising a rendering engine that updates the rendering of the at least one mesh being rendered.
(Item 27)
The pixel processor solves the linear equation system for a time by implicitly integrating the linear equation system by performing an operation on the data in the plurality of memory arrays, and for the linear equation system for the time. 22. The system of item 21, wherein the modified data representing the solution is stored in the plurality of memory arrays.
(Item 28)
The system of linear equations is

Where given by

I is an identity matrix, M is an orthogonal matrix of the masses of the at least one mesh,

Is a vector representing the geometric state of the at least one mesh at t _k ;

Is a vector representing the velocity of each point in the at least one mesh at t _k ;

The system of item 21, wherein is a vector representing the net force on each point in the at least one mesh at time t _k .
(Item 29)
A scene exporter that captures a scene from a software dynamics solver and converts attributes and fields attached to at least one mesh depicted in the scene into the physical parameters stored in the plurality of memory arrays , With scene exporter,
A scene importer that imports simulation results into the scene graph of the software dynamics solver;
Further comprising
22. The system of item 21, wherein the simulation result corresponds to the solution to the linear equation system for the time calculated by the at least one pixel processor.
(Item 30)
22. The system of item 21, further comprising a shader that executes to represent the force acting on the mesh depicted in the scene on at least one GPU.
(Item 31)
A method for performing a physical simulation on at least one graphics processor unit (GPU), the method comprising:
Sending simulation definition data to the at least one GPU;
Receiving simulation results from the at least one GPU in response to the transferred simulation definition;
Including the method.
(Item 32)
Transferring simulation definition data to the at least one GPU includes transmitting at least one of scene data, simulation data, actor data, joint data, and feedback data to the at least one GPU; 32. A method according to item 31.
(Item 33)
32. A method according to item 31, wherein the transmission includes transmitting simulation definition data in a markup language format to the at least one GPU.
(Item 34)
A method for performing a physical simulation on at least one graphics processor unit (GPU), the method comprising:
Converting simulation definition data into application programming interface (API) commands;
Generating simulation result data by performing a physical simulation on the at least one GPU in response to the converted simulation definition data;
Including the method.
(Item 35)
35. A method according to item 34, wherein the converting includes generating a scene data structure from the simulation definition data.
(Item 36)
Performing the above physical simulation
Setting a linear equation system corresponding to the simulation definition data;
Solving the system of linear equations;
Detecting a collision based on a solution to the system of linear equations;
35. A method according to item 34, comprising:
(Item 37)
A computer-based method for performing a physics simulation, the method comprising:
Converting software dynamics solver data into simulation definition data for at least one graphics processor unit (GPU);
Generating simulation result data by performing a physical simulation on the at least one GPU in response to the transformed data;
Including the method.
(Item 38)
38. A method according to item 37, further comprising transmitting the simulation result data to an application.
(Item 39)
39. A method according to item 38, wherein the transmitting includes converting the simulation result data into a format of the software dynamics solver.
(Item 40)
38. The method of item 37, further comprising performing another physics simulation based on the software dynamics solver in response to the additional software dynamics solver data.
(Item 41)
A computer readable medium comprising instructions for generating at least one graphics processor unit (GPU), wherein the instructions, when executed, are adapted to create the at least one GPU, the at least one One GPU is
Setting a system of linear equations governing the motion of the at least one mesh depicted in the scene by mapping physical parameters associated with the at least one mesh to a plurality of memory arrays;
Solve a system of linear equations for a time by operating on data in the plurality of memory arrays using at least one pixel processor
A modified computer-readable medium wherein modified data representing solutions for the system of linear equations for the time is stored in the plurality of memory arrays.
(Item 42)
A computer readable medium comprising instructions for generating at least one graphics processor unit (GPU), wherein the instructions, when executed, are adapted to create the at least one GPU, the at least one One GPU is
Sending simulation definition data to the at least one GPU;
Receive simulation results from the at least one GPU in response to the transmitted simulation definition data
A computer readable medium adapted to
(Item 43)
A computer readable medium comprising instructions for generating at least one graphics processor unit (GPU), wherein the instructions, when executed, are adapted to create the at least one GPU, the at least one One GPU is
Converting software dynamics solver data into simulation definition data for the at least one GPU;
In response to the transformed data, simulation result data is generated by performing a physical simulation on the at least one GPU.
A computer readable medium adapted to

FIG. 1 illustrates a block diagram illustrating a general graphics pipeline. FIG. 2 illustrates a block diagram of an exemplary workflow for performing a physics simulation on a GPU according to an embodiment of the present invention. FIG. 3 illustrates a block diagram of an exemplary pixel processor according to an embodiment of the present invention. FIG. 4 shows a block diagram of an exemplary physics / rendering pipeline in accordance with an embodiment of the present invention. FIG. 5 illustrates a block diagram of an exemplary physics simulation pipeline performed on a GPU according to an embodiment of the present invention. FIG. 6 illustrates a block diagram of an exemplary workflow that bypasses the software dynamics solver and thereby performs physical simulation on the GPU, according to an embodiment of the present invention. FIG. 7 illustrates a block diagram illustrating an exemplary method for performing a physics simulation on a GPU according to an embodiment of the present invention. FIG. 8 illustrates an exemplary point mesh for modeling a cloth according to an embodiment of the present invention. FIG. 9 illustrates an exemplary high level flow diagram for simulating physics on a GPU, in accordance with an embodiment of the present invention. FIG. 10 illustrates an exemplary two-step flow diagram for mapping physical parameters associated with a point mesh to video memory, in accordance with an embodiment of the present invention. FIG. 11 illustrates an exemplary flow diagram for determining the net force and non-diagonal portions of the Jacob matrix for each joint, in accordance with an embodiment of the present invention. FIG. 12 illustrates an exemplary flow chart for determining the diagonal portion of the Jacob matrix for each joint, in accordance with an embodiment of the present invention. FIG. 13 illustrates a block diagram of an exemplary computer system in which embodiments of the present invention may be implemented. FIG. 14A illustrates an exemplary method in which the contents of the vertex buffer are mapped onto a 3 × 3 component array, in accordance with an embodiment of the present invention. FIG. 14B illustrates an exemplary method in which the contents of the index buffer are mapped onto a 3 × 2 grid, according to an embodiment of the present invention. FIG. 15A illustrates an example where the vertex buffer stores eight vertex positions. FIG. 15B illustrates an example where the index buffer stores five faces corresponding to the vertex positions stored in the exemplary vertex buffer illustrated in FIG. 15A.

  The functionality and utility of the present invention will become more apparent from the detailed description set forth below when taken in conjunction with the drawings. In the drawings, like reference characters consistently identify corresponding elements. In the drawings, like reference numbers generally indicate identical, functionally similar, and / or structurally similar elements. The drawing in which an element first appears is indicated by the leftmost digit (s) in the corresponding reference number.

I. Overview of physics simulation on one or more GPUs Exemplary workflow for performing physics simulations on one or more GPUs Exemplary GPU to perform physics simulation
II. Exemplary Physical Simulation Interface A. Exemplary physics simulation software interface (FYSI)
B. Exemplary physical scene description language (FYSL)
C. Exemplary Method by which Point Mesh-Related Physical Parameters may be Received III. Exemplary Method for Performing Physical Simulations on One or More GPUs A. Method Overview B. C. Exemplary physical model for cross simulation D. Exemplary implementation for simulating cloth on a GPU Example code written in FYSL IV. Exemplary Computer Implementation V. Conclusion I. Overview of physics simulation on one or more GPUs Embodiments of the present invention are directed to methods, computer program products, and systems for performing physics simulation on one or more GPUs. Such a physics simulation can be used, for example, to perform game calculations for an application (such as a video game). In order to perform physics simulations on one or more GPUs according to embodiments of the present invention, the physical parameters associated with the mesh are mapped directly into video memory. A mesh may represent any physical object such as a solid object, a volume, a fluid, or a cloth. Presented in detail here is an exemplary method for performing cross physics simulations on one or more GPUs. After the mesh is mapped to video memory, at least one pixel processor of the GPU operates on the data in the video memory using a compiled shader program. Performing physical simulations directly on the GPU may reduce latency and bandwidth problems associated with typical physical simulations performed on a CPU.

  Throughout the specification, methods, computer program products, and systems for performing physics simulations on one or more GPUs include an exemplary physics simulation software interface (referred to as FYSI) and a physical scene description language (referred to as FYSL). Described from the point. However, the present invention is not limited to FYSI and FYSL. Based on this description, methods, computer program products, and systems for performing physical simulations on one or more GPUs are implemented using other types of physical simulation software interfaces and other types of physical scene description languages. Those skilled in the art will appreciate that this can be done.

  References to “one embodiment”, “one embodiment”, “exemplary embodiment”, etc. in the specification indicate that the described embodiments can include specific functions, structures, or characteristics. It should be noted, however, that all embodiments may not necessarily include specific functions, structures or characteristics. Moreover, such phrases are not necessarily referring to the same embodiment. Also, when a particular function, structure, or characteristic is described in connection with one embodiment, that function, structure, or characteristic acts in relation to the other embodiment, whether explicitly stated or not. Is presented to be within the knowledge of a person skilled in the art.

  Described in detail below are embodiments of the present invention for mapping physical simulations on one or more GPUs. In Section II, an exemplary interface for performing this mapping is described. Section III presents an exemplary method for performing physics simulations on one or more GPUs and includes a detailed implementation of an exemplary method for simulating cloth on a GPU. In Section IV, an exemplary computer system for implementing physics simulations on one or more GPUs is described. However, before elaborating embodiments of the present invention, it is useful to describe an exemplary workflow for performing physical simulations on one or more GPUs and an overview of exemplary GPUs for implementing physical simulations It is.

A. Exemplary Workflow for Performing Physical Simulation on One or More GPUs FIG. 2 illustrates a block diagram 200 of an exemplary workflow for performing physical simulation on a GPU. The block diagram 200 includes various software elements, such as an application 210, a physics simulation software interface 212, an application programming interface 214, and a driver 216, which are executed on a power computer system, such as a GPU 218, (optional) GPU 220, By interacting with graphics hardware elements such as and / or multiple GPUs (not shown), physical phenomena are simulated and frames for output to display 222 are rendered. Individual elements of block diagram 200 will now be described in greater detail.

  As shown in FIG. 2, the block diagram 200 includes an application 210. Application 210 is an end user application and requires graphics processing capabilities such as a video game application. The application 210 calls the physics simulation software interface 212. In the embodiment, the physics simulation software interface 212 is an interface called FYSI developed by ATI Technologies Inc. FYSI is described in more detail here. However, as described above, the present invention is not limited to FYSI. Other physics simulation software interfaces can also be used without departing from the spirit and scope of the present invention, as will be apparent to those skilled in the art. The physics simulation software interface 212 creates a simple and extensible abstract machine (SEAM) on which physics simulation is performed.

  The physics simulation software interface 212 communicates with the API 212. Several APIs are available for use in the graphics processing context. The API was developed as an intermediary between application software such as application 210 and the graphics hardware on which the application software operates. As new chipsets and entirely new hardware technologies emerge with increasing momentum, it is difficult for application developers to take into account and take advantage of the latest hardware features. Also, writing applications specifically for each foreseeable set of hardware is becoming increasingly difficult. The API prevents the application from being too hardware specific. The application can output graphics data and commands to the API in a standardized format rather than directly to the hardware. Since the physics simulation software interface 212 communicates directly with the API 214, there is no need to modify the available API. Examples of available APIs include DirectX (R) or OpenGL (R). The API 210 can be any of the available APIs that run a graphics application. As will be appreciated by those skilled in the art, alternative embodiments of the present invention may aggregate the physics simulation software interface 212 into the API 214 and thus operate the application 210 using a single software interface. obtain. In such embodiments, driver 216 may then be modified to respond to a single interface that incorporates aspects of physics simulation software interface 212 with API 214.

  API 210 communicates with driver 216. The driver 216 is typically written by the graphics hardware manufacturer and translates standard code received from the API into a native format understood by the graphics hardware. Driver 216 also receives input to direct performance settings to the graphics hardware. Such input may be provided by a user, application or process. For example, a user may provide input using a user interface (UI) such as a graphical user interface (GUI), which is provided to the user along with a driver 216.

  The driver 216 communicates with the first GPU 218 and / or the second GPU 220. The first GPU 218 and the second GPU 220 are graphics chips, each including a shader and other related hardware that performs physics simulation and graphics rendering. In one embodiment, physics simulation and graphics rendering are performed on a single GPU, such as the first GPU 218. In an alternative embodiment, the physics simulation is performed on one GPU (or core), such as the first GPU 218, and the graphics are rendered on another GPU (or core), such as the second GPU 210. In further embodiments, physics simulation and graphics rendering are performed by multiple GPUs. After the physics simulation, the rendered graphic is sent to the display unit 222 for display. GPU 218 and GPU 220 may each be implemented as described in the next section.

B. Exemplary GPU for performing physics simulations
The GPU architecture according to embodiments of the present invention enables single instruction multiple data (SIMD) technology, resulting in data level parallelism. Such GPUs include a processor and texture (or video memory). The processor performs an operation based on the data in the texture. The result of the operation is written to the render target (part of the video memory). Render targets can be reassigned as textures or subsequent operations. Textures are arranged in an array of memory, such as a 1D-, 2D-, 3D-array, etc. of memory. A shader is a small program or set of instructions written for a processor to perform a specific operation based on data in a texture.

  FIG. 3 illustrates a block diagram 300 illustrating an exemplary pixel processor for performing physics simulations on one or more GPUs in accordance with an embodiment of the present invention. Included in the block diagram 300 are six textures 310a-310f, eight constant storage registers 308a-308h, and one pixel processor 306. Texture coordinates 302 of a memory array (1D-, 2D-, 3D-memory array, etc.) may be written to the texture 310. In contrast, constant data values are stored in constant storage register 308. Pixel processor 306 performs operations based on data in texture 310 and / or constant storage register 308. After performing these operations, pixel processor 306 may write data to texture 310 and / or generate output 314. The operations performed by pixel processor 306 are specified by instructions similar to CPU assembly language instructions.

  We now describe an exemplary method by which a mesh is represented in a GPU vertex processor. The mesh consists of a pair of one-dimensional lists, a vertex buffer and an index buffer. As illustrated in FIG. 15A, the vertex buffer holds vertex positions. The embodiment shown in FIG. 15A illustrates seven vertex positions. FIG. 15A is used for illustrative purposes only and is not intended to be limiting. As will be apparent to those skilled in the art, different numbers of vertex positions may be stored in the vertex buffer. As illustrated in FIG. 15B, the index buffer stores the index of the surface. FIG. 15B is used for illustrative purposes only and is not intended to be limiting. As will be apparent to those skilled in the art, different numbers of surface indices may be stored in the index buffer. A surface represents a triangle, and the surface places a point in the vertex buffer. For example, a face stored in the index buffer may contain three vertices and is classified as 0, 1 and 2. Each of these classified vertices points to a separate location in the vertex buffer.

  Now, an exemplary method by which the mesh is mapped to video memory will be described. This exemplary method is presented for illustrative purposes only and not for limitation. Other methods for mapping the mesh to video memory will be apparent to those skilled in the art based on the description contained herein. Each list of vertices and indices is mapped to an optimized N-dimensional array in video memory to better utilize pixel engine parallelism. An optimized N-dimensional array is such that the optimized N-dimensional array matches the maximum addressability of the GPU used to perform the physical simulation. The vertex buffer maps onto an array of n × m elements, and the index buffer maps onto an l × k grid. Each element (eg, pixel) in the video memory consists of a four component vector. The first three components represent the x, y, and z components of the position, and the fourth component is a boundary tag (described below).

  In one embodiment, the list of vertices and indices are each mapped onto an optimized two-dimensional array in video memory, as shown in FIGS. 14A and 14B, respectively. In this embodiment, the vertex buffer maps on a 3 × 3 component array, and the index buffer maps on a 3 × 2 grid.

  In the case of multiple meshes in one scene, all the meshes are integrated into one two-dimensional composite mesh according to an embodiment of the present invention. The composite mesh records sub-mesh boundaries in video memory by tagging each sub-mesh with a unique identifier (“id”). The id is recorded as the fourth component of each grid element. Mesh compositing alleviates the overhead associated with downloading small size meshes to video memory, and reduces hardware resource pressure due to the total number of texture usage.

II. Exemplary Physics Simulation Interface As described above with respect to FIG. 2, physics simulation software interface 212 allows application 210 to perform physics simulations on GPU 218, GPU 220, and / or multiple GPUs. In this section, an exemplary physics simulation interface is described. First, an exemplary physics simulation software interface called FYSI is described. Subsequently, an exemplary scene description language called FYSL for describing a symbolic concept embodied in FYSI is described. Finally, an exemplary method is described that performs physical simulation on one or more GPUs using FYSI, thereby converting physical parameters and attributes to FYSL to avoid traditional software dynamic solvers. . However, it should be appreciated that these embodiments are presented for illustrative purposes only and not for limitation. Based on the description contained herein, one of ordinary skill in the art will understand how to implement other types of physical simulation software interfaces for performing physical simulations on one or more GPUs.

A. Exemplary physics simulation software interface (FYSI)
FYSI-an exemplary physics simulation software interface system is a vehicle for mapping conventional CPU-based simulation related operations on the GPU. By using FYSI, a higher interaction speed can be achieved than is commonly experienced in game physics. FYSI is a departure from the traditional closed query modality that maps collision detection and resolution on graphics hardware. Alternatively, FYSI proposes a global simulation solution that enhances the power of shading that can be programmed with an increasing number of hardware.

  FIG. 4 illustrates a block diagram 400 of the enhanced graphics pipeline whereby the physics simulation stage 410 feeds through the visual rendering stage 420. The physics simulation stage 410 incorporates a physical description symbolic concept. The description provides definitions for both simulation and scene. A scene consists of actors, each actor having its own set of shapes, dynamics, and material properties. The shape establishes the geometrical nature of the participating actors, the dynamics constitutes the physical behavior, and the substance has substance-related properties. In addition, the scene optionally declares a joint, thereby introducing a pair of actor motion constraints. The process of simulation is started by an iterative and separate uniform step, ie time pattern. The physical description symbol concept takes the form of a language called FYSL, which is an abbreviation for physical scene description language. FYSL is platform independent, scalable, and provides constructs to divide simulation tasks across multiple GPUs as needed.

  In the rendering block 420, the simulation results from the physical block 410 are rendered for visualization. In general, several physics simulation steps are performed for each rendering frame. Thus, the cumulative frame rate of both simulation and visual rendering tasks determines the final interactive rate for the user. FYSI is a software development environment for providing physical simulation requirements. First, the FYSL input symbolic concept is analyzed and converted into a set of internal scene data structures. The simulation is then started on the GPU. The simulation results can be advanced directly to the visual rendering thread using the shared texture, or optionally available to be read back by the programmer. Finally, FYSI implements a computational symbol concept layer (CAL) wrapper on top of the graphics hardware interface to facilitate extensibility. In one embodiment, FYSI interfaces with Microsoft DirectX® (versions 9.0 and 10.0), but those skilled in the art will know that FYSI interfaces with OpenGL® or some other API. Recognize that you can connect.

  The physics simulation field in the game is rather broad and covers a large number of topics. Among these are simulations of rigid bodies, cloths, fluids, and generally deformable bodies. The type of physics simulation indicates the format of the data transferred from the simulation stage onto the visual rendering stage. In the rigid case, FYSI goes to visual thread transformation data, which represents the incremental state change of the object entered in the most recent simulation session. The cloth model returns to the original perturbed particle position, and for fluids or deformable bodies, the resulting simulated shape is irrelevant to the initial shape. ing. Typically, the physics simulation process is CPU bound and the bandwidth requirements from the physics simulation process onto the visual rendering thread are relatively limited.

As shown in FIG. 5, at a relatively high level, the generic pipeline 500 is formed and can be applied to most of the aforementioned physical simulation aspects. Pipeline 500 includes a system setup stage 510, a solver stage 520, and a collision stage 530. In the system setup stage 510, the input is either an initial scene description or an incremental state update of the scene. The role of the system setup stage 510 is to integrate the physical models and arrive at a linear system of scheme A ^* x = b. Here, A is a matrix, x is an unknown number, and b is a known vector.

  In the solver stage 520, the linear system is solved and the scene state to be depicted is updated based on the solution for the linear system. Linear systems are solved by using numerical techniques available to the relevant artisan. In one embodiment, the linear system is a modified conjugate gradient method described in detail below, and “Large Steps in Cloth Simulation” by David Baraff and Andrew Witkin, Computer Graphics Processings, pp 43-54 (July 19-1998, 24th) (hereinafter referred to as “Baraff reference”), which is incorporated herein by reference in its entirety.

  In the collision stage 530, the updated model is tested for possible collisions. As a result of the calculated contact, the scene state is further modified. Collision detection is performed by checking whether the pair of points intersect. Collision detection techniques are well known to those skilled in the art. See, for example, page 50 of the Baraff reference.

  The physical pipeline 500 repeats its entire stage for each of the simulation stages. In general, actors in a scene are considered either individually or on a group basis. Individual actors, such as in the case of a rigid body, pass through the system setup stage 510 and solver stage 520 of the pipeline 500 and perform only the collision stage 530. Cloth, fluid and deformable entities are generally considered a collection of actors with a well-defined interaction model. Thus, in most cases, they are intended to execute all stages of the pipeline 500. An example of a cross passing through the physical pipeline 500 is described in Section III.

B. Exemplary physical scene description language (FYSL)
The input symbolic concept to the FYSI physics simulation interface library is represented in a customized scene description format called FYSL. FYSL is expressed in XML format and consists of five sections: scene, simulation, actors, joints, and feedback. Each of these FYSL sections includes a schema tag and an optional value assignment. Schema tags and optional value assignments are described below. A sample of the FYSL program is provided at the end of this measure.

  The first section of FYSL is a scene. In this section, the scene to be depicted is defined. Exemplary global scene tags are presented in Table 1.

The second section of FYSL is a simulation. The simulation process in FYSI is individual and begins in steps. FYSL simulation characteristics include type and time interval between simulation steps.

  In addition, a global field representing the forces acting on all scene actors in the same way can optionally be added to the simulation definition. In this embodiment, FYSL provides three types of force field tags: a drag field, a direction field, and a procedure field. The drag field is a vector of three scalar values (one for each dimension) that exerts a braking force based on the actor's linear velocity. The directional field is a constant, single component force throughout the simulation that acts in the direction specified by the vector. An exemplary directional field is gravity. A procedural field represents a more complex field that can vary in both time and space. The string attached to the procedure field is a function that is further translated into the code of the shader program that runs on the GPU.

  Exemplary simulation tags are shown in Table 2, and exemplary field tags are shown in Table 3.

The third section of FYSL is an actor. A group of actors is typically organized in a logical grid that can be one, two or three dimensional. The grid serves as a means of developing actor characteristics in GPU video memory. As shown in Table 4, the grid tag includes width, height, and depth values.

Actors are identified by global and specific shape and dynamic characteristics. The shape is used to determine collision detection for pairs, and the dynamics characteristics resolve the response by facilitating physical behavior. FYSL and FYSI use a left-handed coordinate system for shape definition. As shown in Table 5, the global actor tag includes name, type, and id values.

The actor id (identifier) is a positive integer and is required to be unique across a group of actors in the same hierarchy. For the most part, FYSI is required to assign default scene characteristics because of scene characteristics that are missing in the FYSL description.

  The definition of shapes supported in the described FYSL embodiment includes boxes (aligned or oriented with respect to the axis), spheres, meshes, and tetrahedra. The actor shape is defined in the local reference coordinate system. The box and sphere bounding the volume are represented as a pair of centers and radii (the center and radius are either vectors or scalars, respectively). The mesh and tetrahedron take the form of a set of vertex positions (for tetrahedrons the number of vertices is fixed at 4) and a set of face indices (implicit for tetrahedrons). For mesh, the face is explicit, while for tetrahedron, the face is implicit. The shape is associated with a matrix that identifies the transformation of the local coordinate system into the world coordinate space (see discussion below). Tables 6 to 10 illustrate tags specific to the shape.

The center of mass that bounds the volume is explicit by definition of shape. For meshes and tetrahedra, FYSI implicitly computes the center of mass unless the center of mass is provided in a linear set of motion characteristics. The mesh center-of-mass parameter does not necessarily have to be provided by the user, but if it does, it overwrites what FYSI calculates internally.

  The simulation is performed in the world coordinate space. Shape transformation is the concatenation of translation and rotation components and is due to the effect of applying linear and angular motion to the actor, respectively. The resulting matrix transforms the shape from local to world coordinate space. The transformation matrix is used by the FYSI client for the visual rendering process.

  The shape of the FYSL box can take either an arithmetic path aligned with the axis (AABB) or directional (OBB) within the FYSI. The selection is rather dynamic and can vary depending on the simulation step. For example, it can be based on a touch response. In general, the AABB path for collision detection is more efficient than the OBB path.

  The dynamic attribute can be any combination of linear, angular, and material types. Dynamic attributes define kinematic properties, including mass, velocity, position of the explicit center of mass, orientation, and force exerted. In addition, dynamic properties provide touch responsive material attributes such as restoration and friction. Dynamic tags for linear, corner and material types are provided in Table 11, Table 12, and Table 13, respectively.

A rigid body is assumed to be a point mass with respect to FYSI, which is the basis for the rules of physical behavior performed. Linear motion and external forces act on the center of mass of the body, and angular motion is applied to the contact points.

  The FYSL torque is applied to the vertices of any box or mesh shape when it is present. Torque is also significant in the case of particle-based actors, where each particle is defined as a zero radius sphere. Torque depends on the position of the actor (or parent actor in the case of particles) relative to the center of mass. The torque affects the resulting actor's angular motion. FYSL torque is meaningful for particle-based actors (eg, intangible actors that do not have a spatial extent). The torque depends on the position of the top level actor relative to the substantial center of mass. Torque affects the angular motion of the particles.

  The orientation with respect to the actor is required to be an orthogonal matrix in which rows and columns are unit length.

  The omega dynamic characteristic is a vector of angles in radians. A positive angle with respect to any axis results in a counterclockwise rotation about the axis, and a negative angle results in a clockwise rotation about the axis.

  The mesh index and tetrahedral face index are zero-based, each representing a triangle counterclockwise.

  The actor grid deployment utilizes a data parallel architecture unique to the GPU. The grid also provides the resolution of the final image read back from the physically assigned GPU, which moves the simulation results on the CPU or peer GPU that performs the visual rendering Let 1D grids are very inefficient on GPUs and are not normally used. Normally, actors are distributed on a 2D grid. The 3D grid is used, for example, when the addressability of the 2D grid exceeds the GPU limit. The dimension of the grid need not be a power of two. Finally, the number of actors may not necessarily match the number of grid cells (eg, the latter must be equal to or greater than the number of actors in the hierarchy). As a result, the 2D grid may have a last row that is not fully occupied, and the last slice of the 3D grid may not be fully occupied. FYSI fills all generated slivers with dummy actors.

  Actors can be created hierarchically, and the set of actors at each hierarchical level can share global attributes. A grid is required to be attached to a set of actors at each level. A shape at a higher hierarchy level is assumed to be a coarser geometric representation. This works in conjunction with starting a top-down simulation, and the removal of early collision detection improves the overall process efficiency. In addition, the dynamic characteristics of an actor can be unique at each hierarchical level, thus providing the freedom to perform adaptive physical characteristics. Joints (described later) can optionally be applied to groups of actors to simulate constraints. For example, joints are used in cloth simulations, as detailed in Section III below.

  The fourth section of FYSL is a joint. A joint defines an interaction constraint between a pair of actors. Joints inherently limit actor movement. Joints may have common parameters and / or unique parameters based on their type. Common parameters include joint types and handles for each member of a pair of actors. The joint is at the same tag level as the actor in the FYSL description format. Thus, joints can be defined both at the top scene level and at any actor hierarchy. Exemplary joint tags are provided in Table 14, Table 15, and Table 16.

The fifth section of FYSL is feedback. The feedback section of the FYSL description is only provided by FYSI for the return path of the simulation results. In a multi-step simulation session, there is a feedback section for each step. Exemplary feedback tags are shown in Table 17.

Exemplary embodiments may include the tags described above, but in alternative embodiments other tag types may be used. Sample # 1. Provided below is an exemplary section of code written in FYSL. This section of code illustrates a collision detection physics simulation scene with a pair of mesh-shaped actors, each with angular and linear dynamics.

Sample # 2. Provided below is another section of exemplary code written in FYSL. This section of code illustrates a two level hierarchy for particle-based actors in a 2 × 2 grid layout. This is the basic structure for defining cloth and fluid entities.

C. Exemplary methods in which physical parameters associated with a mesh may be received and converted to FYSL Software dynamics solvers (such as Autodesk (R) owned by California, San Rafael, Maya (R) Dynamics, etc.) are executed by the CPU Exists to do physics simulations. According to embodiments of the present invention, plug-ins are used to bypass such software dynamics solvers, thereby performing physical simulations on the GPU as described herein. In this embodiment, the plug-in captures a scene and converts attributes and fields associated with the actors depicted in the scene to FYSL. As a result, physical simulation can be performed on the GPU using FYSI. In another embodiment, the user may select whether the physics simulation is performed by a GPU or a software dynamics solver. In a further embodiment, a GPU or software dynamics solver is automatically selected and a physics simulation is performed based on predetermined criteria, such as GPU effectiveness and / or software support for a given function. For example, GPUs can be used to perform rigid body and cloth physics simulations, while software dynamics solvers can be used to perform physics simulations of fluids. Faster frame rates can be achieved by performing physics simulations with a GPU or software dynamics solver. An exemplary plug-in for bypassing a specific software dynamics solver (ie, Maya (R) Dynamics) is described in this chapter, but first an overview of Maya (R) Dynamics is provided.

  Maya (R) Dynamics is a type of technology that generates motion by simulating real-world physical properties. The dynamics in Maya (R) are diverse and powerful, and possess a tool set of importance levels consistent with modeling, animation and rendering. In general, the Maya (R) Dynamics concept implies simulation-based animation that does not use keyframes. The Maya (R) Dynamics family includes rigid and soft bodies, particle systems, cloths, fluids and hair members. Maya (R) Dynamics is used in games to create visually appealing effects based on physical principles.

  FIG. 6 illustrates a block diagram where GPUs are used to achieve higher simulation speeds without compromising robustness compared to software dynamics solvers such as Maya (R) Dynamics. An exemplary workflow 600 is illustrated. The workflow is largely controlled by plug-ins to Maya (R) Dynamics. Such plug-ins include scene exporters, GPU Dynamics simulator FYSI, and scene importers.

  The workflow 600 begins at step 610, where a scene exporter receives attributes and fields attached to a scene object by an artist. Attributes include initial velocity, spin, orientation, and material friction. Fields affect movement and represent forces including drag, gravity or procedurally defined, and movement is represented in a GPU shader program. The user selects either all scene objects or a subset thereof to initiate a GPU-based simulation. The exporter converts the object's geometry and dynamic properties into a physics simulation format for the GPU. The GPU-oriented physics simulation format is FYSL in one embodiment.

  In step 620, the physical simulation is performed on the GPU using FYSL. Once the appropriate FYSI plug-in appears, the GPU-based simulator seamlessly replaces the software dynamics solver node (eg, Maya (R) Dynamics (R) integration solver). The GPU simulator recursively executes simulations in a number of separate frames. During simulation, the current scene state is resolved and collision detection within each pair of FYSL dynamic actors is examined. The colliding pair is further processed to cause a touch response that will affect the motion of the associated actor. FYSI GPU-assisted physics simulations primarily utilize a pixel engine that exploits a higher degree of concurrency than a vertex processor. Physical simulations on the GPU are grid based, where there is little or no communication barrier across the grid cells. The arithmetic kernels involved have, for the most part, high arithmetic effectiveness properties and are therefore preferred candidates for demonstrating improved speedups compared to equivalent CPU implementations. This simulation process utilizes a single or multiple GPUs to improve efficiency, and is all transparent to artists interacting with the software dynamics solver. FYSI is in the same FYSL expression format as that sent by the exporter. FYSI results are cached internally for a complete simulation session and fully published for reuse in Maya (R) Dynamics.

  In step 630, the frame-by-frame simulator results are imported back into the Maya (R) Dynamics scene graph. During step 630, only the geometry and transformation data are important. FYSI provides both shape positional updates and transformation updates for each simulation step. The transformation data relates to the position and orientation of the incoming scene. In the case of rigid bodies, it is sufficient to update the nodes of the transformation scene graph from Maya (R) Dynamics. For deforming objects (such as cloths and fluids), updates are made for all mesh vertices or indices in the scene primitive nodes provided by Maya (R) Dynamics.

  In step 640, the simulation results are rendered for visualization. The simulation effect is visualized by calling a GPU or software-based renderer. In one embodiment, the GPU for performing the visual rendering task is physically separate from the GPU performing the physical simulation. This is also in this case to facilitate parallel processing at a higher level.

  In step 650, the rendered result is played back in the scene.

III. Exemplary Method for Performing Physical Simulations on One or More GPUs A. Method Overview Here, an exemplary method for performing physical simulation on one or more GPUs using FYSI and FYSL is described. FIG. 7 illustrates a block diagram and illustrates an exemplary method 700 for performing game physics simulations on one or more GPUs, in accordance with an embodiment of the present invention. The method 700 begins at step 710, where physical parameters associated with a mesh are mapped into video memory to set up a linear equation system that determines the motion of the mesh illustrated in the scene. The video memory may include a texture 310, described above with respect to FIG. As will be apparent to those skilled in the art, a mesh may represent any type of physical object, such as an individual object, volume, fluid, cloth, or other type of physical object.

  In step 720, using at least one pixel processor, an operation is performed based on the data in the video memory to solve the system of linear equations at that time. The modified data representing the solution to the system of linear equations at that time is then stored in video memory. In one embodiment, the modified data is stored in texture 310 and another shader then renders the graphics corresponding to the modified data. In this embodiment, a single GPU performs physical simulation and graphics rendering. In another embodiment, the modified data is provided as the output of the first GPU and then written to the texture of the second GPU. In the present embodiment, the first GPU performs physical simulation, and the second GPU performs graphics rendering. Alternatively, the first GPU may write the modified data to an area of memory accessible to the second GPU (eg, video memory or system memory of the first GPU).

  The method 700 may be implemented to simulate any kind of physical object. Provided below is an exemplary implementation for simulating a cloth on one or more GPUs. This exemplary implementation is provided for illustrative purposes only, and not for purposes of limitation. Based on the description contained herein, one skilled in the art will understand how to simulate other types of physical objects on the GPU.

  Here, an implicit technique for simulating a cross with one or more GPUs is described. First, a cross physical model and two approaches to simulating the model in discrete time are presented. Second, a three-step process of implicit discrete time simulation is described. Third, a method for mapping this three-step process to a GPU is presented.

(Example physical model for cross simulation)
The cloth can be simulated by the underlying particle system. Such endogenous particle systems can be represented as an array of point masses that undergo internal stretching and damping forces. These forces depend on the relative displacement and velocity of nearby points. Such an array of point masses is referred to herein as a point mesh. FIG. 8 illustrates an exemplary point mesh.

  Considering the point mesh 800, the following physical parameters associated with the point mesh 800 may be defined.

Alternatively, M can be interpreted as a block, which is a {n × n} diagonal matrix where each element is a {3 × 3} diagonal matrix.

  Newton's second law (ie, F = ma) can be written for a point mesh 800 as follows:

For a secondary mass spring system with linear damping, the net force acting on the particle i is the relative position

And the speed of all (usually nearby) particles

Is a function of Therefore, each component of the net force in Equation 1 is

Can be written. The motion of the point mesh 800 is determined by the following equation.

Thus, the solution of Equation 2 can be used to simulate the motion of the point mesh 800.

In order for Equation 2 to be solved by a series of computer steps (eg, steps performed by at least one pixel processor in the GPU), Equation 2 must be converted to a discrete-time problem. In time-discrete problems, the next state of the system is given by its previous state. Specifically, time t _k

Given the position and velocity of the system at, the simplest first-order discrete problem is the time t _{k + 1}

Determine the position and velocity of the system at. Solutions to time discrete problems require time discrete integration. There are at least two general types of time-discrete integrals, the explicit method and the implicit method.

  The explicit method uses forward projection of derivatives and computes the state at the next time step from the direct extrapolation of the previous state. For example, the primary Euler forward difference is approximated as follows:

The right side of the discrete time derivative is bounded on the left side by the value in the previous time step. The future state can be rewritten as a function of the state, i.e.

Applying the form of Equation 3 to a point mesh 800, the system of equations that determine the motion of the point mesh 800 (ie, Equation 2) is

Can be rewritten as a set of simple independent updating equations applied at each time step given by.

  The main drawback to explicit integration schemes is numerical stability. In general, to maintain a forward approximation, the function a (t) in Equation 3 is

Should not change too rapidly. Ie product

Must be below the threshold. If b ^k is large, the system is said to be “stiff”;

Must be made relatively small.

  The implicit method is responsible for the second type of time-discrete integration technique. The implicit method deduces the state at the next time step from the system of equations representing some “reversibility” from the extrapolated result. In other words, the backward derivative of the future state is simultaneously verified against the previous state. For example, the primary Euler forward difference is approximated as follows:

Skillfully, here, the right side of the time-discrete derivative is simultaneously bound to the left side by a future value. As a direct result, the future state cannot be expressed as a simple function of the previous state.

  By being applied to the point mesh 800, the governing equation of the system (ie, equation 2) becomes 3n unknowns

It must be solved at every time step.

Although this task may seem like a challenge, this approach has two important advantages. First, implicit technology is almost unconditionally constant. That is, the implicit technique is less influenced by the “stiff” equation characteristic of realistic cross simulations and can therefore support larger time steps. Second, the resulting system tends to be sparse and symmetric, and these types of systems are solved without difficulty using efficient numerical methods.

  The net internal force vector in either the explicit integration expressed in Equation 4 or the implicit integration expressed in Equation 5.

You must ask for. In general,

Is a non-linear function that models the internal constraints of the cloth. In discrete time

Is always a function of the current state.

Using explicit integration,

Is directly required,

Is updated. Specifically, as shown in Equation 4,

However, to ensure stability,

Is

Must be selected to reflect the “stiffness” of the. Unfortunately, realistic internal forces are relatively stiff and require relatively small time steps. As proved by the Baraff reference above, the cumulative cost of many updates in these small time steps, which is necessary for realistic rigid equations, is the cost of solving a large, sparse linear system in coarser time steps. Over time. David Baraff and Andrew Witkin's "Large Steps in Close Simulation", SIGGRAPH 98, pp. 43-54 (1998). As a result, the implicit approach is predominant in realistic cross simulation.

  Implicit integration techniques are not without complexity. In particular, the implicit integration technique is

not,

Requires an expression for. In this case, approximation is used. In particular,

Is approximated by the first-order Taylor expansion equation.

The first term in equation 6 is determined as in the explicit case, while the second and third terms are the Jacobian matrix

And is determined at the last time step. Although independent from external forces, these Jacob matrices are large and relatively difficult to obtain numerical values. The Jacob matrix is actually {n × n} of {3 × 3} sub-matrix elements.

  The Jacob matrix has the following form:

here,

So

Elements of the form itself

Given by the {3 × 3} Jacob matrix.

Assuming that the numerical value of is obtained, the linear system that needs to be solved at each time step (ie, Equation 5) is

Can be rewritten as follows.

Where I is the identity matrix, M is the orthogonal matrix of the mass of the mesh,

Is a vector representing the mesh geometric state at t _k ,

Is a vector representing the velocity of each point in the mesh at t _k ,

Is a vector representing the net force on each point of the mesh at t _k. Therefore, the implicit integration method for physics simulation of the point mesh 800 is

Is to solve equation 8 for.

  Equation 8 is

Where, where

It is.

  As described with reference to FIG. 5, performing physical simulation on the GPU using FYSI includes the following three steps. That is, (i) system setup step, (ii) solver step, and (iii) collision step.

  The system setup step is

In

Here is a constant time step that involves determining the value for

And the orthogonal mass matrix M and the current position of the point mesh

And speed

And is given. From these inputs,

Intermediate values for are obtained, which are given by equation 9

Is related to. The rest of this subsection details the evaluation of these intermediate values.

  A linear pair of force models for a rectangular point mesh 800 is used. In the linear pair of force models for point mesh 800, the ridge between points i and j is called a joint and represents a combined spring and damping material. If ij = ji, the two joints are complementary, in which case equal but conflicting forces (ie Newton's third law) are applied to the vertices i and j, respectively Is

Given in. If the joint is not defined between the vertices of i and j, or i = j,

It is clear that. Finally, the net internal force acting on the i th point and

The expression for that Jacobian is given by

In practice, joints are defined only between neighboring points and exist in a regular pattern. For example, the joint topology shown in the point mesh 800 of FIG. 8 includes up to 12 joints per point (depending on boundary conditions).

  Since the force for each joint depends only on its vertices,

Can be shown to be sparse. That is,

And

The expression for an element that is not on the diagonal line connecting the upper left and the lower right of (ie, j ≠ i) is as follows.

On the diagonal (ie, j = i)

and

If the original equation for is true and there is only one joint for point i, then the element is non-zero. Therefore, if ij is not a joint, it is not diagonal

So

May have as many non-zero elements as there are equal to the number of joints defined for point i plus one. For example, for the joint topology shown in FIG. 8, regardless of the dimension of the point mesh, the resulting Jacobian will have no more than 13 non-zero elements (= 1 + 12 joints per point).

  In order for the system of linear equations governing the motion of the point mesh 800 to represent a “matched” system, the matrix A must be (i) sparse and (ii) symmetric. For term (i), A is sparse. Because A is a Jacob matrix

This is because each of these Jacobian matrices has been proven to be sparse. Regarding item (ii):

The Jacobian is the following

As such, it can be contrasted when it can be implemented in off-diagonal parts.

  Thus, if equation 10 is true, A is sparse and symmetric, and thus the system of linear equations can be solved efficiently.

and

It will be appreciated that the criterion of being both is an inductive factor in a particular physical assumption.

  Referring to FIG. 8, joint forces between points in point mesh 800 can be classified into three types: (i) tensile joint 806, (ii) shear joint 804, and (iii) bending joint 802. Defined between adjacent nodes, the tension joint 806 models the strongest internal force. The tension joint 806 resists in-plane changes in the region. Defined between diagonal nodes, shear joint 804 models the second strongest internal force. The shear joint 804 resists the tendency to narrow inward when the cloth is pulled at a corner. Finally, defined between alternating nodes, the bending joint 802 models the weakest internal force. The bending joint 802 resists folding.

Although more realistic definitions have been made, the pairwise joint force-by-force model presented above is based on the aforementioned Baraff reference and Kwang-Jin Choi and Hyong-Seok Ko (“Stable but Responsive Cloth”, In
ACM Transactions on Graphics, SIGGRAPH 2002, pp. 604-11 (2002)), which is influenced by mixing with the model of joint force for the pair taught by, and is hereby incorporated by reference in its entirety. According to the model disclosed herein, all joints are modeled by the same function, but the type of joint (ie, tensile, shear, and bend) depends on stiffness k _s , damping k _d , and natural Different values for the length L can be globally represented by parameters. For each joint, the action and damping (parameterized by k _d ) of the spring (parameterized by k _s and L) are linearly independent and may be considered separate.

  Generally, joint force against either spring force or damping force

Satisfies two properties. (I) Force per joint

Is the direction of the joint

(Ii) force per joint

Is a conditional function

Is proportional to These two properties can be written mathematically as follows:

here,

So the criterion for symmetry

Is

On the other hand, the following needs to be implemented.

Where the force per joint

The spring component of is described. An ideal linearly moving spring resists and stores energy during deformation, and the spring is a manifestation of the action of a restoring force that acts to release the stored energy It is a reactive mechanical device. “Movement” relates to the type of mechanical force involved. In the model for cross simulation described herein, the force is the direction of the joint.

Acts along. “Linear” refers to a restoring force that is directly proportional to deformation (ie, a change in x). Finally, “ideal” means that no energy is lost during the cycle of deformation and restoration.

  The most simplified ideal linear moving spring

A spring condition function for each joint corresponding to is defined.

Depends only on the current vertex position,

And is parameterized by the stiffness coefficient k _s and the natural length L given by the following equation:

Where the force per joint

Are described. A damper is a passive mechanical device that resists deformation, but in contrast to a spring, it does not store energy or represent a restoring force. Instead, the damper resists deformation by dissipating energy applied in the form of heat. This property is created by pure resistance, which is proportional to the change in speed.

  In the model for the cloth simulation described herein, the ideal linear displacement damper is the joint direction.

The joint force is the speed of its apex.

Is directly proportional to the relative change in. More specifically, the damper has a velocity in the joint direction.

Represents a resistance force proportional to the relative change in. Damper condition function for each joint, expressed in parameters by the damping coefficient k _d

Is defined. The damper condition function for each joint is

Satisfies the symmetry criterion for both. This statement can be expressed mathematically as:

Here, the response and effect of external force applied to the point mesh 800 are described. Examples of external forces include gravity, wind, and collisions (both self and the environment). It should be understood that there is a clear distinction between external force responses and effects. In response, the current state

Immediate changes to are included. Thus, the response is relatively easy to model. In contrast, the effect of force constrains future conditions (ie, limits future freedom because the fabric is pinned). Therefore, the effect is relatively difficult to model.

  Several approaches are known for solving external force responses and effects, including approaches using reduced coordinates, penalty methods, and / or language multipliers. For example, see the Baraff reference above. Another approach, discussed in the Barraff reference, constrains the mass of a given point in the modeled point mesh. As mentioned above, the diagonal mass matrix

For each block unit, the mass of the i-th particle is represented by a {3 × 3} diagonal matrix

Represent as However, if the mass is assumed to be anisotropic and varies with direction, Equation 11 is

Can be written as Based on the mass given in Equation 12, the equation of motion for a point mesh is

It becomes. Therefore, efficiently defining the anisotropic mass is relative to the xy plane.

This effectively restrains the above-mentioned effect, and acceleration is impossible in the z direction.

  The approach developed in the Baraff reference has implications for the symmetry of linear systems and consequently has efficient solvability. These problems can be solved by using a modified conjugate gradient (“modified CG”) method, which introduces a filtering operation to implement mass-based constraints. Another approach uses both mass-based constraints and modified CG methods, which include Kwang-Jin Choi and Hyong-Seok Ko (“Stable but Responsive Cloth”, In ACM Transactions on Graphics, SIGGRAPH 60.2). -11 (2002)), which is incorporated herein by reference in its entirety.

B. Exemplary Implementation for Simulating Cross on GPU We have described a model for simulating cloth implicitly, where we now implement a simulation of cross for each discrete time step on the GPU. A three-step method is described. FIG. 9 depicts an exemplary flow chart for implementing cross simulation on a GPU according to an embodiment of the present invention. In other words, FIG. 9 is a high level depiction of a particular implementation of the physics simulation block 410 described above with reference to FIG. In FIG. 9, the large circle represents an array of textures or video memory and may be similar to the texture 310 described above with reference to FIG. The specific mapping of data to texture is as follows: (I) A circle 902 (classified as M) represents a texture that includes data related to the mass of each point in the point mesh 800. (Ii) A circle 904 (classified as P) represents a texture containing data regarding the position of each point in the point mesh 800. (Iii) A circle 906 (classified as V) represents a texture containing data regarding the speed of each point in the point mesh 800. (Iv) A circle 908 (classified as F) represents a texture containing data relating to the net force acting on each point in the point mesh 800. (V) Circle 912 (classified as J) represents a texture including data relating to a Jacobian matrix. Shaded circles 910 represent kernel operations (such as mathematical operations performed by one or more GPUs).

  The first step for implementing the cloth simulation on the GPU is to set the physical parameters associated with the point mesh to set up a system of linear equations governing the motion of the point mesh, as shown in FIG. A mapping to a texture (ie video memory) is included. By applying an implicit integration technique, what has been described above is that the system of linear equations governing the motion of the point mesh is

It can be written, and here,

It becomes. The mass, position, and initial velocity of the modeled point mesh are established by the artist creating the scene. As a result, textures 902a, 904a and 906a (corresponding to mass, position and initial velocity, respectively) can be satisfied immediately. In contrast, all components of the Jacobian matrix and net power are not established by the artist. As a result, the kernel operation 910a is based on inputs from textures 904a, 906a, and 908a, and forces and Jacobian matrices.

To evaluate. The result of this evaluation is written into textures 908b and 912b. After these results are written to textures 908b and 912b, the system setup step is complete for this time step.

  The second step for implementing cross simulation on the GPU includes updated values of position and velocity, as shown in FIG.

Includes solving a linear system for. The kernel operation 910b solves the linear equation system based on the inputs from the textures 902a, 904a, 906a, 908b and 912b. Based on this solution, updated values for position and velocity are written to textures 904b and 906b, respectively. After the updated value is written, the system solver step is complete for this time step.

  The final step for implementing cross simulation on the GPU includes collision detection, as shown in FIG. Kernel operation 910c determines whether a collision occurs based on inputs from textures 902a, 904b, 906b, and 908b. The result of kernel operation 910c is written into textures 902b, 904c, 906c and 908c. After these results are written, the collision response step is completed for this time step.

  Here, each of the steps for implementing a cross simulation on the GPU is described in more detail.

i. Step 1: System Setup A major design challenge for GPU implementations is the development of texture representations of system equations that are compact and facilitate single instruction multiple data (SIMD) parallelization. One embodiment of the present invention utilizes 17 persistent textures with structures derived directly from the rectangular point mesh under consideration. However, the present invention is not limited to 17 textures. Those skilled in the art will understand how to perform a physical simulation on a GPU using a different number of textures without departing from the spirit and scope of the present invention.

  The texture used to simulate the cloth described herein is a two-dimensional texture of n texels having a height of "rows" and a width of "cols" corresponding to the point mesh 800. . The point mesh 800 is organized into rows and columns, which are elements of “rows” and “cols”, respectively. Accordingly, each texel position of each texture is mapped one-to-one to a specific point in the point mesh 800. Each texture is ordered from left to right and from top to bottom. In general, individual textures store different properties belonging to the same point i at the same texture coordinate {s, t} (for the sake of clarity, the body text describes all texture coordinates as height = Delineated as non-normal integer bounded by 'rows' and width = 'cols'). The mapping of point numbers to point texture coordinates and vice versa is given by:

Furthermore, on the condition of the boundary, the joint topology point offset shown in FIG. 8 is also mapped to a two-dimensional texture offset as shown in Table 18.

The 17 textures are classified as P, V, F, A #, B #, C, and D, where A # and B # are a collection of 6 textures each. each

In contrast, 17 texture contents are then given by the following definitions: First, textures P, V and F are respectively

Represents. In particular,
・ P is the current position of the point

3 components of
・ V is the current speed of the point

3 components of
F is the current net force vector of the point

Are stored. Second, A # and B # are respectively

Represents the lower triangle (element not on the diagonal). In particular,
・ A # is

Store a {3 × 3} matrix corresponding to
・ B # is

, Where A0-A5 and B0-B5 are defined for each of the following six joints.

Third, textures C and D are respectively

Represents an element on the diagonal of. In particular,
・ C is

Store a {3 × 3} matrix corresponding to
・ D is

{3 × 3} matrix corresponding to is stored.

  Now that 17 textures have been defined, a two-step process for filling these textures (ie, for performing the system setup steps of FIG. 9) will now be described. FIG. 10 illustrates a two-step process flow diagram for establishing a linear equation system that governs the motion of the point mesh 800. Included in FIG. 10 is input textures 1002a and 1004a.

And output textures 1006a, 1008a, 1012a, 1014a, and 1016a

It is.

  The first stage of FIG. 10 includes six identical subpaths, which are represented by kernel operations 1010a-1010f that operate on the joints of the complementary pair of joints. In this first stage, the net force vector

(Ie texture F) and

The lower triangle (element not on the diagonal) of the textures A0-A5 and B0-B5 is determined. That is, the results of kernel operations 1010a-1010f are written into textures 1006b, 1008b, and 1012b.

  The second stage of FIG. 10 includes two identical subpaths, represented by kernel operations 1010g and 1010h,

The diagonal elements of (ie, textures C and D) are determined from the elements that are not on the diagonal of the lower triangle (ie, textures A0-A5 and B0-B5). That is, the results of kernel operations 1010g and 1010h are written into textures 1016b and 1014b, respectively. The first stage and the second stage are each described in more detail below.

  The first stage of system setup (Figure 10) is the net force vector

(Ie texture C) and

(I.e., textures A0-A5 and B0-B5) including determination of the lower triangle (elements not on the diagonal). As shown in FIG. 10, the evaluation of these outputs may involve a huge overlap of analysis per joint, as represented by kernel operations 1010a-1010f. As a result, this first stage can be divided into six identical joint-by-join subpaths, as represented in FIG.

  FIG. 11 illustrates a flowchart 1100 representing the joint path m. Each joint path includes two subpaths and is represented by a first kernel 1110a (classified as EvaJoint) and a second kernel 1110b (classified as updateF). The first kernel 1110a is written to temporary textures T, Am and Bm, respectively.

Calculate per-joint values for. The specific joint analyzed for each subpath is

By the texture Am and Bm.

  The first kernel 1110a (evalJoint) uses the following facts.

(1) Both joint values are most easily evaluated,
(2) Stored in Am and Bm

Elements that are not on the diagonal of are actually independent,

Equal to
(3) Symmetry

Thus, the same analysis is performed on the complementary joints. Therefore, it is ideal (ie, there is no duplication of work) to analyze the unique half of the joint in our topology. Furthermore, by symmetry, stored in textures A0-A5 and B0-B5

The lower triangle (elements that are not diagonal) is sufficient to represent all elements that are not diagonal in the Jacobian.

  The second kernel 1110b (classified as updateF) uses the force of the joint being analyzed to determine the net force.

(Or texture C) is updated. The second kernel (updateF) is the force per joint currently stored in T

Input net force vector (from another subpath or including external force)

Or add to texture C. This in particular makes use of the linear independence of joint forces and the symmetry provided by Newton's third law. Since each subpath efficiently calculates the force of the complementary pair of joints, the second kernel 1110b (updateF) must address T to properly account for both contributions (boundary conditions , Certain values for each joint force in T can be irregular).

  Referring again to FIG. 10, the second and final stages of system setup are:

Includes determination of diagonal elements of (ie textures C and D). In this second stage, the fact that these diagonal elements are an advantageously structured accumulation of elements that are not on those diagonals is reinforced. In particular, each of the following accumulations includes up to 12 terms, and those for each joint (depending on the boundary conditions) are readily available in textures A0-A5 and B0-B5.

As illustrated graphically in FIG. 12, the accumulation in equation 13a is evaluated by kernel 1250a (classified as evaldiagonalC) and the accumulation in equation 13b is evaluated by kernel 1250c (classified as evaldiagonalD). Kernels 1250a and 1250c are independent and differ only in their inputs and outputs. The kernel 1250a obtains data as input from the textures 1202a, 1204a, 1206a, 1208a, 1210a, and 1212a, and these textures are collectively the Jacob matrix.

Represents an element that is not on the diagonal of. The output of kernel 1250c is written to texture 1214b (ie texture C). The kernel 1250c obtains data as input from the textures 1222a, 1224a, 1226a, 1228a, 1230a, and 1232a, and the textures are collectively set to a Jacobian matrix.

Represents an element that is not on the diagonal of.

ii. Step 2: System Solver Referring again to FIG. 8, the second step in simulating cloth on the GPU is the system solver step. The most promising approach to the system solver step is the linear system described in the Baraff reference above.

Using a conjugate gradient (CG) method. It is ideal for large, sparse, symmetric and positive definite systems.

Until is below the user-defined threshold,

Including procedural approximation. The exemplary methods described herein use the CG method for the system solver step, but other methods may also be recognized by those skilled in the art without departing from the spirit and scope of the present invention. Can be used.

iii. Step 3: Collision Response Referring again to FIG. 8, the third and final step in the simulation of the cross on the GPU is the collision response step. Collision detection schemes can use a pair of points from a simulated mesh (eg, point mesh 800) to (i) another pair of points from the mesh, or (ii) another object being simulated (eg, a point). Whether or not a collision has occurred is determined by determining whether one of a pair of points from the ball) depicted in the same scene as the mesh 800 intersects. As illustrated by the aforementioned Baraff reference, collision detection schemes are well known to those skilled in the art. Any collision detection scheme known to those skilled in the art can be used without departing from the spirit and scope of the present invention.

C. Example Code Written in FYSL Provided below is an example section of code written in FYSL. In particular, provided below are (i) a high level scene description written in FYSL, (ii) a child actor deployment, and (iii) a prototype deployment of a fabric joint.

  i. High-level scene description written in FYSL

ii. Child Actor deployment

iii. Fabric joint prototype development

IV. Exemplary Computer Implementations Embodiments of the invention may be implemented using hardware, software, or a combination thereof, and may be implemented in one or more computer systems or other processing systems. However, although the operations performed by the present invention have been frequently referred to with respect to additions, comparisons, etc., they generally relate to operations performed in the head performed by human operators. In any of the operations described herein that form part of the present invention, no such human operator capability is required or desired in most cases. Rather, the operation is a mechanical operation. Useful machines for performing the operations of the present invention include digital computers, such as personal computers, video game consoles, cell phones, personal digital assistants, or similar devices.

  Indeed, in one embodiment, the present invention is directed to one or more computer systems capable of performing the functionality described herein. An example of a computer system 1300 is shown in FIG.

  Computer system 1300 includes one or more processors, such as processor 1304. The processor 1304 can be a general purpose processor (such as a CPU) or a dedicated processor (such as a GPU). The processor 1304 is connected to a communication infrastructure 1306 (eg, a communication bus, crossover bar, or network). Various software embodiments are described in terms of this exemplary computer system. After reading this description, it will become apparent to a person skilled in the art how to implement the invention using other computer systems and / or architectures.

  Computer system 1300 includes a display interface 1302, which displays graphics, text, and other data from communication infrastructure 1306 (or a frame buffer not shown) for display on display unit 1330. Forward.

  Computer system 1300 also includes main memory 1308, preferably random access memory (RAM), and may also include secondary memory 1310. The secondary memory 1310 may include, for example, a hard disk drive 1312 and / or a removable storage drive 1314, such as a floppy disk drive, magnetic tape drive, optical disk drive, and the like. The removable storage drive 1314 reads from and writes to the removable storage unit 1318 in a well-known manner. The removable storage unit 1318 represents a floppy (registered trademark) disk, a magnetic tape, an optical disk, and the like, and is read and written by the removable storage drive 1314. As will be appreciated, the removable storage unit 1318 includes computer usable media having computer software and / or data stored therein.

  In alternative embodiments, secondary memory 1310 may include other similar devices that cause computer system 1300 to load computer programs or other instructions. Such devices may include, for example, a removable storage unit 1322 and an interface 1320. Examples include program cartridges and cartridge interfaces (such as those found in video game consoles), removable memory chips (such as erasable programmable read only memory (EPROM) or programmable read only memory (PROM)) and associated sockets. , As well as other removable storage units 1322 and interfaces 1320 that allow software and data to be transferred from the removable storage unit 1322 to the computer system 1300.

  Computer system 1300 may also include a communication interface 1324. Communication interface 1324 enables the transfer of software and data between computer system 1300 and external devices. Examples of communication interface 1324 may include a modem, a network interface (such as an Ethernet card), a communication port, a personal computer memory card international association (PCMCIA) slot and card, and the like. Software and data transferred via the communication interface 1324 take the form of a signal 1328, which can be electronic, electromagnetic, optical, or other signal receivable by the communication interface 1324. These signals 1328 are provided to the communication interface 1324 via a communication path (eg, channel) 1326. This channel 1326 carries signal 1328 and may be implemented using wires or cables, optical fibers, telephone lines, cellular links, radio frequency (RF) links and other communication channels.

  In this text, the terms “computer program medium” and “computer usable medium” are generally used to refer to a removable storage drive 1314, a medium such as a hard disk installed in hard disk drive 1312, and a signal 1328. These computer program products provide software to computer system 1300. The present invention is directed to such a computer program product.

  Computer programs (also called computer control logic) are stored in main memory 1308 and / or secondary memory 1310. A computer program may also be received via communication interface 1324. Such computer programs, when executed, enable the computer system 1300 to perform the functions of the present invention as discussed herein. In particular, the computer program, when executed, enables the processor 1304 to perform the functions of the present invention. Accordingly, such a computer program represents a controller of computer system 1300.

  In embodiments where the present invention is implemented using software, the software may be stored in a computer program product and loaded into a computer system 1300 using a removable storage drive 1314, hard drive 1312, or communication interface 1324. When executed by the processor 1304, control logic (software) causes the processor 1304 to perform the functions of the present invention as described herein.

  In another embodiment, the invention is implemented primarily in hardware using, for example, hardware components such as GPUs. Implementation of a hardware state machine to perform the functions described herein will be apparent to those skilled in the art.

  In yet another embodiment, the invention is implemented using a combination of both hardware and software.

V. CONCLUSION It should be recognized that the chapters of the embodiments, rather than the summary and summary chapters, are intended to be used to interpret the claims. The summary and summary sections may describe one, but not all, of the exemplary embodiments of the present invention, as intended by the inventors. Accordingly, the Summary and Summary sections are not intended to limit the invention and the appended claims in any way.

Claims (4)

A method for performing a physics simulation, wherein the method is performed by an interface system that communicates with at least one graphics processor unit (GPU) such that the at least one GPU communicates with a plurality of memory arrays. Is adapted and includes at least one pixel processor;
The method
The interface system sends simulation definition data to the at least one GPU;
The interface system includes receiving simulation results from the at least one GPU responsive to the transmitted simulation definition data;
The simulation results, the first stage and at least one mesh in the associated mapped child physical parameters to the plurality of memory arrays during the second stage of the process and, using one of the pixel processor the at least Generated by the at least one GPU by performing operations on data in the memory array ;
The operation is
Performing a first set of identical rendering sub-passes that operate on complementary joints between the first set of physical parameters associated with the at least one mesh during the first stage; ,
During the second stage, perform a second set of identical rendering sub-passes that operate on the first set of physical parameters based on the results of the first set of identical rendering sub-passes To do
Including the method.   Transmitting simulation definition data to the at least one GPU includes transmitting at least one of scene data, simulation data, actor data, joint data, and feedback data to the at least one GPU; The method of claim 1.   The method of claim 1, wherein the transmitting includes transmitting simulation definition data in a markup language format to the at least one GPU. A computer readable medium comprising instructions for generating at least one graphics processor unit (GPU) in communication with an interface system, wherein the at least one GPU is adapted to communicate with a plurality of memory arrays. And including at least one pixel processor, the instructions being adapted to create the at least one GPU when executed, the at least one GPU comprising:
Receiving simulation definition data from the interface system;
Transmitting simulation results in response to the transmitted simulation definition data to the interface system; and
The simulation results, the first stage and at least one mesh in the associated mapped child physical parameters to the plurality of memory arrays during the second stage of the process and, using one of the pixel processor the at least Generated by the at least one GPU by performing operations on data in the memory array ;
The operation is
Performing a first set of identical rendering sub-passes that operate on complementary joints between the first set of physical parameters associated with the at least one mesh during the first stage; ,
During the second stage, perform a second set of identical rendering sub-passes that operate on the first set of physical parameters based on the results of the first set of identical rendering sub-passes To do
A computer readable medium comprising: