Mercurial > cortex

annotate org/cone-joints.txt @ 108:92b857b6145d

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
slow implementation of UV-mapped touch is complete
author Robert McIntyre <rlm@mit.edu>
date Sun, 15 Jan 2012 04:08:31 -0700
parents 14b604e955ed
children
rev   line source
rlm@83 1
rlm@83 2
rlm@83 3
rlm@83 4
rlm@83 5 (ConeJoint
rlm@83 6 RigidBody A
rlm@83 7 RigidBody B
rlm@83 8 Vector3f PivotA
rlm@83 9 Vector3f PivotB
rlm@83 10 Matrix3f RotA
rlm@83 11 Matrix3f RotB
rlm@83 12 )
rlm@83 13
rlm@83 14 Parameters:
rlm@83 15
rlm@83 16 The specification of a cone joint depends on local coordinates,
rlm@83 17 that is coordinates relative to the given rigid bodies.
rlm@83 18
rlm@83 19 ***
rlm@83 20 DIGRESSION ABOUT LOCAL COORDINATES
rlm@83 21
rlm@83 22 Each rigid body has its own coordinate system.
rlm@83 23 If an object is placed, unrotated, at the origin of the world,
rlm@83 24 then its coordinate system is the same as the world's coordinate
rlm@83 25 system. In other words, the origin of the object coincides with the
rlm@83 26 origin of the world, and the XYZ axes of the object coincide with the
rlm@83 27 XYZ axes of the world.
rlm@83 28
rlm@83 29 When you translate the object, its "origin" goes with it.
rlm@83 30 The origin of the object is always the center of the object.
rlm@83 31
rlm@83 32 When you rotate the object, its axes go with it.
rlm@83 33 For example, if you rotate the object pi/2 radians righthandedly
rlm@83 34 about the Z axis, its own X axis will move to coincide with the
rlm@83 35 world's Y axis; its own Y axis will move to coincide with the
rlm@83 36 world's -X axis; its Z axis will remain aligned with the world's
rlm@83 37 Z-axis.
rlm@83 38
rlm@83 39
rlm@83 40 In such a way, you can see the way in which the translations and rotations of an
rlm@83 41 object alter its local coordinates.
rlm@83 42
rlm@83 43
rlm@83 44 ## a haphazard elaboration of the above
rlm@83 45
rlm@83 46 Converting from world coordinates to local coordinates amounts to
rlm@83 47 finding the transformation that undoes all the rotations and
rlm@83 48 translations that the Object has suffered, then applying that
rlm@83 49 undoing-transformation to the world coordinates.
rlm@83 50
rlm@83 51 +position of obj +rot of obj
rlm@83 52 world axes ---------------> x -----------> obj axes
rlm@83 53
rlm@83 54
rlm@83 55 1. Start with the world coordinates of the Object and a test-object.
rlm@83 56 2. Subtract the world coordinates of the Object from each. Now the
rlm@83 57 Object is at the origin (though still has its rotation, if any) and
rlm@83 58 the test-object is somewhere else (irrelevant).
rlm@83 59 3. Rotate the whole world about the origin so that the Object becomes
rlm@83 60 unrotated. Now the object is unrotated at the origin, and the
rlm@83 61 test-object is somewhere else.
rlm@83 62 4. That somewhere-else is the coordinates of the test-object as seen
rlm@83 63 from the Object's own coordinate system (the system in which the Object is always
rlm@83 64 unrotated and centered at the origin)
rlm@83 65
rlm@83 66 cf: get-subjective-rotation
rlm@83 67 cf: get-subjective-position
rlm@83 68
rlm@83 69 ***
rlm@83 70
rlm@83 71
rlm@83 72 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
rlm@83 73
rlm@83 74 Now, to understand the ConeJoint constructor:
rlm@83 75 Suppose you have the position of the cone joint picked out, as well as its
rlm@83 76 orientation (orientation aka rotation matters because the limits of
rlm@83 77 rotation are taken with respect to the xy and xz plane of the _joint's_
rlm@83 78 coordinate system. This is what the documentation means by "by
rlm@83 79 default, the x-axis").
rlm@83 80
rlm@83 81 Then:
rlm@83 82 Pivot-a is the position of the joint, as expressed in the coordinate
rlm@83 83 system of object-a.
rlm@83 84 Pivot-a is the position of the joint again, this time as expressed in
rlm@83 85 the coordinate system of object-b.
rlm@83 86
rlm@83 87 (Use get-subjective-position to calculate this conveniently)
rlm@83 88
rlm@83 89
rlm@83 90 Rot-a is the orientation of the joint, as expressed in the
rlm@83 91 coordinate system of object-a. By default, it is aligned with a's
rlm@83 92 coordinate system, making the cone's axis along a's x-axis, and its
rlm@83 93 limits of rotation in a's xy and xz planes.
rlm@83 94
rlm@83 95 Analogously for b.
rlm@83 96
rlm@83 97 If inconsistent pivot locations are given, it's possible to recover by
rlm@83 98 moving the objects. I think the engine prefers to keep object b still
rlm@83 99 and move everything else, but it may not always be so.
rlm@83 100
rlm@83 101 If inconsistent rotations are given ... I don't know what
rlm@83 102 happens. Beez happens.
rlm@83 103
rlm@83 104
rlm@83 105 Modulo a bunch of forced object migration because your pivots give
rlm@83 106 inconsistent indicators of where the joint should be expected, etc., this is
rlm@83 107 how the method works.
rlm@83 108
rlm@83 109
rlm@83 110
rlm@83 111 # Another implementation option would have been to specify the positions and
rlm@83 112 # rotations of THREE things --- object A, object B, and the joint --- all in terms of world
rlm@83 113 # coordinates. This wouldn't be any more or less fragile (i.e. subject to explosions
rlm@83 114 # of inconsistency) but it might be nice to avoid those
rlm@83 115 # transformations into local coordinates, even if we had to introduce
rlm@83 116 # more parameters into such a new method
rlm@83 117 # (specifically, the position and orientation of the joint would be new).
rlm@83 118
rlm@83 119 # I wouldn't mind because after all, don't we already need to keep in mind the position and orientation of the
rlm@83 120 # joint in the existing method? Lest it explode in inconsistency? I
rlm@83 121 # suggest we create a clojure method that creates cone joints in the
rlm@83 122 # transformation-free way.
rlm@83 123 # cf. joint-create, my first attempt
rlm@83 124
rlm@83 125
rlm@83 126
rlm@83 127