# HG changeset patch # User Robert McIntyre # Date 1328270925 25200 # Node ID e1232043656a4e92f7d8b406a2112f44e2308d63 # Parent 1e6beed24cec3e057aded07e3972dd511f00372f removed old cone-joints.txt diff -r 1e6beed24cec -r e1232043656a org/body.org --- a/org/body.org Fri Feb 03 04:31:58 2012 -0700 +++ b/org/body.org Fri Feb 03 05:08:45 2012 -0700 @@ -17,9 +17,8 @@ com.jme3.math.Matrix3f com.jme3.bullet.control.RigidBodyControl com.jme3.collision.CollisionResults - com.jme3.bounding.BoundingBox)) - -(import com.jme3.scene.Node) + com.jme3.bounding.BoundingBox + com.jme3.scene.Node)) (defn jme-to-blender "Convert from JME coordinates to Blender coordinates" diff -r 1e6beed24cec -r e1232043656a org/cone-joints.txt --- a/org/cone-joints.txt Fri Feb 03 04:31:58 2012 -0700 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,127 +0,0 @@ - - - - -(ConeJoint - RigidBody A - RigidBody B - Vector3f PivotA - Vector3f PivotB - Matrix3f RotA - Matrix3f RotB -) - -Parameters: - -The specification of a cone joint depends on local coordinates, -that is coordinates relative to the given rigid bodies. - -*** -DIGRESSION ABOUT LOCAL COORDINATES - -Each rigid body has its own coordinate system. -If an object is placed, unrotated, at the origin of the world, -then its coordinate system is the same as the world's coordinate -system. In other words, the origin of the object coincides with the -origin of the world, and the XYZ axes of the object coincide with the -XYZ axes of the world. - -When you translate the object, its "origin" goes with it. -The origin of the object is always the center of the object. - -When you rotate the object, its axes go with it. -For example, if you rotate the object pi/2 radians righthandedly -about the Z axis, its own X axis will move to coincide with the -world's Y axis; its own Y axis will move to coincide with the -world's -X axis; its Z axis will remain aligned with the world's -Z-axis. - - -In such a way, you can see the way in which the translations and rotations of an -object alter its local coordinates. - - -## a haphazard elaboration of the above - -Converting from world coordinates to local coordinates amounts to -finding the transformation that undoes all the rotations and -translations that the Object has suffered, then applying that -undoing-transformation to the world coordinates. - - +position of obj +rot of obj -world axes ---------------> x -----------> obj axes - - -1. Start with the world coordinates of the Object and a test-object. -2. Subtract the world coordinates of the Object from each. Now the -Object is at the origin (though still has its rotation, if any) and -the test-object is somewhere else (irrelevant). -3. Rotate the whole world about the origin so that the Object becomes -unrotated. Now the object is unrotated at the origin, and the -test-object is somewhere else. -4. That somewhere-else is the coordinates of the test-object as seen -from the Object's own coordinate system (the system in which the Object is always -unrotated and centered at the origin) - -cf: get-subjective-rotation -cf: get-subjective-position - -*** - - -!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! - -Now, to understand the ConeJoint constructor: -Suppose you have the position of the cone joint picked out, as well as its -orientation (orientation aka rotation matters because the limits of -rotation are taken with respect to the xy and xz plane of the _joint's_ -coordinate system. This is what the documentation means by "by -default, the x-axis"). - -Then: -Pivot-a is the position of the joint, as expressed in the coordinate -system of object-a. -Pivot-a is the position of the joint again, this time as expressed in -the coordinate system of object-b. - -(Use get-subjective-position to calculate this conveniently) - - -Rot-a is the orientation of the joint, as expressed in the -coordinate system of object-a. By default, it is aligned with a's -coordinate system, making the cone's axis along a's x-axis, and its -limits of rotation in a's xy and xz planes. - -Analogously for b. - -If inconsistent pivot locations are given, it's possible to recover by -moving the objects. I think the engine prefers to keep object b still -and move everything else, but it may not always be so. - -If inconsistent rotations are given ... I don't know what -happens. Beez happens. - - -Modulo a bunch of forced object migration because your pivots give -inconsistent indicators of where the joint should be expected, etc., this is -how the method works. - - - -# Another implementation option would have been to specify the positions and -# rotations of THREE things --- object A, object B, and the joint --- all in terms of world -# coordinates. This wouldn't be any more or less fragile (i.e. subject to explosions -# of inconsistency) but it might be nice to avoid those -# transformations into local coordinates, even if we had to introduce -# more parameters into such a new method -# (specifically, the position and orientation of the joint would be new). - -# I wouldn't mind because after all, don't we already need to keep in mind the position and orientation of the -# joint in the existing method? Lest it explode in inconsistency? I -# suggest we create a clojure method that creates cone joints in the -# transformation-free way. -# cf. joint-create, my first attempt - - - -