I have a simple animation which drives me crazy. A constraint is broken when following a path closer to the base, while working fine when the path is farther from the base.
Am I doing something wrong or is it a bug with the Rubberband (“pistons”) scaling down?.
See in the clip what happens. I made two “path followers” for comparison, the red path causes constraint errors. Model attached below:
The model :
_ThreePistonPathFollower.3dm (532.6 KB)
The problem lies with line LN__PISTON_B.
When you change its scaling direction to X instead of Z everything works fine. With scaling to Z apparently the constraint cannot be met (somewhere between tick 14 and 15) not because of the distance but rather because of the twist PT_TRIJOINT_B makes (due to its hinging properties) putting Z nearly perpendicular to the direction pointed out by PT_SNAP_B.
You should take into account the fact that scaling always has its effect in Objectspace. LN__PISTON_B is a child of PT_TRIJOINT_B, hence inherits the orientation of his parent. The IK-solver will try to figure out the scaling along the twisted pivot.
When you want an linear object to scale along its own axis it is sensible to rotate the object’s pivot so that one of the pivot’s axis (no matter X, Y or Z) is aligned with the object itself.
_ThreePistonPathFollower 001.3dm (547.1 KB)
It is for situations like this we need a BongoOrientPivot command. A workaround is as following:
• Detach point PT_SNAP temporarily form the line LN__PISTON.
• Use Rhino’s Orient command on LN__PISTON to put the line vertical.
• Use the ‘Reset’ option in the BongoRotatePivot command, hence making the Z axis align with the line.
• Use Rhino’s Orient command again on LN__PISTON with PT_SNAP as “target point 2” in order to put the line back in position.
• Reestablish the hierarchy with PT_SNAP
Now scaling along the Z-axis will do exactly what you intended.
Haha, you’re incredible in finding all the glitches in my attempts to play with the adults. 
Thank you very much for this help. I definitely will pay more attention to the orientation of the pivot in the future. I actually tried to “Rotate Pivot” on a single “piston” which I tried at first, but I had to give up on it because it had angles in two planes, and the pivot won’t orient properly in the perspective viewport…
But with the method you describe above, I will have better luck in the future. Thanks!
// Rolf
Okay, I got that problem fixed following your instructions. I didn’t know that “Orient” could rotate so that also the Pivot would follow. Nice.
But, I still have problems with that little tri-legged animal not being very obedient to instructions. In the clip below the ABB-robot and the tri-legged one is following the same point (by Constrain to Object), that same point being simple constrained “To Path”. But the three-legged thingy doesn’t seem to follow the “To Path” point as well as the ABB-robot.
Any ideas about what can be causing such ugly lag?
// Rolf
PS: The robot was downloaded from ABB-robotics web pages. I spent quite a few hours cleaning it up and repairing surfaces (“Bad Objects” and “Naked Edges” etc). All the typical surface errors that makes me suspect the robots has been drawn with Rhino… 
Yes, I was busy doing that but wasn’t quick enough. You should have received a mail by now.
Have a nice weekend!
// Rolf
You keep saying that, yes 
Huh?
Hm. I don’t remember having said this in any other thread, or did I? That very statement can be perceived as either criticism or, well, just acknowledging that Rhino lets you do what you are capable of doing, while other software let you do only what the software is capable of doing.
In any case, I’m fine with that because that very freedom is one of the best things with Rhino. Free to do things well, and free to mess things up.
But again, this isn’t anything I keep saying. But perhaps I should start saying that all the time.
I try to learn other CAD packages as well, but Rhino has got me hooked. It really is the Swiss knife of CAD. I don’t have any other opinion in mind, although it may have sounded otherwise in English which isn’t my native language.
Have a nice weekend!
// Rolf
Yup…
When you put it that way it suddenly makes more sense.
At any rate, I would think that what you are seeing in that downloaded file has more to do with file conversion than anything else. I’ve been trying to make some sense of this model of an ROV that apparently comes out of SolidWorks but that doesn’t make me say anything about the quality (or lack thereof) if SolidWorks… (I just now saw that there are *.SLDASM and *.SLDPRT files in there as well and Rhino is chewing on them as I write this…)
Takk for det. Ha en fin helg, du også!
w
I decided onesidedly that I think that an object navigator would be a good thing without being a whiner.
Anyway, I doubt that what I have seen in this model is due to conversions. Not all of them anyway. One reason for that is that many of the objects have never been true solids (and they’re not so now either). And another reason is that you’ll find fillets cutting into other fillets and crisscrossing… like you most probably would be able to do only in Rhino, or the alike. (If you are not a Norwegian and if not being fully sober, that is. ).
See some close up examples below. Let’s vote for what kind of modeling tool was used for producing this level of “creative craftmanship.” Probably not a solid-modeller in my opinion.
_Fig. 1: I was going to say something about this one, but I find myself at loss of words. But OK, one word: “Skillz” (and this one looks nice compared to another one which I couldn’t find at this moment) :
Fig 2. Well, this surface is actually smooth, but I really didn’t expect that kind of solution :
And many more places which I fail to find right now. Plus a bunch of “bad objects” of the kind I sometimes find being produced by Rhino (but of course I don’t know if other software makes them as well, those self intersecting edge loops etc, I just didn’t expect stricter solid-modeller software to allow for open surfaces and the typical oddities that comes with that, but I’m new to CAD so what do I know).
BTW, I have a daughter living in Oslo having a boyfriend from Bergen. So I can only say good things about Norway in these days.
Ha en mycket trevlig helg!
// Rolf
I find this one pretty amazing as well :
What to think of this? Of course they may have drawn the basic stuff with a solid modeller and then reworked some details with a surface modeller, but the point is that I think there are good reasons to believe that a surface modeller has been used, and I suspect Rhino isn’t a very bad guess. OTOH I noticed that PTC Creo has a combined Parametric and Direct modeller, so there is another candidate.
Well, that’s my guess work about this patch work so far. 
// Rolf
It’s the other way around; the ABB-robot does not follow.
It is due to the limits you used for TOP_ARM_FUSELAGE (Min -90.00 and Max 0.00).
As you certainly know Rhino and Bongo use the right handed Cartesian coordinate system. Because we are accustomed by Rhino to look backwards at the Y vector in Perspective (and Front) view positive/negative rotation is easily confused. I guess that’s what fooled you into thinking that downwards was negative.
The zero values use for Min(imum) and Max(imum) hinge rotation are (in my view) a bit particular. Z and Y both use positive X-vector, while X uses the negative Z-vector. @Lars???
BTW Rolf, I think the pivot of TOP_ARM_FUSELAGE is not correct positioned relative to the object to act as its rotation-axis.
Typical you to only find all the errors. But I’m glad you did!
But I actually have at least a half-excuse. Except for failing to run the animation with the path visible (then I would have noticed myself that it was the Robot that had problems) I tried to change this limit, but obviously the modification didn’t stick, see next section.
I tried to change that value, but apparently it refuses to change (modifying the value and selecting another object, and then selecting the “Min” field again jumps back to the same old value (-90) regardless of my attempts to change it).
I (now) resorted to “remove the animation” altogether for this part, only then I was able to correct the Min value.
Something for the developers to take a closer look at?
Ops again. I probably exploded that part (fixing some “BadObjects”) and joined it again, even forgetting that when doing so also the Pivot setting goes away.
But now it works beautifully! Thanks again for your help @Luc., I value your help very much, your help is very careful, professional and not to forget, very patient.
// Rolf
I fooled around a bit with limits.
It is a mathematical evidence that Min(imum) must be smaller than (or equal to) Max(imum). When unfitting values (min > max or max < min) are entered they cannot be accepted.
Unfortunately the concerning UI is vague and confusing: the invalid value remains displayed in white font against blue field whereas an accepted value turns black on white field. Nevertheless an invalid value is turned black on white when the opposite input box (Min/Max) is selected. What happens then kind of depends on the entered values – it remains all unclear (even for me 
) – often the previous values are reset. Regrettably this can results in one leaving the Limits dialog believing the entries are OK, but on return has to find the “modification didn’t stick” (as you put it so well).
A similar situation Min/Max occurs in Bongo’s Render Animation dialog for Input Start/End and for Frame Range. In this dialog the behavior of the input-boxes in my opinion is more user-friendly.
An invalid entry is immediately altered into the corresponding maximum/minimum value,
i.e. 
becomes 
.
This automatically makes one understand what is erroneous.
Still remains the slight irritation one has to alter the opposite input-box first and then the first one again in order to get the desired values in. So maybe it would be better that the exceeding value was accepted while the opposite one is set to the corresponding max/min and selected. 
In the Render Animation dialog unluckily the user has not the visual comfort of seeing his entry confirmed when hitting Enter (by the box-field turning to white and the font to black with a blinking cursor).
I’ll pass these considerations on to the developers.
BTW In case of your TOP_ARM_FUSELAGE : when you want to change the limits from Min -90.00 Max 0.00 into i.e. Min 10 Max 120, you first have to enter the 120 Max and only then the 10 Min (not the other way around) 
Now you really got me!
OK, but now I understand what was fooling me. I should have understood that, because this is a “classical problem” with Min & Max values. I really should have tested this myself since I’ve solved this kind of problem before as a programmer (but I often solved it by pushing the Max value automagically).
I think that the best solution would be to simply trip up the Max value if the Min value “intersects.” Also changing the color of the numbers (or background color) until the numbers are confirmed (until ENTER is pressed in each modified field) would make it very clear to the user what’s happening, since he would clearly see if both numbers has changed (color).
Yes, this definitely needs to be fixed.
// Rolf
