文件列表:

ode-0.11.1\aclocal.m4 (315815, 2009-06-09)
ode-0.11.1\autogen.sh (1613, 2009-06-09)
ode-0.11.1\build\.svn\all-wcprops (438, 2009-06-09)
ode-0.11.1\build\.svn\dir-prop-base (29, 2009-06-09)
ode-0.11.1\build\.svn\entries (733, 2009-10-16)
ode-0.11.1\build\.svn\prop-base\premake4.exe.svn-base (53, 2009-06-09)
ode-0.11.1\build\.svn\prop-base\premake4.lua.svn-base (34, 2009-06-09)
ode-0.11.1\build\.svn\text-base\config-default.h.svn-base (4763, 2009-06-09)
ode-0.11.1\build\.svn\text-base\premake4.exe.svn-base (205312, 2009-06-09)
ode-0.11.1\build\.svn\text-base\premake4.lua.svn-base (11755, 2009-06-09)
ode-0.11.1\build\config-default.h (4763, 2009-06-09)
ode-0.11.1\build\premake4.exe (205312, 2009-06-09)
ode-0.11.1\build\premake4.lua (11755, 2009-06-09)
ode-0.11.1\build\RigidBody\Debug\BuildLog.htm (11168, 2009-11-22)
ode-0.11.1\build\RigidBody\Debug\RigidBody.exe.embed.manifest (2048, 2009-11-21)
ode-0.11.1\build\RigidBody\Debug\RigidBody.exe.embed.manifest.res (2112, 2009-11-22)
ode-0.11.1\build\RigidBody\Debug\RigidBody.exe.intermediate.manifest (621, 2009-11-22)
ode-0.11.1\build\RigidBody\Debug\RigidBody.obj (46330, 2009-11-22)
ode-0.11.1\build\RigidBody\Debug\RigidBody.pch (3211264, 2009-11-21)
ode-0.11.1\build\RigidBody\Debug\RigidBody.res (32, 2009-11-22)
ode-0.11.1\build\RigidBody\Debug\stdafx.obj (12277, 2009-11-21)
ode-0.11.1\build\RigidBody\Debug\vc90.idb (257024, 2009-11-22)
ode-0.11.1\build\RigidBody\Debug\vc90.pdb (315392, 2009-11-22)
ode-0.11.1\build\RigidBody\Release\BuildLog.htm (9168, 2009-11-22)
ode-0.11.1\build\RigidBody\Release\mt.dep (69, 2009-11-22)
ode-0.11.1\build\RigidBody\Release\RigidBody.exe.intermediate.manifest (616, 2009-11-22)
ode-0.11.1\build\RigidBody\Release\RigidBody.obj (664741, 2009-11-22)
ode-0.11.1\build\RigidBody\Release\RigidBody.pch (3211264, 2009-11-22)
ode-0.11.1\build\RigidBody\Release\RigidBody.res (32, 2009-11-22)
ode-0.11.1\build\RigidBody\Release\stdafx.obj (35230, 2009-11-22)
ode-0.11.1\build\RigidBody\Release\vc90.idb (125952, 2009-11-22)
ode-0.11.1\build\RigidBody\Release\vc90.pdb (290816, 2009-11-22)
ode-0.11.1\build\RigidBody\resource.h (403, 2009-11-21)
ode-0.11.1\build\RigidBody\RigidBody.aps (17688, 2009-11-21)
ode-0.11.1\build\RigidBody\RigidBody.cpp (1442, 2009-11-22)
ode-0.11.1\build\RigidBody\RigidBody.rc (1341, 2009-11-21)
ode-0.11.1\build\RigidBody\RigidBody.vcproj (4881, 2009-11-22)
ode-0.11.1\build\RigidBody\RigidBody.vcproj.LENOVO-CCEF8B9A.Yves Liu.user (1427, 2009-11-23)
ode-0.11.1\build\RigidBody\stdafx.cpp (296, 2009-11-21)
... ...

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.

近期下载者：

相关文件：

评论：[我要评论] [举报此文件]

收藏者：