aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/libraries/ode-0.9/ode/README
diff options
context:
space:
mode:
authordan miller2007-10-19 05:15:33 +0000
committerdan miller2007-10-19 05:15:33 +0000
commit79eca25c945a535a7a0325999034bae17da92412 (patch)
tree40ff433d94859d629aac933d5ec73b382f62ba1a /libraries/ode-0.9/ode/README
parentadding ode source to /libraries (diff)
downloadopensim-SC_OLD-79eca25c945a535a7a0325999034bae17da92412.zip
opensim-SC_OLD-79eca25c945a535a7a0325999034bae17da92412.tar.gz
opensim-SC_OLD-79eca25c945a535a7a0325999034bae17da92412.tar.bz2
opensim-SC_OLD-79eca25c945a535a7a0325999034bae17da92412.tar.xz
resubmitting ode
Diffstat (limited to 'libraries/ode-0.9/ode/README')
-rw-r--r--libraries/ode-0.9/ode/README158
1 files changed, 158 insertions, 0 deletions
diff --git a/libraries/ode-0.9/ode/README b/libraries/ode-0.9/ode/README
new file mode 100644
index 0000000..dd4596f
--- /dev/null
+++ b/libraries/ode-0.9/ode/README
@@ -0,0 +1,158 @@
1Dynamics Library.
2=================
3
4CONVENTIONS
5-----------
6
7matrix storage
8--------------
9
10matrix operations like factorization are expensive, so we must store the data
11in a way that is most useful to the matrix code. we want the ability to update
12the dynamics library without recompiling applications, e.g. so users can take
13advantage of new floating point hardware. so we must settle on a single
14format. because of the prevalence of 4-way SIMD, the format is this: store
15the matrix by rows or columns, and each column is rounded up to a multiple of
164 elements. the extra "padding" elements at the end of each row/column are set
17to 0. this is called the "standard format". to indicate if the data is stored
18by rows or columns, we will say "standard row format" or "standard column
19format". hopefully this decision will remain good in the future, as more and
20more processors have 4-way SIMD, and 3D graphics always needs fast 4x4
21matrices.
22
23exception: matrices that have only one column or row (vectors), are always
24stored as consecutive elements in standard row format, i.e. there is no
25interior padding, only padding at the end.
26
27thus: all 3x1 floating point vectors are stored as 4x1 vectors: (x,x,x,0).
28also: all 6x1 spatial velocities and accelerations are split into 3x1 position
29 and angular components, which are stored as contiguous 4x1 vectors.
30
31ALL matrices are stored by in standard row format.
32
33
34arguments
35---------
36
373x1 vector arguments to set() functions are supplied as x,y,z.
383x1 vector result arguments to get() function are pointers to arrays.
39larger vectors are always supplied and returned as pointers.
40all coordinates are in the global frame except where otherwise specified.
41output-only arguments are usually supplied at the end.
42
43
44memory allocation
45-----------------
46
47with many C/C++ libraries memory allocation is a difficult problem to solve.
48who allocates the memory? who frees it? must objects go on the heap or can
49they go on the stack or in static storage? to provide the maximum flexibility,
50the dynamics and collision libraries do not do their own memory allocation.
51you must pass in pointers to externally allocated chunks of the right sizes.
52the body, joint and colllision object structures are all exported, so you
53can make instances of those structure and pass pointers to them.
54
55there are helper functions which allocate objects out of areans, in case you
56need loots of dynamic creation and deletion.
57
58BUT!!! this ties us down to the body/joint/collision representation.
59
60a better approach is to supply custom memory allocation functions
61(e.g. dlAlloc() etc).
62
63
64C versus C++ ... ?
65------------------
66
67everything should be C linkable, and there should be C header files for
68everything. but we want to develop in C++. so do this:
69 * all comments are "//". automatically convert to /**/ for distribution.
70 * structures derived from other structures --> automatically convert?
71
72
73WORLDS
74------
75
76might want better terminology here.
77
78the dynamics world (DWorld) is a list of systems. each system corresponds to
79one or more bodies, or perhaps some other kinds of physical object.
80each system corresponds to one or more objects in the collision world
81(there does not have to be a one-to-one correspondence between bodies and
82collision objects).
83
84systems are simulated separately, perhaps using completely different
85techniques. we must do something special when systems collide.
86systems collide when collision objects belonging to system A touch
87collision objects belonging to system B.
88
89for each collision point, the system must provide matrix equation data
90that is used to compute collision forces. once those forces are computed,
91the system must incorporate the forces into its timestep.
92PROBLEM: what if we intertwine the LCP problems of the two systems - then
93this simple approach wont work.
94
95the dynamics world contains two kinds of objects: bodies and joints.
96joints connect two bodies together.
97
98the world contains one of more partitions. each partition is a collection of
99bodies and joints such that each body is attached (through one or more joints)
100to every other body.
101
102Joints
103------
104
105a joint can be connected to one or two bodies.
106if the joint is only connected to one body, joint.node[1].body == 0.
107joint.node[0].body is always valid.
108
109
110Linkage
111-------
112
113this library will always be statically linked with the app, for these reasons:
114 * collision space is selected at compile time, it adds data to the geom
115 objects.
116
117
118Optimization
119------------
120
121doubles must be aligned on 8 byte boundaries!
122
123
124MinGW on Windows issues
125-----------------------
126
127* the .rc file for drawstuff needs a different include, try winresrc.h.
128
129* it seems we can't have both main() and WinMain() without the entry point
130 defaulting to main() and having resource loading problems. this screws up
131 what i was trying to do in the drawstuff library. perhaps main2() ?
132
133* remember to compile resources to COFF format RES files.
134
135
136
137Collision
138---------
139
140to plug in your own collision handling, replace (some of?) these functions
141with your own. collision should be a separate library that you can link in
142or not. your own library can call components in this collision library, e.g.
143if you want polymorphic spaces instead of a single statically called space.
144
145creating an object will automatically register the appropriate
146class (if necessary). how can we ensure that the minimum amount of code is
147linked in? e.g. only one space handler, and sphere-sphere and sphere-box and
148box-box collision code (if spheres and boxes instanced).
149
150the user creates a collision space, and for each dynamics object that is
151created a collision object is inserted into the space. the collision
152object's pos and R pointers are set to the corresponding dynamics
153variables.
154
155there should be utility functions which create the dynamics and collision
156objects at the same time, e.g. dMakeSphere().
157
158collision objects and dynamics objects keep pointers to each other.