I am attempting to model two spheres (eventually more) and have some specifications for their relationship.
- They should always remain a set distance apart from each other.
- They should always maintain the same orientation with each other. To see what I mean by that, consider placing one sphere at the origin and another sphere above the first some distance along the z-axis. If I rotate either sphere, Condition 1 should continue to hold, while the sphere not being rotated should move (translate) so that it maintains its position relative to the rotating sphere. In other other words, the spheres do not have arbitrary surfaces. The closest points on the spheres need to remain such when either sphere rotates.
- Lastly, they should be free to rotate about the axis which defines the distance between them, so that Condition 2 only holds for rotation away from the direction axis between the two spheres.
I hope the explanations make sense, especially Condition 2, since I felt I had to reword it a few times. I’m pretty sure I can accomplish Condition 1 several ways. First, I could use the ‘Child Of’ constraint and only lock in location. Second, I could use the ‘Copy Location’ constraint. Third, I could use the ‘Limit Distance’ constraint. This seems like it may be best because it specifically dictates exactly what I’m looking for, particularly with the ‘Clamp Region’ set to ‘On Surface’. There are some problems, however.
The relationship is not two-way. If I attempt to grab and move the sphere with the applied constraint, it will only roll around the surface of the other sphere. This is understandable, although it would be nice if the other one just moved accordingly and kept the appropriate distance. With the same constraint applied to the other sphere I then am stuck with not being able to grab and translate either sphere, although they do certainly keep the same distance by just rolling around on each others’ surfaces. This is actually fine for now, but if anybody has any pointers on getting a bit more flexibility I am listening.
So next comes Condition 2, where I am largely lost. Consider having the two spheres, with the elevated second sphere having the applied ‘Limit Distance’ constraint as described above. The first sphere, at the origin, has no constraints applied. [A weird observation: when removing the test constraint from the first sphere, subsequent grabbing and translating of the first sphere does not make the second sphere move, but when grabbing and translating the second sphere, its motion is still limited to the surface of the first. Deleting and reapplying the constraint to the second sphere restores normal operation. Any explanations?] With Condition 1 met, select the first sphere and rotate it. The second sphere does not move (nor should it at this point). What I would like is for the second sphere to translate around the first sphere as the first sphere rotates. Essentially, I do not want them to be able to roll about each others’ surfaces, but instead be locked at some point as though they were facing each other at all times.
It seems Condition 2 could actually be broken down into two sub-conditions. First, the second sphere should translate according to the rotation of the first. Second, it should also be rotating at the same time in order to stay “facing” the first sphere. Combining these does seem like the tricky part and probably why it’s so difficult to describe. Basically, that’s what I meant by “orientation”.
I am aware of the ‘Track To’ constraint. Whether I am misusing it and therefore not getting my desired result or if there is a more appropriate constraint to use, I am not sure. I am confounded by the ‘To’ and ‘Up’ options. I assume the ‘To’ axes refer to the local axes of the object that I am applying the constraint to, but I cannot fully tell if that is right. For instance, If I apply the ‘Track To’ constraint to the second sphere, then ‘Z’ is the default ‘Up’ value and ‘Y’ is the default ‘To’ value. I am then able to select ‘X’ and I can see the local x-axis of the constrained second sphere point to the first. Returning to ‘Y’ points the local y-axis towards the first sphere. But selecting ‘Z’ keeps the local y-axis pointing to the target but rotates the second sphere 180 degrees about its local y-axis. A similar situation occurs if ‘X’ is ‘Up’ but even more confusing, if ‘Y’ is ‘Up’, then all three local axes point to the target when selected in the ‘To’ field. What in the world is going on? Since I haven’t explicitly asked it yet, what exactly is ‘Up’ anyways? Changing the selection makes the local axes flop around but there is nothing consistent that I can tell which would indicate a common “up” direction. Intuitively, I would expect it to be in the positive global z direction but nothing points that way ever.
The closest I can get to what I am trying to achieve is to apply Condition 1 as described above, then apply ‘Track To’ to the second sphere, target the first, select ‘Target Z’ (although I have no idea what it is doing) and leave ‘Z’ as the ‘Up’ field and ‘Y’ as the ‘To’. Then, if I grab the second sphere and translate it, it rolls around the first sphere (maintaining the correct distance - Condition 1) and always faces it. This is the correct behaviour, except that the first sphere does not continually “face” the second as it moves. I need it to do this as well. Alternatively, at this point, I can grab the first sphere and translate it and the second sphere will move to stay in contact with the surface (maintaining the appropriate distance) and continually face the appropriate direction, but the first sphere stays in its original orientation, rather than rotating as necessary to continue facing the second. This must happen in order to meet Condition 2.
In order to do this I tried applying the ‘Track To’ constraint to the first sphere and targeting the second using the same settings as for the constraint upon the second sphere. This kind of works. If I then grab the first sphere and translate it, the second no longer maintains contact, although the first sphere does continue to face the second like I wanted. Unfortunately, the second sphere does not face the first either, as though both the prior constraints on the second sphere disappeared and only the new constraint upon the first sphere applies when I move it around. I then apply the ‘Limit Distance’ constraint to the first sphere and target the second so that both of the spheres have both the ‘Limit Distance’ and ‘Track To’ constraints targeting the other. I do also note that at this point the ‘Limit Distance’ constraint was applied to the second sphere first and then the ‘Track To’, while the reverse happened for the first. I am not sure how to interpret any order of operations within the constraint panel, so I am not bothering yet with this detail until instructed otherwise. Under these conditions I am very close to achieving Condition 2, yet one problem remains: when I grab the first sphere and translate it, it remains in contact with the second and also faces it appropriately, but the second sphere remains completely still and does not track (face) the first as it moves. Conversely, when I grab the second sphere, it behaves correctly, but the first acts as though it is not bound by its constraints anymore. How to get them both to do the right thing at the same time?
It seems to me that if I were to successfully meet Condition 2, Condition 3 would be met by default because rotation about the axis which both spheres are using to face each other will not cause a change in distance, nor would it cause a change in their orientation towards each other (by definition of rotation about that axis). The only trick I could think of is that perhaps this behaviour would be effected in some unforseen way, but since I’m not there and that hasn’t happened yet, I’m not too worried about it.
If you bothered to read through this entire thing, I thank you. May it not have wasted your time. Assistance with any of the quandaries, confusion, etc. is appreciated so that I can actually learn about Blender. However, the main question of the post is highlighted for clarity.
I should also point out that I am totally open to completely alternative ways of achieving what I am trying to do. For instance, I can imagine placing some invisible object (maybe a line with vertices at the center or surface point of each sphere) to which I can define relationships/constraints rather than being stuck with just the spheres, if doing something like that would make it all more flexible or easier in the long run. Involved or tedious is ok, if it works better.
Linux Mint 12, 64b
Windows 7, 32 & 64b