EP2158553A2

EP2158553A2 - Computer device for simulating a set of objects in interaction and corresponding method

Info

Publication number: EP2158553A2
Application number: EP08826113A
Authority: EP
Inventors: Stéphane REDON; Romain Rossi
Original assignee: Institut National de Recherche en Informatique et en Automatique INRIA
Current assignee: Institut National de Recherche en Informatique et en Automatique INRIA
Priority date: 2007-06-20
Filing date: 2008-06-13
Publication date: 2010-03-03
Also published as: BRPI0813385A2; WO2009007550A2; US8489370B2; CN101779203A; CN101779203B; FR2917866A1; FR2917866B1; US20100179795A1; JP5421248B2; JP2010530581A; WO2009007550A3; KR101496368B1; KR20100050460A

Abstract

Computer device for simulating a set of objects in interaction and corresponding method. A computer device for simulating a set of objects in interaction comprises: a memory (8) with a tree representation of the objects, each node being associated with dynamic, geometric and interaction data dependent on the data of the child nodes and local interaction data for certain nodes, a simulation controller (4), for actuating repeatedly: + a distributor (10) of interaction data, with a mechanism for interaction updating which scans the tree representation and updates an item of interaction data of a node as a function of the local interaction data of its child nodes, + a mechanism for updating the dynamic data (12) which scans the tree representation and operates as a function of the geometric interaction data concerned, + a mechanism for updating the geometric data (14) which scans the tree representation for nodes subject to interaction and operates as a function of the dynamic data updated. The invention also relates to a method for simulating a set of objects in interaction, and a computer program product.

Description

Computer device for simulating a set of interacting objects and corresponding method

The invention relates to the simulation of a set of interacting objects.

The simulation of interacting objects is a vast field that extends from the simulation of a multitude of more or less complex mechanical bodies to the simulation of the behavior of molecules, for example proteins.

The first approaches developed were based on the collection of objects, that is their grouping together in order to define a global behavior. This type of approach is interesting because of its relatively low calculation costs.

However, the reduction of the cost of calculation is to the detriment of the realism of the simulation insofar as many aspects relating to the relations of the grouped objects are voluntarily ignored or reduced to their simplest expression.

Other approaches have been to consider interacting objects as articulated bodies. An articulated body is generally composed of two bodies connected to each other by a joint. The two bodies can be articulated bodies themselves and so on. This approach allowed to model with fidelity the mechanical behavior of such sets of objects while maintaining a high level of performance.

We speak of "mechanical" behavior because objects interact essentially through the joint or joint that joins them. It is then enough to model the articulations to model the set of objects.

When the interactions between objects become more complex, these approaches become rather ineffective quickly, because the needs / computational costs associated with them become prohibitive.

The invention improves the situation. For this purpose, the invention proposes a computing device for the simulation of a set of interacting objects which comprises a memory containing a tree representation of the set of objects. In this tree representation, each of the intermediates is associated with dynamic data, geometric data and interaction data.

The device further comprises a simulation controller that operates in a repetitive cycle:

a distributor of interaction data on objects and subsets of objects,

a mechanism for updating the dynamic data with traversing of the tree representation for nodes of the interaction subjects according to the interaction data and the geometric data concerned, and

a mechanism for updating the geometric data, with traversing of the tree representation for nodes subject to interactions, as a function of the dynamic data updated.

In order to take into account interactions between independent nodes of the joints, the memory further includes local interaction data associated with at least some of the nodes, and the interaction data distributor includes an interaction update mechanism, with traversal of the tree representation for interacting subjects, for updating an interaction datum of a node according to the local interaction data of concerned child nodes.

Such a device is particularly advantageous because it offers the possibility of extending the articulated body modeling approach, while taking into account non-exclusively articular forces, without significantly increasing the calculation time, and consequently increasing the exploitability of the simulation. The invention also relates to a method for simulating the behavior of a set of interacting objects in which a tree representation of the set of objects is maintained. In the representation, each intermediate node is associated with dynamic data, geometric data and data dependent interaction data of its child nodes.

The process repetitively uses a cycle comprising the following steps:

at. distribute interaction data on some of the objects and subsets of objects,

b. traversing the tree representation for interacting subject nodes, while updating dynamic data of these nodes, based on the interaction data and geometric data concerned, and

vs. re-browsing the tree representation for interacting subject nodes, while updating geometric data, based on the dynamic data as updated in step b.

More specifically, step a. includes:

al. a preliminary path of the tree representation for interacting nodes, with the update of the interaction data of these nodes, as a function of local interaction data of concerned child nodes.

Other characteristics and advantages of the invention will appear better on reading the description which follows, taken from examples given by way of non-limiting illustration from the drawings in which:

FIG. 1 represents a schematic diagram of a computing device according to the invention; FIG. 2 represents a block diagram of an implementation by functions of a simulation loop performed by the device of FIG. 1;

FIG. 3 represents a block diagram of a first function of the simulation loop of FIG. 2;

FIG. 4 represents a block diagram of a function of FIG. 3;

- Figures 5 and 6 schematically show two functions of Figure 4;

FIG. 7 represents a block diagram of another function of FIG. 3;

FIG. 8 represents a block diagram of a second function of the simulation loop of FIG. 2;

FIG. 9 represents a block diagram of a third function of the simulation loop of FIG. 2;

FIG. 10 represents a block diagram of a fourth function of the simulation loop of FIG. 2; and

FIG. 11 represents a block diagram of a fifth function of the simulation loop of FIG. 2.

The drawings and the description below contain, for the most part, elements of a certain character. They can therefore not only serve to better understand the present invention, but also contribute to its definition, if any.

This description is likely to involve elements likely to be protected by copyright and / or copyright. The rights holder has no objection to the identical reproduction by anyone of this patent document or its description, as it appears in the official records. For the rest, he reserves his rights in full.

The invention also covers, as products, the software elements described, made available under any "medium" (support) readable by computer. The term "computer readable medium" includes data storage media, magnetic, optical and / or electronic, as well as a medium or transmission vehicle, such as an analog or digital signal.

In addition, the detailed description is augmented by Appendix A, which gives the formulation of certain mathematical formulas implemented in the context of the invention. This Annex is set aside for the purpose of clarification and to facilitate referrals. It is an integral part of the description, and can therefore not only serve to better understand the present invention, but also contribute to its definition, if any.

A first approach to the mechanical simulation of articulated bodies has been proposed in the article "A divide-and-conquer articulated body algorithm for parallel o (log (n)) calculation ofrigid body dynamics. Part 1: Basic Algorithm", International Journal of Robotics Research 18 (9): 867-875 by Featherstone, hereinafter referred to as Featherstone '99.

Featherstone '99 describes an algorithm for splitting an articulated body into a binary tree, to compute the set of force and position components recursively. Articulated body means the assembly which comprises a joint, or joint, which connects two bodies that can themselves be articulated bodies.

The concept of an articulated body must not therefore be restricted to its mere mechanical connotation. The notion of articulation must also be understood in a broad sense. For example, an articulation may comprise a variable number of degrees of freedom, ranging from zero (rigid coupling of the two subsets) to six (relative movement of the two non-constrained subsets). The binary tree has leaf nodes which represent the most basic objects of the articulated object, and which are each connected to a joint, or node. Thus, each node of the binary tree is itself an articulated body which designates a subset of objects.

The article "An Efficient, Error-Bounded Approximation Algorithm for Simulating Quasi- Statics o / Complex Linkages", Proceedings of ACM Symposium on Solid and Physical Modeling, 2005, by Redon and Lin, noted below SPM '05, completes this approach by defining an acceleration metric of the joints.

This metric is used to evaluate the acceleration of the articulated body associated with a given joint, from the data of this joint alone, without knowing the data of the sheets. It is then possible to "stiffen" the shaft, by canceling the acceleration of an articulated body for which the acceleration metric is less than a chosen threshold. The rigidification of the tree thus makes it possible to restrict the path of the tree to a reduced number of nodes, while controlling the fidelity of the simulation.

In the article "Adaptive Dynamics cf Articulated Bodies", ACM Transactions on Graphics (SIGGRAPH 2005), 24 (3). by Redon, Gallopo and Lin, noted below SIGGRAPH '05, the quality of the simulation is improved by also treating the dynamic case, and not only quasi-static, and by adding a method of taking it into account of the stiffening, to avoid creating forces with no concrete reality.

The embodiments described herein take advantage of all of these methods, and may sometimes be implemented as extensions thereof, although many other implementations of the invention may be contemplated.

For simulation, each node of the tree is associated with various data. There are three main types of data that will be described later: interaction data, dynamic data and geometric data. The interaction data can be defined as follows: it represents forces that apply to a given node, or to a given object in the subset of objects represented by that node. These forces can be classified into two classes of forces:

- forces of constraint, related to the interactions of objects through the joints, and

- local forces, which include all the other forces that can be applied to a given node.

In the example described here, the objects are molecules and atoms, and the local forces include on the one hand the external forces that apply individually to joints, and on the other hand all the inter-atomic forces. and inter-molecular, such as electrostatic forces, van der Waals forces etc.

Dynamic data represent composite data characteristic of the dynamics of articulated bodies. These data make it possible to compute metrics of acceleration and speed of joint without necessarily knowing all the data of position and force of all the objects. Their application will appear better later.

Geometric data represent a set of characteristic data of articulated bodies that depend exclusively on the relative positions of objects between them. This data makes it possible to perform most of the calculations in local references, which simplifies the simulation. Here again, these data will be explained later.

The example described here applies to a quasi-static simulation of objects. This means that we consider that their speed is zero at every moment. FIG. 1 shows a schematic representation of a device according to the invention.

The device 2 comprises a simulation controller 4, a simulation block 6 and a memory 8. The simulation block 6 comprises an interaction data distributor 10, a dynamic data update mechanism 12 and a setting mechanism. Geometric Data Update 14.

During a simulation, the controller 4 repetitively actuates the simulation block 6 according to a simulation loop which will be described below on the basis of data contained in the memory 8.

The device 2 can be realized in several forms. The presently preferred embodiment is a computer program that implements the controller 4 and the block 6 in executable form on a commercially available computer, for example a computer having a 1.7 GHz microprocessor, having 1 GB of RAM, and a hard disk of sufficient size to contain an operating system and program code.

Nevertheless, other embodiments are possible, such as the embodiment in the form of a specialized printed circuit (daughter card, ASIC, etc.) or a dedicated processor (FPGA, microchip, etc.).

FIG. 2 shows a schematic diagram of an implementation of the simulation loop carried out by block 6. In this loop, functions Upd lnt () 20, Sprd_Int () 22, Get_Dyn_Coeff () 24, Upd_Dyn () 26, and Upd_Geo () 28, are called successively.

The loop shown in FIG. 2 represents the main steps of the simulation in a given operating loop. These steps are respectively the update of inter-object interactions of non-articular nature, the diffusion of these interactions, obtaining and updating dynamic simulation parameters, and then updating geometric simulation parameters.

Although the different steps represented in FIG. 2 correspond to functions in the program implementing the invention, it will subsequently appear that these functions themselves comprise several subfunctions, and must be considered as functional components that the human being the profession will be free to implement as he sees fit.

From a functional point of view, we can consider that:

* The functions Upd_Int () 20 and Sprd_Int () 22 constitute a kernel of the data distributor 10,

the functions Get_Dyn_Coeff () 24 and Upd_Dyn () 26 constitute a core of the dynamic data update mechanism 12, and

* The function Upd_Geo () 28 constitutes a kernel of the mechanism for updating geometric data 14.

FIG. 3 represents a possible implementation of the function Upd_Int () of FIG. 2. As can be seen in this figure, the function Upd_Int () 20 comprises three subfunctions, Upd_BB () 30, Upd_Int_L () 32 and Upd_Int_Val () 34.

In the classical approach, when a subset of objects is rigidified, it temporarily stops being processed in the simulation. Since the forces considered in this type of simulation are of mechanical type, this subset can be very close in the space of another subset of objects without this having any consequence. When it is desired to simulate the behavior of a protein or a molecular chain, local electrostatic or van der Waals type interatomic forces are added to the forces of stress and external forces.

Therefore, the "mechanical" simulation is no longer sufficient, because it becomes possible for a rigidized sub-assembly to interact with another subset. It is then necessary to "de-rigidify" it to take account of these new local forces, which depend only on the relative position of the objects between them. This is not possible in the existing approach unless you give up all the benefits.

The function Upd_Int () 20 allows to take into account these local forces. For that, this function starts from a given molecular situation, and makes it possible to determine at first what are the objects likely to interact with each other. In a second step, this function calculates the corresponding local forces, and integrates these data in an orderly way.

The function Upd_BB () 30 is an adaptation of interaction detection to molecular simulation. Since interatomic forces are mainly short-range, this function defines potential interaction spaces around each object.

More precisely, these spaces are defined as "oriented boxes" surrounding an object or group of objects. The boxes themselves are defined for each node of the binary tree at the beginning of the simulation, and the function Upd_BB () operates by updating the position of a reference point and an orientation direction for each box. .

The principles of oriented boxes, called "Oriented Bounding Box" or OBB in the literature, are described in the article "Obbtree: a hierarchical structure for rapid interference detection" by Gottschalk et al. in ACM Translations on Graphics (SIGGRAPH 1996).

Since OBBs depend exclusively on the positions of the objects they surround, and as they are expressed in a repository linked to the node to which they are attached, they are unchanged when a node is stiffened. The function Upd_OBB () 30 therefore operates only on the nodes whose position has changed during the preceding simulation step. This function traverses the binary tree from bottom to top selectively, crossing only the so-called active nodes, as will be explained below.

The updated OBBs form the workbase used by the Upd_Int_L () function 32. This function, an implementation of which is shown in Figure 4 recursively traverses the binary tree from top to bottom, from the root RN.

The function Upd_Int_L () maintains for each node two main lists Int_L and Int L Old. At each node, the list Int L (respectively Int L Old) contains pairs of nodes belonging to the subset of objects designated by the given node which interact by local forces in the current loop (respectively the previous loop).

These lists make it possible to detect the local interactions that have changed, that is to say the local interactions that have been modified by the positions of the objects following the previous loop.

The function Upd_Int () starts from a 3200 activity test of the current node. This test is related to the acceleration metric of the current node (or other appropriate metric where appropriate), and can be realized as a calculation of this metric, or as a reading of a data (commonly called "flag") which indicates the active character or not of the node, decided according to the value of this metric.

In the example described here, a node is considered active if the value of its acceleration metric is greater than a threshold chosen by the user, that is to say if it is considered non-rigidified. If the node is rigid, it means that the global accelerations within the articulated body associated with the node are considered as zero within the framework of the simulation. As we have seen above, this means that the positions of the objects within this body have not changed, since the accelerations of this body have been considered as null. Thus, the IntJL and Int Old L interaction lists of the preceding loop remain valid for this node and all these child nodes, and the function stops (3202).

If node C is active, the list Int L (C) of the preceding loop becomes the list Int Old L (C) for the current loop by overwrite (3204), and the list ML (C) is reset (3206). ).

Then, a loop is started to queue all the possible interactions between the children of the node C. Thus, the two immediate-son nodes A and B are recovered by a function CH () in 3208, and their OBB respective OBBA and OBBB are recovered in 3210.

The pair (OBBA, OBBB) is then stacked in a Q list (3212), which serves as a storage stack for potential interactions between OBBs. The mentioned loop has the condition of stopping the emptying of the stack Q (3214), and the function Upd_Int_L (C) stops when this condition is fulfilled (3216).

The loop starts with an unstacking of the list Q, which makes it possible to recover the last potential interaction torque (OBBE, OBBF) introduced in Q (3218). During the first iteration of this loop, it is obviously the pair (OBBA, OBBB) of step 3212.

In 3220, an Upd_Pos () function updates the OBB OBBE and OBBF OBBF real-world positions, in order to establish their eventual collision. This "real" position update is distinct from that performed in the Upd_OBB () function 30, which updates the relative position of each OBB in the repository of its node.

The distinction between real position and relative position makes it possible to implement the algorithm in a more efficient and integrated way. It would nevertheless be possible to update the actual position of the OBBs directly in the Upd OBBQ function 30. In 3222, the Coll () function determines whether OBBE and OBBF collide, that is, if their oriented boxes have an intersection. If this is not the case, then there is no local interaction, and the loop is reset to 3214 to test the next potential interaction.

In the case where OBBE and OBBF, which are associated with respective nodes E and F, are in collision, four possibilities exist:

a) E and F are both leaves of the tree, which means that these objects interact with each other, and that the function stops;

b) F is an articulated object and E is a leaf, which means that it is necessary to explore F to determine the interactions of its child nodes with the object associated with E, then to determine the interactions of the child nodes of F between them;

c) E is an articulated object and F is a leaf, which means that it is necessary to explore E to determine the interactions of its child nodes with the object associated with F, then to determine the interactions of the child nodes of E between them; and

d) E and F are both articulated objects, which means that E and F must be explored to determine the interactions between their respective child nodes, and then determine the interactions of the child nodes of E and F between them.

For this, a test 3224 determines if E is a leaf node, by calling a function CH_OBB () with OBBE. The CH_0BB () function is similar to the CH () function, except that it takes an OBB input instead of a node.

If E is a leaf node, the function DPl () is called at 3230, which handles cases a) and b). An exemplary implementation of the function DP1 () is shown in Figure 5. In this function, a test 3232 determines if F is a leaf node, calling the function CH_OBB () with OBBF. If F is a leaf node, then the case a) applies, and the list Int L (C) receives the pair (E, F) at 3234, the function DP1 () stops at 3236, and the loop of Upd Ιnt L (C) resumes in 3214 with the Q battery test.

If F is an articulated object, then FA and FB are his sons, and case b) applies. To determine the interactions of the son of F with E, the OBBs of FA and FB are recovered at 3238, and two potential interactions (OBBE, OBBFA) at 3240 and (OBBE, OBBFB) are then stacked at 3242 in the Q stack.

Then, the interactions of the F wires between them are determined by calling Upd_Int_L () with F at 3244. This function call is used to update the Upd Old L (F) and Upd L (F) lists. Finally the function DP1 () stops at 3236, and the loop of Upd Ιnt L (C) resumes at 3214 with the test of the stack Q.

If E is an articulated object, then EA and EB are his sons. Then a function DP2 () is called in 3250, which handles cases c) and d). An example of implementation of the function DP2 () is shown in FIG.

In this function, a test 3252 determines if F is a leaf node, calling the function CH_OBB () with OBBF.

If F is a leaf node, then we are in case c). To determine the interactions of the son of E with F, the OBBs of EA and EB are retrieved at 3254, and two potential interactions (OBBEA, OBBF) at 3256 and (OBBEB, OBBF) are stacked at 3258 in the Q stack.

Then, the interactions of the E wires between them are determined by calling Upd_Int_L () with E at 3260. This function call is used to update the Upd_01d_L (E) and Upd_L (E) lists. Finally, the DP2 () function stops at 3262, and the Loop of Upd_Int_L (C) resumes at 3214 with the Q battery test. If F is an articulated object, then FA and FB are his sons, and case d) applies. To determine the interactions of the threads of E with those of F, we call a function Max_Vol () with OBBE and OBBF at 3264.

The Max_Vol () function determines which of OBBE and OBBF has the largest volume, in order to explore the thread interactions of the node associated with the other node. This optimizes the performance of Upd_Int_L ().

As a result, three OBBs, OBBMAs, OBBMBs and OBBMin are obtained. Thus, if OBBE is larger than OBBF, then OBBMA contains OBBEA, OBBMB contains OBBEB, and OBBMin contains OBBF. In the opposite case, OBBMA contains OBBFA, OBBMB contains OBBFB and OBBMin contains OBBE.

Two potential interactions (OBBMA, OBBMin) are then stacked at 3266 and (OBBMB, OBBMin) at 3268 in the Q stack. Then the interactions of the E wires between them are determined by calling Upd_Int_L () with E at 3270, and those wires of F between them are determined by calling Upd_Int_L () with F in 3272.

These function calls are used to update the Old Upd (L), Upd L (E), Upd_01d_L (F), and Upd_L (F) lists. Finally, the DP2 () function stops at 3262, and the Upd Ιnt L (C) loop resumes at 3214 with the Q battery test.

As it appears implicitly, the function Upd_Int () applied to a node C thus presents two nested recursions.

The first recursion relates to the stacking and unstacking of the stack Q, so as to analyze all the potential interaction pairs between the wires of the node C, whatever their level of depth with respect to this node.

The second recursion concerns the selective calling of the function Upd_Int () with child nodes of C, which makes it possible to update the lists Upd_01d_L () and Upd_L () of all the active nodes. The determination of local interactions in the binary tree is mainly based on OBB properties, as discussed above. However, although OBBs are an interesting tool, other tools can be used, such as interaction prediction tables, or other suitable tools that the skilled person will consider in view of the application concerned.

When the Upd_Old_L () and Upd_L () lists have been updated for all active nodes, the interaction data is ready to be updated with the Upd_Int_Val () 34 function.

An implementation of the function Upd_Int_Val () is shown in Figure 7. As seen in this figure, this function starts with a recursive block 700. By calling the function Upd_Int_Val () with the node RN, the block 700 performs a descent in the binary tree.

Block 700 begins at 702 with an activity test of the current node C, as previously described. If the current node is inactive, then the function ends in 704. If the current node is active, the descent into the tree is started by getting children A and B of this node by the CH () function at 706.

Then an activity test is performed on the left son A of C, as previously described in 708. If node A is active, then the descent to the left is done at 710, calling Upd_Int_Val () with A.

Then, an activity test is carried out on the right wire B of C, as previously described, in 712. If A is inactive, then the test 712 is carried out directly, and there is no descent to the left for the node C.

If node B is active, then the descent to the right is done at 714, calling Upd_Int_Val () with B. This is then the end of the recursive descent block 700, and the function continues with its effective part of processing. If B is inactive, then there is no descent to the right for the node C, the block 700 ends, and the function continues with its effective part of treatment.

Once block 700 has been repeated and recursions have been completed, data processing begins at node C by resetting a list Upd (C) and a stack Q at 720.

The list Upd (C) is used to progressively bring up updated interaction data from data updated in the C wires during recursive calls made using block 700.

The list Q serves as an object storage stack whose interaction data must be updated at the current node. Thus, the list Q receives lists Upd (A), Upd (B), Int Old L (C), and Int L (C) in 722. Note that, although Int Old L (C), and IntJL ( C) contain pairs of nodes and not nodes, one skilled in the art will recognize that the operation 722 is to stack in Q only nodes distinct from each other.

An interaction data feedback loop then begins at 724, with the Q list being unstacked in a work node R. The work node R is added to the list Upd (C) in 726, to ensure the recovery of the data. data associated with it when unstacking the recursions of the block 700, then a test 728 is performed to determine if R belongs to the subset of objects designated by A, or that designated by B.

If R belongs to the subset of objects designated A, then the interaction data F (C, R) is reset with the value of F (A, R) in 730. Otherwise, F (C, R) is reset with the value of F (B, R) in 732. Finally, a test on Q at 734 indicates whether all the object interaction data of Q has been reset or not.

When Q is empty, an interaction data update loop begins at 736 with unstacking of a list Int_L_t (C). The list Int_L_t (C) is a working copy Int L (C), and is used only for the update loop. The unstacking result of the list Int L t (C) is stored in a pair of working nodes (P, T).

In 738, the interaction data F (C, P) is updated by adding to the value of F (C, P) reset in the above loop the value F (P, T) of the interaction of T on P. The value of F (P, T) is calculated, by means of a function F_Int (), and gives the intensity of the inter-atomic interaction of P with T, in the frame of P. This same operation is carried out in 740 with T, by adding to the value of F (C, T) reset in the above loop the value F (T, P) of the interaction of P on T, in the reference frame of T .

The function F_Int () is based on the well-known formulas of electrostatic interaction and van der Waals between two atoms / molecules. Other formulas can of course be used. It is important to note that F_Int () calculates the interactions in the coordinate system associated with the first invoked node.

Then, in 742 a test checks if Int L t (C) has been completely unstacked. If this is the case, the relevant instance of Upd_Int_Val () terminates at 744. Otherwise, the update loop resumes at 736. After the list Int L t (C) has been completely unpacked, the data of interactions F (C, X), where X is a leaf node descending from C, represent the set of interactions undergone by node X by all the other leaf nodes that are descendants of C.

It is clear from the above that the function Upd_Int_Val () has a bottom-up approach, although it is invoked with the root node. It also appears that this function brings up, step by step, all the interactions experienced by each leaf node of a node C by the other leaf nodes of C.

Finally, this function also keeps track of the nodes whose interaction data were updated using the list Upd (). Thus, when the function Upd_Int_Val () ends, the root node RN contains firstly all the interaction data on its leaf nodes, but also the list of interaction data. that have been updated in the current loop, which ensures access only to nodes that have actually evolved.

Once the function Upd_Int_Val () is finished, the function Upd_Int () ends. As shown in Figure 2, the function Upd_Int () is followed by the Sprd_Int () function in the simulation loop. The Sprd_Int () function is called with the root node RN, as its list Upd (RN) includes all the interaction data that has been modified by the function Upd lntQ.

An example of implementation of this function is shown in Figure 8. The Sprd_Int () function is a loop that starts with a test 802 on the list Upd (C) of the input node. If this list is empty, the function ends in 804.

When the list Upd (C) is not empty, an element R is depilated at 806, the interaction data F (R, R) of the corresponding node is updated to the value F (C, R) at 808.

Then, a Set_Flg () function stores Flg bph data associated with R at 810. The value of the Flg_bph data signals the need to update the dynamic coefficients b, p and η. The Set FlgO function also records Flg bph data for all ancestors of the R node, up to the root node RN. The loop then resumes in 802, until the list Upd (C) is empty.

Note that the Sprd_Int () function can be implemented in many ways. In particular, the updated interaction data is here stored in the concerned node. However, it would be possible to store these interactions at another place, in a separate table for example. The same goes for the data recorded by the Set_Flg () function.

It would also be possible not to perform this function, and to be satisfied with a call to the list Upd (RN) adequately where necessary, although this would result in a certain lack of clarity and introduce a relative complexity of management.

When the interaction data has been updated, the simulation loop is extended with the Get_Dyn_Coeff () function, which is used to determine the dynamic parameters of the objects and nodes of the tree.

An example implementation of the Get_Dyn_Coeff () function is shown in Figure 9. The Get_Dyn_Coeff () function is a bottom-up function, like the function Upd_Int_Val (). To obtain this propagation, a test 902 checks whether node C has child nodes A and B.

If node C does not have child nodes, a test 904 checks if the data Flg bph (C) is activated. If this is the case, then the node C is a leaf node for which a function Coeff_bphl () is called in 906, a function which puts p (C) and η (C) to 0, and which calculates b (C) to from the updated interaction data F (C, C). After step 906, or if the data Flg bph (C) is not activated, the function ends at 908.

If node C has some wires, the function Get_Coeff_Dyn () is called recursively with A and B at 910 and 912. This ensures a path of the necessary nodes of the binary tree from bottom to top. Once all the recursive calls have been started and all the necessary leaf nodes have been processed, a recovery of the tree is made, recursion loop recursion loop, in a block 920.

In block 920, a first test 922 checks whether the current node C is active. If this is the case, then the coefficients Φ (C) and Ψ (C) are calculated at 924 by calling a function Coeff_phipsi () with the values of these coefficients for the children of C, namely A and B. Then, the coefficients b (C), p (C) and η (C) are computed at 926 by calling a function Coeff_bph (), with the values of these coefficients for the children of C, namely A and B. Finally, the function ends in 928. In the case where the current node C is inactive, a test is performed on the data Flg bph (C) at 930. In the case where the test is negative, the function ends directly in 928. If this test is positive, that is, if the data indicates that it is necessary to update the coefficients b (C), p (C) and η (C), then these are calculated as 932 by calling the function Coeff_bph ( ) with the values of these coefficients for the children of C, namely A and B. Finally, the function ends in 928.

The formulas (l) to (13) of Annex A give the formula of the calculation on the basis of which these coefficients are established in the functions Coeff_phipsi () and Coeff_bph (). For the purposes of the present description, it is sufficient to know that these recursively determined coefficients make it possible to locally describe the behavior of the articulated bodies, and serve as a basis for calculations of metric, acceleration and position of the simulation. For more information, SPM '05 and SIGGRAPH '05 explain the precise definition and obtaining of these equations. The applicant recommends that these documents be consulted for this purpose.

It will be noted in particular that the calculation of the coefficients b (C), p (C) and η (C) can directly and indirectly involve a quantity Q which represents an active force data on the articulation of a node C. This Q size can be used, for example, to represent a torque dependent dihedral angle. Since the calculation of the quantity Q associated with the node C depends only on the relative position of the wires A and B of C, this quantity is updated only for the active nodes. Thus, this update can be done, for example, immediately before the calculation of b (C), p (C) and η (C) by the function Coeff_bph ().

When the dynamic coefficients have been updated, the Upd_Dyn () function updates the dynamic data based on these coefficients. An example implementation of the Upd_Dyn () function is shown in Figure 10.

The function Upd_Dyn () shown in Figure 10 is a recursive function that traverses the binary tree from top to bottom. This function uses a priority queue to optimize the determination of the active nodes, as will appear below. For this, a test 1002 on the current node calls an acceleration metric calculation 1003 if the current node is the root node RN. The result serves as a basis at 1004 for a terminal ε which serves as a stop condition at 1006.

The acceleration metric calculation is performed by a function Tot_Acc () which performs the calculation described with the formula 21 of Annex A, and which corresponds to the sum of the squares of the accelerations of the child nodes of the current node. This allows you to define active and inactive nodes.

Indeed, εmax defines the simulation accuracy sought in terms of acceleration metrics. So, if ε <εmax, it means that the desired precision is reached. The acceleration of the node C qdd (C) is then not calculated, and the function ends in 1010.

On the other hand, if ε> εmax, the simulation is not considered as yet precise enough. In 1012, a test determines whether node C has threads or not. If this is not the case, the function ends in 1010.

An Active Flg function (C) is then called at 1014. The Active_Flg () function records data that contains a time marker that is associated with the current simulation loop. It is this time marker that is used in the activity tests of a node. For this, for the given node, the possible time marker associated with the time marker of the current loop is compared. When there is concomitance, then the node is considered active. A similar method can be used to enable Flg bph (C) data.

If the node C has children A and B, the acceleration of the node C qdd (C) is calculated in 1016 by means of the function Q_Dot. The Q_Dot () function uses the dynamic coefficients Φ (C) and b (C), as well as a force F (C). The calculation performed by the Q_Dot () function is explained by Equation 22 of Appendix A. The force F (C) is a composite vector that represents the set of articulation forces that apply on the node C. For the root node RN, particular conditions make it possible to determine the vector F (C), as described in FIG. SPM '05 section 3.1.2.

As described in SPM '05 section 3.1.1, a vector F (C) has two components: F (I, C) and F (2, C). In the context of the invention, the vector F (C) of a node is used to calculate the vector of its child nodes F (A) and F (B).

Indeed, if we consider the two son A and B of C, then the force F (I, C) is equal to F (I, A), and the force F (2, C) is equal to F (2, B). In addition, the F (2, A) and F (I, B) components can also be obtained from F (C) as described below. Therefore the components of F (A) and F (B) can be obtained totally from F (C).

Once the acceleration of the node C has been calculated, the function Upd_Dyn () continues in 1018 and in 1020 with the computation of the vectors F (2, A) and F (I, B) by means of the function Ch_F () according to the formula 23 of Annex A.

Then, the acceleration metrics of the nodes A and B are calculated at 1022 and 1024, and the nodes A and B are entered at 1026 in a queue of priority Q_prio according to the values of Acc (A) and Acc (B). In 1028, the square value of the acceleration qdd (C) is removed at ε to update the accuracy of the simulation. Finally, a node R is pared from the queue Q_prio at 1030, and the function Upd_Dyn () is called with R at 1032 to ensure the recursion of the function and the descent into the tree.

The queue Q_prio classifies the nodes according to the value of their acceleration metric, in order to quickly determine the most important nodes. Thus, since the acceleration metric of a node represents the sum of the squares of the accelerations of its threads, the function progressively descends into the nodes that will bring down ε the fastest, which speeds up the simulation. Note that this function performs two tasks simultaneously. Indeed, the activity of a node is based on the value of the acceleration metric. The non-computation of the accelerations of some nodes, and the use of the Active_Flg () data thus also makes it possible to separate them from the following loops which take into account the activity, without additional computation cost.

This is made possible by the fact that the functions that traverse the tree from bottom to top begin to descend recursively in the active nodes only.

Therefore, all of the above functions, through its selection of active nodes, provide a minimal path of the tree, and is a selective update of the data of some of the nodes.

Note also that the accuracy of the simulation is here ensured by means of the parameter εmax which represents the maximum error of acceleration. Other means may be employed, such as specifying the number of nodes to be simulated, or other metrics.

When dynamic data update has been performed, the function Upd_Geo () completes the simulation loop. Indeed, as mentioned above, the interaction data in the nodes are calculated with respect to a particular local coordinate system at each node.

In fact, the accelerations of the nodes and the positions that can be derived are also relative, or intrinsic. To be able to display the result of the simulation and to be able to trace (or go back down) the data in the various traverses of the tree, matrices of passage that we have not discussed so far are necessary. It is these passing matrices that are used to calculate the actual position of the OBBs in the Upd_Pos () function of FIG. 4, or else to update the force F (C, R) in the steps 732 and 734 of FIG. 7. To update these matrices, the function Upd_Geo () starts in 1102 with a subfunction Upd_Hyb_qdd (). The function Upd_Hyb_qdd () calculates dynamic coefficients corrected to take into account the stiffening performed with the function Upd_Dyn (). Then, the accelerations qdd (C) of the nodes are recalculated with the corrected dynamic coefficients. The operations performed by this function, as well as their integration in the calculation of qdd (C) are described in the article SIGGRAPH '05, sections 4 and 5.

Although it is described in the preferred embodiment of the invention, the function Upd_Hyb_qdd () _ is not necessarily necessary in all cases. Optionally, the function Upd_Geo () may not contain this function and proceed directly to 1104.

The function Upd_Geo () continues in 1104 with a function Upd_qpos (), which updates the intrinsic positions of the nodes based on their accelerations. This calculation is simple and represents a basic temporal integration corresponding to equation 14 of Appendix A. Other methods can be used for updating the intrinsic positions of the nodes, for example involving additional accelerations calculations. .

Finally, the function Upd_Geo () ends in 1106 with the function Upd_CT_Mat (), which updates the internal matrices mentioned above based on the updated intrinsic positions of the nodes. These matrices and their update are described further in section 5 of SPM '05. In the above, the interaction and geometry data are mainly calculated intrinsically, that is to say with respect to a local coordinate system associated in each case with the node concerned.

This makes it unnecessary to recalculate data that depends only on the relative positions of the objects, such as the coefficients Φ (C) and Ψ (C) and the local interaction forces. Thus, the transition to the coordinates of the real world is only necessary for the calculation of the real positions of the nodes. In other embodiments, it would be possible to operate on real-world coordinate data each time, retaining intrinsic data only for nodes that are not active.

Although the present invention has been described with respect to the representation by means of a binary tree, it would be possible to use other types of tree, for example ternary or even n-ary. It would also be possible to use other types of representations, since they make it possible to differentiate between active nodes and inactive nodes with a comparable path cost.

The above functions present the main steps of implementation of the invention. They can be used by those skilled in the art as a basis for writing a computer program implementing the invention. Such a program can be written in C ++ or any other appropriate computer language as will be recognized by the skilled person.

ANNEX A

SECTION 1

with where S is the subspace of movement of the node, of dimension 6 x number of degrees of freedom of the node. Typically, S = (0, 0, 1, 0, 0, 1) ^τ .

with

Note: The matrices Φ (C) and Φ (C) are matrix matrices. APPENDIX A (continued)

SECTION 2

with where Q is the number vector of degrees of freedom x 1 of the active forces of the node.

with APPENDIX A (continued)

SECTION 3

Claims

claims

A computer device for the simulation of a set of interacting objects, comprising: a memory (8) capable of containing a tree representation of the set of objects, where each intermediate node is associated with dynamic data; , geometric data, and data dependent interaction data of its child nodes, and

a simulation controller (4), for operating according to a repetitive cycle: + a distributor (10) of the interaction data on the objects and subsets of objects,

+ a dynamic data update mechanism (12), with a tree representation path for interacting subject nodes, as a function of the interaction data and the geometric data concerned, + a mechanism for updating the geometric data (14), with traversal of the tree representation for interacting nodes, based on the updated dynamic data, characterized in that

the memory (8) furthermore comprises local interaction data, associated with some or fewer nodes,

the distributor (10) of the interaction data comprises an interaction updating mechanism (20), with traversing of the tree representation for interacting subject nodes, for updating an interaction data item of a node based on the local interaction data of the relevant child nodes.

2. Device according to claim 1, characterized in that:

the local interaction data comprise an interaction list comprising pairs designating nodes in local interaction, and

the mechanism for updating the interaction data comprises: a function for updating the interaction list data (32),

+ an interaction data update function (34), based on at least some of the updated interaction list data.

3. Device according to claim 2, characterized in that:

the memory comprises, for at least some of the nodes, oriented box data representing an interaction space around an associated node, and

the mechanism for updating the interaction data further comprises a function for updating the boxed data (30), the function of updating the interaction lists operating on the basis of at least some of the Oriented box data updated.

4. Device according to one of the preceding claims, characterized in that: - the memory comprises, for some at least nodes, dynamic coefficient data, and

the mechanism for updating the dynamic data comprises:

+ a dynamic coefficient data update function (26), and + a dynamic data update function (28), based on the updated dynamic coefficient data.

5. Device according to one of the preceding claims, characterized in that:

the storage memory comprises, for at least some nodes, data representing an activity marker (Active_Flg ()), the dynamic data updating mechanism (12) is furthermore capable of updating the activity marker (Active_Flg ()) of a node it processes, and

in that at least one of the interaction data update mechanism, the dynamic data mechanism, and the geometric data update mechanism is arranged to traverse the tree representation by ignoring the unmarked active nodes. .

A method of simulating the behavior of a set of interacting objects, in which a tree representation of the set of objects is maintained, wherein each intermediate node is associated with dynamic data, geometric data and data of a plurality of objects. dependent interaction of data of its child nodes, and a cycle comprising the following steps is repeated: a. distribute the interaction data on some of the objects and subsets of objects, b. traversing the tree representation for interacting nodes while updating dynamic data of those nodes, based on the interaction data and geometric data concerned, and c. again browsing the tree representation for interacting subject nodes, while updating geometric data, based on the dynamic data as updated in step b., characterized in that step a. includes: al. a preliminary path of the tree representation for interacting nodes, with the update of the interaction data of these nodes, as a function of local interaction data of concerned child nodes.

7. Simulation method according to claim 6, characterized in that step a1 comprises: a. updating interaction lists forming local interaction data, associated with at least some of the nodes, each interaction list comprising pairs of nodes in local interaction, alb. updating the interaction data, based on the updated interaction lists.

8. Simulation method according to claim 7, characterized in that step ai l. includes: a IaI. updating oriented box data associated with at least some of the nodes, the oriented box data representing an interaction space around an associated node, and ala2. updating interaction lists based on updated oriented box data.

9. Method according to one of claims 6 to 8, characterized in that at least one of the steps a, b and c comprises the path of the tree representation ignoring at least some of the nodes, according to a marker d activity associated with at least some nodes.

A computer program product comprising portions / means / program code instructions for performing the steps of the method according to one of claims 6 to 9 when said program is executed on a computer.