1 | README for GeomTransformGroup by Tim Schmidt. |
---|
2 | --------------------------------------------- |
---|
3 | |
---|
4 | This is a patch to add the dGeomTransformGroup object to the list of geometry |
---|
5 | objects. |
---|
6 | |
---|
7 | It should work with the cvs version of the ode library from 07/24/2002. |
---|
8 | |
---|
9 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
---|
10 | |
---|
11 | comment by russ smith: this code is easy to use with the rest of ODE. |
---|
12 | simply copy GeomTransformGroup.cpp to ode/src and copy GeomTransformGroup.h |
---|
13 | to include/ode. then add GeomTransformGroup.cpp to the ODE_SRC variable |
---|
14 | in the makefile. rebuild, and you're done! of course i could have done all |
---|
15 | this for you, but i prefer to keep GeomTransformGroup separated from the |
---|
16 | rest of ODE for now while other issues with the collision system are |
---|
17 | resolved. |
---|
18 | |
---|
19 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
---|
20 | |
---|
21 | |
---|
22 | Description: |
---|
23 | |
---|
24 | The dGeomTransformGroup is an adaption of the TransformGroup known from |
---|
25 | Java3D (and maybe other libraries with a similar scene graph representation). |
---|
26 | It can be used to build an arbitrarily structured tree of objects that are |
---|
27 | each positioned relative to the particular parent node. |
---|
28 | |
---|
29 | If you have a plane for example, there is one root node associated with the |
---|
30 | plane's body and another three transformgroups placed 'under' this node. One |
---|
31 | with the fuselage (cappedcylinder) under it and two with the underlying wings |
---|
32 | (flat boxes). And if you want to add engines, simply put them 'next to' the |
---|
33 | wings under another two transformgroups. |
---|
34 | |
---|
35 | bodyTG ---> associated with dBody |
---|
36 | | |
---|
37 | +--fuselageTG |
---|
38 | | | |
---|
39 | | +--fuselageCylinder |
---|
40 | | |
---|
41 | +--leftwingTG |
---|
42 | | | |
---|
43 | | +--wingBox |
---|
44 | | | |
---|
45 | | +--leftengineTG |
---|
46 | | | |
---|
47 | | +--leftengineCylinder |
---|
48 | | |
---|
49 | +--rightwingTG |
---|
50 | | |
---|
51 | +--wingBox |
---|
52 | | |
---|
53 | +--rightengineTG |
---|
54 | | |
---|
55 | +--rightengineCylinder |
---|
56 | |
---|
57 | This is a method to easily compose objects without the necessity of always |
---|
58 | calculating global coordinates. But apart from this there is something else |
---|
59 | that makes dGeomTransformGroups very valuable. |
---|
60 | |
---|
61 | Maybe you remember that some users reported the problem of acquiring the |
---|
62 | correct bodies to be attached by a contactjoint in the nearCallback when |
---|
63 | using dGeomGroups and dGeomTransforms at the same time. This results from the |
---|
64 | fact that dGeomGroups are not associated with bodies while all other |
---|
65 | geometries are. |
---|
66 | |
---|
67 | So, as you can see in the nearCallback of the the test_buggy demo you have to |
---|
68 | attach the contactjoint with the bodies that you get from the geometries that |
---|
69 | are stored in the contact struct (-> dGeomGetBody(contacts[i].geom.g1)). |
---|
70 | Normally you would do this by asking o1 and o2 directly with dGeomGetBody(o1) |
---|
71 | and dGeomGetBody(o2) respectively. |
---|
72 | |
---|
73 | As a first approach you can overcome that problem by testing o1 and o2 if |
---|
74 | they are groups or not to find out how to get the corresponding bodies. |
---|
75 | |
---|
76 | However this will fail if you want grouped transforms that are constructed |
---|
77 | out of dGeomTransforms encapsulated in a dGeomGroup. According to the test |
---|
78 | you use contacts[i].geom.g1 to get the right body. Unfortunately g1 is |
---|
79 | encapsulated in a transform and therefore not attached to any body. In this |
---|
80 | case the dGeomTransform 'in the middle' would have been the right object to |
---|
81 | be asked for the body. |
---|
82 | |
---|
83 | You may now conclude that it is a good idea to unwrap the group encapsulated |
---|
84 | geoms at the beginning of the nearcallback and use dGeomGetBody(o1) |
---|
85 | consistently. But keep in mind that this also means not to invoke |
---|
86 | dCollide(..) on groups at all and therefore not to expoit the capability of |
---|
87 | dGeomGroups to speed up collision detection by the creation of bounding boxes |
---|
88 | around the encapsulated geometry. |
---|
89 | |
---|
90 | Everything becomes even worse if you create a dGeomTransform that contains a |
---|
91 | dGeomGroup of geoms. The function that cares about the collision of |
---|
92 | transforms with other objects uses the position and rotation of the |
---|
93 | respective encapsulated object to compute its final position and orientation. |
---|
94 | Unfortunately dGeomGroups do not have a position and rotation, so the result |
---|
95 | will not be what you have expected. |
---|
96 | |
---|
97 | Here the dGeomTransformGroups comes into operation, because it combines the |
---|
98 | advantages and capabilities of the dGeomGroup and the dGeomTransform. |
---|
99 | And as an effect of synergy it is now even possible to set the position of a |
---|
100 | group of geoms with one single command. |
---|
101 | Even nested encapsulations of dGeomTransformGroups in dGeomTransformGroups |
---|
102 | should be possible (to be honest, I have not tried that so far ;-) ). |
---|
103 | |
---|
104 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
---|
105 | |
---|
106 | API: |
---|
107 | |
---|
108 | dGeomID dCreateGeomTransformGroup (dSpaceID space); |
---|
109 | - create a GeomTransformGroup |
---|
110 | |
---|
111 | void dGeomTransformGroupAddGeom (dGeomID tg, dGeomID obj); |
---|
112 | - Comparable to dGeomTransformSetGeom or dGeomGroupAdd |
---|
113 | - add objects to this group |
---|
114 | |
---|
115 | void dGeomTransformGroupRemoveGeom (dGeomID tg, dGeomID obj); |
---|
116 | - remove objects from this group |
---|
117 | |
---|
118 | void dGeomTransformGroupSetRelativePosition |
---|
119 | (dGeomID g, dReal x, dReal y, dReal z); |
---|
120 | void dGeomTransformGroupSetRelativeRotation |
---|
121 | (dGeomID g, const dMatrix3 R); |
---|
122 | - Comparable to setting the position and rotation of all the |
---|
123 | dGeomTransform encapsulated geometry. The difference |
---|
124 | is that it is global with respect to this group and therefore |
---|
125 | affects all geoms in this group. |
---|
126 | - The relative position and rotation are attributes of the |
---|
127 | transformgroup, so the position and rotation of the individual |
---|
128 | geoms are not changed |
---|
129 | |
---|
130 | const dReal * dGeomTransformGroupGetRelativePosition (dGeomID g); |
---|
131 | const dReal * dGeomTransformGroupGetRelativeRotation (dGeomID g); |
---|
132 | - get the relative position and rotation |
---|
133 | |
---|
134 | dGeomID dGeomTransformGroupGetGeom (dGeomID tg, int i); |
---|
135 | - Comparable to dGeomGroupGetGeom |
---|
136 | - get a specific geom of the group |
---|
137 | |
---|
138 | int dGeomTransformGroupGetNumGeoms (dGeomID tg); |
---|
139 | - Comparable to dGeomGroupGetNumGeoms |
---|
140 | - get the number of geoms in the group |
---|
141 | |
---|
142 | |
---|
143 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
---|
144 | |
---|
145 | Tim Schmidt |
---|
146 | student of computer science |
---|
147 | University of Paderborn, Germany |
---|
148 | tisch@uni-paderborn.de |
---|