1.1 --- a/org/body.org	Fri Feb 03 04:31:58 2012 -0700
     1.2 +++ b/org/body.org	Fri Feb 03 05:08:45 2012 -0700
     1.3 @@ -17,9 +17,8 @@
     1.4     com.jme3.math.Matrix3f
     1.5     com.jme3.bullet.control.RigidBodyControl
     1.6     com.jme3.collision.CollisionResults
     1.7 -   com.jme3.bounding.BoundingBox))
     1.8 -
     1.9 -(import com.jme3.scene.Node)
    1.10 +   com.jme3.bounding.BoundingBox
    1.11 +   com.jme3.scene.Node))
    1.12  
    1.13  (defn jme-to-blender
    1.14    "Convert from JME coordinates to Blender coordinates"

     2.1 --- a/org/cone-joints.txt	Fri Feb 03 04:31:58 2012 -0700
     2.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
     2.3 @@ -1,127 +0,0 @@
     2.4 -
     2.5 -
     2.6 -
     2.7 -
     2.8 -(ConeJoint
     2.9 -	RigidBody A
    2.10 -	RigidBody B
    2.11 -	Vector3f PivotA
    2.12 -	Vector3f PivotB
    2.13 -	Matrix3f RotA
    2.14 -	Matrix3f RotB
    2.15 -)
    2.16 -
    2.17 -Parameters:
    2.18 -
    2.19 -The specification of a cone joint depends on local coordinates,
    2.20 -that is coordinates relative to the given rigid bodies.
    2.21 -
    2.22 -***
    2.23 -DIGRESSION ABOUT LOCAL COORDINATES
    2.24 -
    2.25 -Each rigid body has its own coordinate system.
    2.26 -If an object is placed, unrotated, at the origin of the world,
    2.27 -then its coordinate system is the same as the world's coordinate
    2.28 -system. In other words, the origin of the object coincides with the
    2.29 -origin of the world, and the XYZ axes of the object coincide with the
    2.30 -XYZ axes of the world.
    2.31 -
    2.32 -When you translate the object, its "origin" goes with it.
    2.33 -The origin of the object is always the center of the object.
    2.34 -
    2.35 -When you rotate the object, its axes go with it.
    2.36 -For example, if you rotate the object pi/2 radians righthandedly
    2.37 -about the Z axis, its own X axis will move to coincide with the
    2.38 -world's Y axis; its own Y axis will move to coincide with the
    2.39 -world's -X axis; its Z axis will remain aligned with the world's
    2.40 -Z-axis.
    2.41 -
    2.42 -
    2.43 -In such a way, you can see the way in which the translations and rotations of an
    2.44 -object alter its local coordinates.
    2.45 -
    2.46 -
    2.47 -## a haphazard elaboration of the above
    2.48 -
    2.49 -Converting from world coordinates to local coordinates amounts to
    2.50 -finding the transformation that undoes all the rotations and
    2.51 -translations that the Object has suffered, then applying that
    2.52 -undoing-transformation to the world coordinates.
    2.53 -
    2.54 -            +position of obj   +rot of obj
    2.55 -world axes  ---------------> x -----------> obj axes
    2.56 -
    2.57 -
    2.58 -1. Start with the world coordinates of the Object and a test-object.
    2.59 -2. Subtract the world coordinates of the Object from each. Now the
    2.60 -Object is at the origin (though still has its rotation, if any) and
    2.61 -the test-object is somewhere else (irrelevant).
    2.62 -3. Rotate the whole world about the origin so that the Object becomes
    2.63 -unrotated. Now the object is unrotated at the origin, and the
    2.64 -test-object is somewhere else.
    2.65 -4. That somewhere-else is the coordinates of the test-object as seen
    2.66 -from the Object's own coordinate system (the system in which the Object is always
    2.67 -unrotated and centered at the origin)
    2.68 -
    2.69 -cf: get-subjective-rotation
    2.70 -cf: get-subjective-position
    2.71 -
    2.72 -***
    2.73 -
    2.74 -
    2.75 -!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    2.76 -
    2.77 -Now, to understand the ConeJoint constructor: 
    2.78 -Suppose you have the position of the cone joint picked out, as well as its
    2.79 -orientation (orientation aka rotation matters because the limits of
    2.80 -rotation are taken with respect to the xy and xz plane of the _joint's_
    2.81 -coordinate system. This is what the documentation means by "by
    2.82 -default, the x-axis").
    2.83 -
    2.84 -Then: 
    2.85 -Pivot-a is the position of the joint, as expressed in the coordinate
    2.86 -system of object-a.
    2.87 -Pivot-a is the position of the joint again, this time as expressed in
    2.88 -the coordinate system of object-b.
    2.89 -
    2.90 -(Use get-subjective-position to calculate this conveniently)
    2.91 -
    2.92 -
    2.93 -Rot-a is the orientation of the joint, as expressed in the
    2.94 -coordinate system of object-a. By default, it is aligned with a's
    2.95 -coordinate system, making the cone's axis along a's x-axis, and its
    2.96 -limits of rotation in a's xy and xz planes.
    2.97 -
    2.98 -Analogously for b.
    2.99 -
   2.100 -If inconsistent pivot locations are given, it's possible to recover by
   2.101 -moving the objects. I think the engine prefers to keep object b still
   2.102 -and move everything else, but it may not always be so.
   2.103 -
   2.104 -If inconsistent rotations are given ... I don't know what
   2.105 -happens. Beez happens.
   2.106 -
   2.107 -
   2.108 -Modulo a bunch of forced object migration because your pivots give
   2.109 -inconsistent indicators of where the joint should be expected, etc., this is
   2.110 -how the method works.
   2.111 -
   2.112 -
   2.113 -
   2.114 -# Another implementation option would have been to specify the positions and
   2.115 -# rotations of THREE things --- object A, object B, and the joint --- all in terms of world
   2.116 -# coordinates. This wouldn't be any more or less fragile (i.e. subject to explosions
   2.117 -# of inconsistency) but it might be nice to avoid those
   2.118 -# transformations into local coordinates, even if we had to introduce
   2.119 -# more parameters into such a new method
   2.120 -# (specifically, the position and orientation of the joint would be new).
   2.121 -
   2.122 -# I wouldn't mind because after all, don't we already  need to keep in mind the position and orientation of the
   2.123 -# joint in the existing method? Lest it explode in inconsistency? I
   2.124 -# suggest we create a clojure method that creates cone joints in the
   2.125 -# transformation-free way.
   2.126 -# cf. joint-create, my first attempt
   2.127 -
   2.128 -
   2.129 -
   2.130 -