(28-09-2020, 08:42 AM)mr-matt Wrote: I am indeed using dynamic constraints.
What's this mass ratio in relation to? I tried adjusting the mass on the parent object from 500 to 50000 with no change in behaviour and the rope/solver doesn't appear to use mass anywhere. Only the mass of the objects the ropes are carrying that seem to have an affect.
Mass ratio
between the bodies involved in the attachment, in this case the rope and the attached object. So if the object is very heavy compared to the rope, it will stretch it. Hierarchical transform relationships play no role in here.
Ropes (and the solver) do use mass. Being a particle-based engine, each particle carries its own mass value, that is used throughout the simulation to calculate all constraints including collisions and attachments. You can set rope mass per-control point using the path editor. Mass values from the control points will be interpolated to particles. See:
http://obi.virtualmethodstudio.com/tutor...setup.html
(28-09-2020, 08:42 AM)mr-matt Wrote: I found increasing substeps caused eratic behaviour where the ropes would randomly move around and drastically affected performance.
Using 2-3 substeps should be enough, and should not cause any weird behavior. Make sure you haven't attached the rope inside a collider that's set to collide with the rope (this is a common mistake that will cause erratic behavior, see the last bit of:
http://obi.virtualmethodstudio.com/tutor...aints.html). Also make sure you've enabled "substep unity physics" in the updater, or rigidbodies will get out of sync with the particle simulation.
(28-09-2020, 08:42 AM)mr-matt Wrote: I wasn't happy with the length of the ropes until the distance iterations were at around 100 at which point frame rate was reduced to a slide show on a 2080ti and Ryzen 3700x. I also found that the large masses were causing a lot of oscillations that don't seem to go away very quickly even with a high damper on the obi solver.
Using iterations of often less effective than using substeps and a bit more costly, as described in the manual:
Quote:Note that reducing the timestep/increasing the amount of substeps also has an associated cost. But for the same cost in performance, the quality improvement you get by reducing the timestep size is greater than you'd get by keeping the same timestep size and using more iterations.
You should first increase substeps (they affect all constraints), then fine-tune using iterations if you need more/less quality on specific constraint types.
(28-09-2020, 08:42 AM)mr-matt Wrote: I've also tried scaling the mass of the objects down but I have to scale it down so much that the behaviour of the objects no longer looks natural i.e. it messes with the inertia.
Any other ideas?
Increasing rope mass or reducing rope resolution should also work. By reducing the mass ratio and using less constraints, you'll increase convergence and reduce simulation cost.
To get an idea: what's the mass of the object you've attached to the rope? Also, what's the approximate length of the rope (in meters)? I get the feeling that you're just using the wrong type of physics engine for this. It is widely known that large mass ratios are one of the weakest points of iterative physics solvers (that account for almost 100% of realtime game engines), for this reason large mass ratios are simply avoided in games. Just try placing a 1000 kg rigidbody on top of a 1 kg rigidbody in Unity and watch it dance.
If you absolutely must deal with large ratios, you should avoid both Obi and Unity's built-in engine and switch either to a direct solver or a reduced-coordinates solver (ABA/Featherstone). Both are much more performance hungry than iterative solvers, and often relegated to engineering/industrial environments where correctness is more important than raw speed.
