Help Scripting rod forces

[Qriva0]

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?

Not such a big difference, but yes. My point is that it's not like I press some key and it moves rod with undefined speed/distance and it does not matter where it ends, but instead there is input that has exact values and the idea is that rod must adjust to those numbers and move to provided place and stay in sync. Obviosuly it does not matter from where this input comes, I can create variable where Time.deltaTime is added when key is pressed and result is the same, the only point is that rod should stay in sync with that value, so when I push rod for 1s, then pull for 1s it ends up in starting position.

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.

By pullback I mean anything that causes rod to move back after I stop adding forces to it. For example bend caused by hitting an obstacle and returning to rest shape. Yes it's natural, but when I push rod via velocity, then hitting obstacle will stop rod, while my input depth still goes up. That simply descyncs rod with input, so I need to either pin particle to certain position (but that breaks physics) or use velocity method with offset (like spring) to account for difference between current and actual input depth. (by depth I mean how far rod is pushed)

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?

Yes, but the difference is that previously I just added force equal to movement delta, while spring (or similar method) will pull particle towards desired position, but without breaking the simulation I guess? Because I don't teleport or force rod into colliders, but push it in physical way. At least this is how I understand this.
By the way as I mentioned before about exposing job handle, that would be actually nice if there was additonal event for each substep exposing job handle.

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 accurately simulate.

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). 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.

I am aware it is not doable to replicate real behaviour, this is why I wonder if there are some hacks to improve it, even if it's not actually very realistic.

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.

Yeah I considered something like that, but as you said it's not good for bending rods, this is why I tried to do something similar, but along particle orientations.
Sooo, I guess there is not much I can do about this, except decreasing number of particles.