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