Animating ISMs attached to a Cable Component

[alex.pillar1]

Hi to all,

Can anyone offer any suggestions on how to fix this roll offset? At the mid-point the flag is perfectly aligned with the cable component along all three axes, including the sag. As it sways side-to-side, it goes off-kilter by a few degrees along Z, and it also tilts front to rear along Y. Here’s what I’m working with:

Thanks for taking the time to look.

-Alex

[RedGrimnir (Grimnir)]

“I just need the correct combination” case

I take some time to go over it and here is some that MAYBE the culprit;

• Vectors are right at first glance, UPxRight maybe better normalise again to be sure as first try.
• You can maybe use MakeRotFromXZ
• OR Maybe there is a problem with the up being not truly perpendicular to forward so maybe you can try something like this

[alex.pillar1]

@RedGrimnir Thanks so much, I’ll check this out over the weekend.

[alex.pillar1]

@RedGrimnir I believe I’ve done justice to your proposal, but unfortunately, no change. Did I integrate this correctly? The only thing I had to change was 1.0 → -1.0 on UpNominal, otherwise the flags are inverted, sitting on top of the cable. I doubt this is core to the problem.

I also tried the simpler solutions, but they all produce same/similar result.

Many thanks,

Alex

[alex.pillar1]

I solved it! Finding “the correct combination” required a different approach. I wanted to try and offset the unwanted rotation and this would need to be relative to the SINE roll function. Splitting the Forward Vector, I trialed subtracting randomly from each axis before creating the final Roll Rotator - of course it was the last one I tested that worked! . Feed the Twist Amplitude into this offset and “hey presto!”

[alex.pillar1]

I don’t know what’s going on here - my previous post indicated “solved”, but after a quick tidy-up of the node spaghetti it “unresolved”… after some hair-tearing and finally removing my “solution”, it’s now working according to this logic:

Thanks to @RedGrimnir for the assist.

[Dasay2605]

The logic can be simplified to the following form:

This may not work for your particular setup as I don’t know what static meshes you used as flags, so you may end up with rotated flags.

Here are some changes I made compared to your solution:

1. The logic on BeginPlay can be simplified to just creating the instances and that’s it. You won’t notice their first position anyway, since the EventTick will almost instantly override it.
2. You don’t have to use quaternions directly. If you want to do a multiplication, Combine Rotation will do it for you. It takes rotators A and B, converts them to quaternions, multiplies them (effectively doing quat(B)*quat(A), so you may need to swap the inputs), and converts the result back to the rotator.
3. You can find the base rotation much more easily by directly converting the vector to a rotator using RotationFromXVector. Sometimes you can use MakeRotFrom.. nodes. This includes nodes like MakeRotFromXY, so you don’t have to calculate the last axis yourself.
4. When calculating the twist angle, you do the following:
   
   
   
   It looks like you wrote this logic just to make sure that TwistWaveLength will have an effect up to 1, and any higher number will have the same effect as 1. This is very non-obvious logic. You can simply go to the variable properties and set the limit directly there:
   
   
5. The last thing is not that important and is usually unnoticeable, but if the cable consists of a small number of samples and forms a U-shaped curve, you may notice the problem, which I illustrated in the image below:
   
   
   
   When calculating the direction vector at a point, you make the following calculation: NextParticleLocation - CurrentParticleLocation which results in the red arrows you see in the image above. To get the green direction, you can add two segments directions (or find the average between the two vectors). I did it in the following way:

   Norm(NextParticleLocation - CurrentParticleLocation) + Norm(CurrentParticleLocation - LastParticleLocation) 
   

   Again, this can be not necessary if you have a very detailed straight cable, but it can be done to get the mathematically expected direction.

I hope this was at least somewhat clear. I know you’ve already solved your problem yourself, but I thought you wouldn’t mind a slightly simplified solution. If anything remains unclear, I can explain in more detail.