Trying to simulate a rubber hose, I started wondering, can a curve be twisted?
In the image below bending is illustrated and the rotated frame is meant to illustrate the “twisting” of the curve.
The idea is to simulate a rubber hose connected between two independent moving parts. Initially I did that with segments of polylines which where forced to equal vector angles between segments, and so the segments would behave more or less like the illustrated nurbs curve.
But if I would like to, not only bend the hose, but also “twist” the hose (the curve or the polyline segments) like you would twist a rubber hose making it coil, how would I go about simulating something like that? (using either a nurbs curve or polyline segments). Has anyone tried simulating something such with GH?
The hose (center curve) must start and end aligned with the frame Normals (perpendicular to the planes) since this defines the orientation and rotation of the end-couplings of the rubber hose.
I don’t know if a curve can be twisted but I would do it in the following way: I’d measure the length of the twisted curve you drew there and make a straight line with the same length. Then model the rubber hose around that curve without the twist. Then use the twist command to make the hose twist. And then use flow on the hose with the straight curve as a base and the original twisted curve as target.
I’m trying this out but it seam that the combo of twist and flow needs a lot of calculcating…
The final hose is finally converted to a mesh, which in turn is used in collission tests.
The idea with the twist, just like with the bending, is to try to make it behave as “real” as possible (although not necessarily 100% real rubber). With behave I mean not only the looks but how the twist would add to the winding and curling of the hose, since I will use this for a [Grasshopper] simulation where the end couplings are constantly moving.
The suggested Flow method probably doesn’t change the “behaviour” of the fake rubber, only the final looks.
Interesting basic approach. Since I will twist the curve using Grasshopper (Frames) I could perhaps start from the basic idea of attaching three (3) curves to the frames (a little bit apart), then bend and twist (then the three curves would then actually twist) and finally - draw a tween curve between the three twisted ones.
Tried twisting a triplet of curves and finally tween the three curves.
The resulting tweened curve doesn’t deviate much from a single curve though. I would expect a rubber hose to twist and buckle significantly more than it does here (compare the two center lines, one is green).
elasticatwist.gh (13.6 KB)
If I understand correctly, you are interested in finding the space curve that results when an (initially straight) elastic rod has its ends fixed in certain positions and orientations. The example above shows a way this can be set up with the beam elements in Kangaroo.
One problem though - The hoses does twist around its center lines, by they don’t twist and bend away from its relaxed “center path” like a rubber hose would do when twisting more than the elasticity can take.
I’ll show in a minute with a short clip how I expect it to move.
Edit: Example of how the hose sways/bends to the sides when twisting(rotating) the hose ends. This is what it should do (and that also was the most difficult part, I think):
In the previous clip, based on @DanielPiker’s solution, the Frame of “the other end” was fixated while rotating (twisting) the near end. In this clip (the same solution) I show how the Frame of the “other end” starts rotating when moving the opposite end.
This unwanted rotation happens when moving either end.
Q1. Can the other end of the Hose be fixated so that it is independent of the (other) moving end? (and so the twisting occurs only to the frames between the first and last frame?). In this way the hose would tend to strat “looping” (as it was called in the paper linked to earlier in this thread)
Q2: Is it possible to make the twisting more “rigid” (one can see that the first segments/rectangles rotates quite freely, like if the rubber was more like very soft “slime” rather than stiffer rubber).
Its is also important that the rubber is more stable while moving the ends (in this clip the rubber “jumps” pretty badly).
Here’s an example showing how you can choose which of the end positions/orientations to keep fixed: elasticatwist3.gh (19.5 KB)
As for the softness you see in your video - this is just due to the speed of solving. In particular, the NURBS piping or lofting of the result can slow things down a lot for live updating. If you display only the polyline curve, things get much faster.
Are you actually wanting to use this in some sort of real time application?
If not, and it is important to have accurate solutions at each intermediate step, you might want to use the ‘Zombie’ solver instead to make sure it is always fully converged.
Realtime would be needed only for better looking demoing. For the critical simulation (collision testing) the Zombie Solver seems to do a good job (it made it look better also for real time movements).
The fixating ( = true) of the hose ends doesn’t seem to keep the end frames from rotating when moving one end. The end frames stays in their correct positions, that is good, but the they still rotate. If the orientation (or rotation) of the ends were truly locked the, hose would start to “loop” due to the movement in the clip below, which would be “real” and thus the desired behavior.
Another problem would be to keep the length of the curve constant, or as near constant as possible (In my example the curve is an interpolate curve between a set of end points in order to start with tangency (to the frame normals), and thus the length varies when the endpoints are moved). To make the curve length constant I assume I would need to make the curve from polyline segments instead, and have the segments strive to stay as straight a line as possible.
I realised that it maybe isn’t easy to set up a moving end constraint for a beam that preserves orientation with the existing components, so here’s a slightly modified version of the ‘support’ goal that lets you also specify a target frame (like the T input on the new Anchor component).
I also changed things around a bit so the input beam is straight, and the end frames get moved into position. This should make it easier to preserve length - the rest length of each beam segment stays the same as the input line. elasticatwist_movingsupport3.gh (23.8 KB)
There will still be a small discrepancy between the length of an interpolated curve and the polyline, decreasing as you increase the resolution of the discretization. Potentially though I could add a term into the beam code to account for this.
…and just for fun, I added in some self-collision too, so you can get some plectonemes forming:
