1 | Dynamics Library. |
---|
2 | ================= |
---|
3 | |
---|
4 | CONVENTIONS |
---|
5 | ----------- |
---|
6 | |
---|
7 | matrix storage |
---|
8 | -------------- |
---|
9 | |
---|
10 | matrix operations like factorization are expensive, so we must store the data |
---|
11 | in a way that is most useful to the matrix code. we want the ability to update |
---|
12 | the dynamics library without recompiling applications, e.g. so users can take |
---|
13 | advantage of new floating point hardware. so we must settle on a single |
---|
14 | format. because of the prevalence of 4-way SIMD, the format is this: store |
---|
15 | the matrix by rows or columns, and each column is rounded up to a multiple of |
---|
16 | 4 elements. the extra "padding" elements at the end of each row/column are set |
---|
17 | to 0. this is called the "standard format". to indicate if the data is stored |
---|
18 | by rows or columns, we will say "standard row format" or "standard column |
---|
19 | format". hopefully this decision will remain good in the future, as more and |
---|
20 | more processors have 4-way SIMD, and 3D graphics always needs fast 4x4 |
---|
21 | matrices. |
---|
22 | |
---|
23 | exception: matrices that have only one column or row (vectors), are always |
---|
24 | stored as consecutive elements in standard row format, i.e. there is no |
---|
25 | interior padding, only padding at the end. |
---|
26 | |
---|
27 | thus: all 3x1 floating point vectors are stored as 4x1 vectors: (x,x,x,0). |
---|
28 | also: all 6x1 spatial velocities and accelerations are split into 3x1 position |
---|
29 | and angular components, which are stored as contiguous 4x1 vectors. |
---|
30 | |
---|
31 | ALL matrices are stored by in standard row format. |
---|
32 | |
---|
33 | |
---|
34 | arguments |
---|
35 | --------- |
---|
36 | |
---|
37 | 3x1 vector arguments to set() functions are supplied as x,y,z. |
---|
38 | 3x1 vector result arguments to get() function are pointers to arrays. |
---|
39 | larger vectors are always supplied and returned as pointers. |
---|
40 | all coordinates are in the global frame except where otherwise specified. |
---|
41 | output-only arguments are usually supplied at the end. |
---|
42 | |
---|
43 | |
---|
44 | memory allocation |
---|
45 | ----------------- |
---|
46 | |
---|
47 | with many C/C++ libraries memory allocation is a difficult problem to solve. |
---|
48 | who allocates the memory? who frees it? must objects go on the heap or can |
---|
49 | they go on the stack or in static storage? to provide the maximum flexibility, |
---|
50 | the dynamics and collision libraries do not do their own memory allocation. |
---|
51 | you must pass in pointers to externally allocated chunks of the right sizes. |
---|
52 | the body, joint and colllision object structures are all exported, so you |
---|
53 | can make instances of those structure and pass pointers to them. |
---|
54 | |
---|
55 | there are helper functions which allocate objects out of areans, in case you |
---|
56 | need loots of dynamic creation and deletion. |
---|
57 | |
---|
58 | BUT!!! this ties us down to the body/joint/collision representation. |
---|
59 | |
---|
60 | a better approach is to supply custom memory allocation functions |
---|
61 | (e.g. dlAlloc() etc). |
---|
62 | |
---|
63 | |
---|
64 | C versus C++ ... ? |
---|
65 | ------------------ |
---|
66 | |
---|
67 | everything should be C linkable, and there should be C header files for |
---|
68 | everything. 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 | |
---|
73 | WORLDS |
---|
74 | ------ |
---|
75 | |
---|
76 | might want better terminology here. |
---|
77 | |
---|
78 | the dynamics world (DWorld) is a list of systems. each system corresponds to |
---|
79 | one or more bodies, or perhaps some other kinds of physical object. |
---|
80 | each 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 |
---|
82 | collision objects). |
---|
83 | |
---|
84 | systems are simulated separately, perhaps using completely different |
---|
85 | techniques. we must do something special when systems collide. |
---|
86 | systems collide when collision objects belonging to system A touch |
---|
87 | collision objects belonging to system B. |
---|
88 | |
---|
89 | for each collision point, the system must provide matrix equation data |
---|
90 | that is used to compute collision forces. once those forces are computed, |
---|
91 | the system must incorporate the forces into its timestep. |
---|
92 | PROBLEM: what if we intertwine the LCP problems of the two systems - then |
---|
93 | this simple approach wont work. |
---|
94 | |
---|
95 | the dynamics world contains two kinds of objects: bodies and joints. |
---|
96 | joints connect two bodies together. |
---|
97 | |
---|
98 | the world contains one of more partitions. each partition is a collection of |
---|
99 | bodies and joints such that each body is attached (through one or more joints) |
---|
100 | to every other body. |
---|
101 | |
---|
102 | Joints |
---|
103 | ------ |
---|
104 | |
---|
105 | a joint can be connected to one or two bodies. |
---|
106 | if the joint is only connected to one body, joint.node[1].body == 0. |
---|
107 | joint.node[0].body is always valid. |
---|
108 | |
---|
109 | |
---|
110 | Linkage |
---|
111 | ------- |
---|
112 | |
---|
113 | this 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 | |
---|
118 | Optimization |
---|
119 | ------------ |
---|
120 | |
---|
121 | doubles must be aligned on 8 byte boundaries! |
---|
122 | |
---|
123 | |
---|
124 | MinGW 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 | |
---|
137 | Collision |
---|
138 | --------- |
---|
139 | |
---|
140 | to plug in your own collision handling, replace (some of?) these functions |
---|
141 | with your own. collision should be a separate library that you can link in |
---|
142 | or not. your own library can call components in this collision library, e.g. |
---|
143 | if you want polymorphic spaces instead of a single statically called space. |
---|
144 | |
---|
145 | creating an object will automatically register the appropriate |
---|
146 | class (if necessary). how can we ensure that the minimum amount of code is |
---|
147 | linked in? e.g. only one space handler, and sphere-sphere and sphere-box and |
---|
148 | box-box collision code (if spheres and boxes instanced). |
---|
149 | |
---|
150 | the user creates a collision space, and for each dynamics object that is |
---|
151 | created a collision object is inserted into the space. the collision |
---|
152 | object's pos and R pointers are set to the corresponding dynamics |
---|
153 | variables. |
---|
154 | |
---|
155 | there should be utility functions which create the dynamics and collision |
---|
156 | objects at the same time, e.g. dMakeSphere(). |
---|
157 | |
---|
158 | collision objects and dynamics objects keep pointers to each other. |
---|