1 files changed, 0 insertions, 158 deletions
diff --git a/libraries/ode-0.9/ode/README b/libraries/ode-0.9/ode/README
deleted file mode 100644
index dd4596f..0000000
--- a/libraries/ode-0.9/ode/README
+++ /dev/null
@@ -1,158 +0,0 @@
-Dynamics Library.
-=================
-CONVENTIONS
-----------
-matrix storage
--------------
-matrix operations like factorization are expensive, so we must store the data
-in a way that is most useful to the matrix code. we want the ability to update
-the dynamics library without recompiling applications, e.g. so users can take
-advantage of new floating point hardware. so we must settle on a single
-format. because of the prevalence of 4-way SIMD, the format is this: store
-the matrix by rows or columns, and each column is rounded up to a multiple of
-4 elements. the extra "padding" elements at the end of each row/column are set
-to 0. this is called the "standard format". to indicate if the data is stored
-by rows or columns, we will say "standard row format" or "standard column
-format". hopefully this decision will remain good in the future, as more and
-more processors have 4-way SIMD, and 3D graphics always needs fast 4x4
-matrices.
-exception: matrices that have only one column or row (vectors), are always
-stored as consecutive elements in standard row format, i.e. there is no
-interior padding, only padding at the end.
-thus: all 3x1 floating point vectors are stored as 4x1 vectors: (x,x,x,0).
-also: all 6x1 spatial velocities and accelerations are split into 3x1 position
-  and angular components, which are stored as contiguous 4x1 vectors.
-ALL matrices are stored by in standard row format.
-arguments
---------
-3x1 vector arguments to set() functions are supplied as x,y,z.
-3x1 vector result arguments to get() function are pointers to arrays.
-larger vectors are always supplied and returned as pointers.
-all coordinates are in the global frame except where otherwise specified.
-output-only arguments are usually supplied at the end.
-memory allocation
-----------------
-with many C/C++ libraries memory allocation is a difficult problem to solve.
-who allocates the memory? who frees it? must objects go on the heap or can
-they go on the stack or in static storage? to provide the maximum flexibility,
-the dynamics and collision libraries do not do their own memory allocation.
-you must pass in pointers to externally allocated chunks of the right sizes.
-the body, joint and colllision object structures are all exported, so you
-can make instances of those structure and pass pointers to them.
-there are helper functions which allocate objects out of areans, in case you
-need loots of dynamic creation and deletion.
-BUT!!! this ties us down to the body/joint/collision representation.
-a better approach is to supply custom memory allocation functions
-(e.g. dlAlloc() etc).
-C versus C++ ... ?
------------------
-everything should be C linkable, and there should be C header files for
-everything. but we want to develop in C++. so do this:
-  * all comments are "//". automatically convert to /**/ for distribution.
-  * structures derived from other structures --> automatically convert?
-WORLDS
------
-might want better terminology here.
-the dynamics world (DWorld) is a list of systems. each system corresponds to
-one or more bodies, or perhaps some other kinds of physical object.
-each system corresponds to one or more objects in the collision world
-(there does not have to be a one-to-one correspondence between bodies and
-collision objects).
-systems are simulated separately, perhaps using completely different
-techniques. we must do something special when systems collide.
-systems collide when collision objects belonging to system A touch
-collision objects belonging to system B.
-for each collision point, the system must provide matrix equation data
-that is used to compute collision forces. once those forces are computed,
-the system must incorporate the forces into its timestep.
-PROBLEM: what if we intertwine the LCP problems of the two systems - then
-this simple approach wont work.
-the dynamics world contains two kinds of objects: bodies and joints.
-joints connect two bodies together.
-the world contains one of more partitions. each partition is a collection of
-bodies and joints such that each body is attached (through one or more joints)
-to every other body.
-Joints
------
-a joint can be connected to one or two bodies.
-if the joint is only connected to one body, joint.node[1].body == 0.
-joint.node[0].body is always valid.
-Linkage
-------
-this library will always be statically linked with the app, for these reasons:
-  * collision space is selected at compile time, it adds data to the geom
-    objects.
-Optimization
------------
-doubles must be aligned on 8 byte boundaries!
-MinGW on Windows issues
-----------------------
-* the .rc file for drawstuff needs a different include, try winresrc.h.
-* it seems we can't have both main() and WinMain() without the entry point
-  defaulting to main() and having resource loading problems. this screws up
-  what i was trying to do in the drawstuff library. perhaps main2() ?
-* remember to compile resources to COFF format RES files.
-Collision
---------
-to plug in your own collision handling, replace (some of?) these functions
-with your own. collision should be a separate library that you can link in
-or not. your own library can call components in this collision library, e.g.
-if you want polymorphic spaces instead of a single statically called space.
-creating an object will automatically register the appropriate
-class (if necessary). how can we ensure that the minimum amount of code is
-linked in? e.g. only one space handler, and sphere-sphere and sphere-box and
-box-box collision code (if spheres and boxes instanced).
-the user creates a collision space, and for each dynamics object that is
-created a collision object is inserted into the space. the collision
-object's pos and R pointers are set to the corresponding dynamics
-variables.
-there should be utility functions which create the dynamics and collision
-objects at the same time, e.g. dMakeSphere().
-collision objects and dynamics objects keep pointers to each other.

diff --git a/libraries/ode-0.9/ode/README b/libraries/ode-0.9/ode/README deleted file mode 100644 index dd4596f..0000000 --- a/libraries/ode-0.9/ode/README +++ /dev/null
@@ -1,158 +0,0 @@
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.