Help Scripting rod forces

[josemendez]

Yeah, I tried both methods. The problem is that I don't move rod by pressing the keyboard arrow, but I try to keep it in sync with some depth value - for instance it's 10 meters at some point, but several frames later it will be 11 and rod should reflect that by moving 1m forward. There are two problems with that.

I'm not sure what the difference would be between using the keyboard or driving motion by using a value. Do you mean the value changes in a non-smooth way, as it may suddenly jump from 10 to 11 in a single frame?

First one is pullback. I don't want my cable to go back on collision

I'm not sure what you mean by "pullback" or "going back on collision".

and that is the reason why I tried to "pin" particle - to disallow pullback from tension.

If by "pullback" you mean the rope snapping back to its rest length when one particle is moved far away from its current position in a single frame, that's the physically accurate way for the rope to react: the force applied to one particle propagates trough the rope over time and results in a pullback effect, the speed of the propagation will be faster the more iterations/substeps you use, but will never be instantaneous.

If you move one particle X meters, it wouldn't make any sense for the entire rope to suddenly *teleport* X meters away: that just doesn't happen in the real world.

I guess I would need to change approach to moving rod particle by invisible line, something like softbody dragon demo?

That's just using a spring force (F = -kx, where k is stiffness and x distance)  to move a particle. Still counts as modifying the particle's velocity which I think is what you were originally doing?

I wanted, but that causes a lot of not physical things to happen, jitters or breaking constraints. Does pinhole do that actually? I think it does not.

Pinholes just adjust the position of the particle, and then calculate the resulting change in velocity as newPosition-oldPosition/dt. All dynamic constraints in Obi work this way. Kinematic constraints (such as fixed attachments) just change the position, but keep velocity = zero.

In my case rod is some kind of stiff cable and when I pull it I need the whole thing to move at the same time.
You know, when you pull a plastic cable in reality it does not strech much, but the whole length moves at the same time.

Yes, I think I understand but there's bad news: This is simply not doable.

The reason is that in the real world, time is a continuous quantity, which is the same as saying the timestep/delta time is infinitely small (in Obi that would mean using infinite substeps).

If an infinitely stiff material existed, forces would propagate trough it at infinite speed, requiring infinite computational resources to simulate them. However, there's no such thing as an infinitely stiff material in reality: all materials have finite stiffness, that results in a specific speed of sound for that material - the speed at which molecules vibrate and transfer force along the material. This is the speed at which force propagates trough the material. Despite not being infinite, for very stiff materials this is an *extremely* high speed that still needs a huge amount of computational resources to be accurately simulated.

Now, Obi is an iterative solver and that means it propagates forces by repeating the process of spreading them out from one particle (roughly == molecule) to the next over many iterations. There's another family of solvers that try to directly calculate what the state of the system will be in the next timestep, called direct solvers (in Obi, chain constraints implement this). The problem with direct solvers is that their base cost is much higher than that of iterative solvers, and that they may return nonsense if they can't find a solution to the system (overconstrained system) or if there's multiple solutions (underconstrained system).

All existing physics engines face the same fundamental difficulty: for instance if you stack boxes in any rigidbody engine (you can try Unity's), the taller the stack the more wobbly/bouncy it becomes - as forces cannot propagate fast enough up the stack. You'd need a smaller fixed timestep or more velocity iterations to improve this, increasing the computational cost of the solution.

In general: the more individual "units of matter" you need to propagate force trough, and the higher the stiffness of the matter, the more computational resources you need. For Obi, this means that ropes/rods with more particles in them (longer, or higher resolution) and zero compliance (== infinite stifness) require more substeps/iterations to be accurately simulated.

My current solution do this problem is adding forces along the rope (according to particle orientations), not perfect, but definitely better than nothing. However I still  wonder if there is anything else I could do.

What you're trying to accomplish with this is to simulate the effect of faster force propagation, but just adding some ad-hoc extra force to all particles in the rope. It's as good as you can do without switching to much more computationally intensive methods.

Another "hack" that many games use is to just constrain particles to be within some distance of an attachment point, in an attempt to simulate instant propagation of forces - however this won't work well for non-straight ropes involving collisions. Obi Cloth features such a solution for cloth in the form of tether constraints.

kind regards,