I've encountered a bug in my project, and was able to encounter it again on a new clean projet. I'm using Unity 2019 LTS and Obi Rope 5.6.2
1. I've a prefab, containing two objects dynamically linked by a rope. The solver is inside the prefab (with ObiFixedUpdater)
2. I put 3 instances of this prefab in a simple scene
3. Then, if I delete A, then B, then C, everything is fine...
BUT ! If I delete C first, there is a big bug, and ropes from A go crazy and jump (or the spheres/cubes fly away) ! The attachment is almost broken (there is a big gap between the rope and the sphere)
Could you help me/resolve this bug ?
I can send a zip package is necessary,
I've encountered a bug in my project, and was able to encounter it again on a new clean projet. I'm using Unity 2019 LTS and Obi Rope 5.6.2
1. I've a prefab, containing two objects dynamically linked by a rope. The solver is inside the prefab (with ObiFixedUpdater)
2. I put 3 instances of this prefab in a simple scene
3. Then, if I delete A, then B, then C, everything is fine...
BUT ! If I delete C first, there is a big bug, and ropes from A go crazy and jump (or the spheres/cubes fly away) ! The attachment is almost broken (there is a big gap between the rope and the sphere)
Could you help me/resolve this bug ?
I can send a zip package is necessary,
Thanks,
Hi there,
If you could send a .zip of the project to support(at)virtualmethodstudio.com I will take a look at it. I don't quite understand your description.
04-02-2021, 10:45 AM (This post was last modified: 04-02-2021, 10:46 AM by josemendez.)
This is a known bug in dynamic attachments, introduced in 5.6.1 and fixed in 6.0 (yet unreleased). A quick fix is to open up ObiParticleAttachment.cs, and just remove/comment out line 456:
Code:
//if (torn) // <---comment this out
m_Actor.SetConstraintsDirty(Oni.ConstraintType.Pin);
One thing I though I should point out about your current setup: you're using an independent updater/solver for each prefab instance. This is a big no-no. This means each solver and its rope will be updated sequentially, negating most multithreading benefits. Usually you're supposed to have a single Updater component in your scene that updates all solvers in parallel. See: http://obi.virtualmethodstudio.com/tutor...cture.html http://obi.virtualmethodstudio.com/tutor...aters.html
To make things worse, all updaters use 3 substeps and have "substep unity physics" enabled. This will force rigidbody physics in your scene to be updated 3 times per updater, for a total of 9 full physics updates per frame. For very simple scenes it might be ok, but as soon as you add a few more ropes it will absolutely obliterate performance.
(04-02-2021, 10:45 AM)josemendez Wrote: This is a known bug in dynamic attachments, introduced in 5.6.1 and fixed in 6.0 (yet unreleased). A quick fix is to open up ObiParticleAttachment.cs, and just remove/comment out line 456:
Code:
//if (torn) // <---comment this out
m_Actor.SetConstraintsDirty(Oni.ConstraintType.Pin);
One thing I though I should point out about your current setup: you're using an independent updater/solver for each prefab instance. This is a big no-no. This means each solver and its rope will be updated sequentially, negating most multithreading benefits. Usually you're supposed to have a single Updater component in your scene that updates all solvers in parallel. See: http://obi.virtualmethodstudio.com/tutor...cture.html http://obi.virtualmethodstudio.com/tutor...aters.html
To make things worse, all updaters use 3 substeps and have "substep unity physics" enabled. This will force rigidbody physics in your scene to be updated 3 times per updater, for a total of 9 full physics updates per frame. For very simple scenes it might be ok, but as soon as you add a few more ropes it will absolutely obliterate performance.
let me know if I can be of further help. cheers!
It's working now ! Thank you a lot for your efficiency
Yes, for my original project (not the simple that I made to send for the bug report), I've one Updater, and dynamically add/remove solvers to it. The number of substeps is relative to the number of solvers.
