Obi Official Forum
Performance issues - Printable Version

+- Obi Official Forum (https://obi.virtualmethodstudio.com/forum)
+-- Forum: Obi Users Category (https://obi.virtualmethodstudio.com/forum/forum-1.html)
+--- Forum: Obi Rope (https://obi.virtualmethodstudio.com/forum/forum-4.html)
+--- Thread: Performance issues (/thread-318.html)

Pages: 1 2


RE: Performance issues - josemendez - 25-01-2018

(25-01-2018, 03:11 PM)khalvr Wrote: Do tether constraints only work with fixed particles, or do they also work with pin constraints? The way i deal with anchor points right now is to pin a dummy rigidbody to a specific particle and freeze it using a fixed joint. This has some side effects but is easy to configure. Is there an easy way of un-fixing a particle through script? Will i have to iterate through all the particles in the solver and check their distance to the point?

Tethers ignore pinned particles, but there's a workaround: you could fix the pinned particles, add tethers, then unfix the particles. That should work.

However I still don't get why you go trough so much trouble just to anchor a particle. Simply creating a handle out of it will "promote" that particle to a GameObject, that you can move around, parent to other objects, etc. Pinning it to a rigidbody w/fixed joint seems a bit convoluted, specially since your rigidbodies do not rely on the rope to keep the appropriate distance between them (you're using joints for this, right?)

Since you have a chain of rigidbodies linked with joints and the rope is merely passive eye candy between each pair of bodies, simply creating handles and parenting them to the rigidbodies should suffice. The rigidbodies do not need to be aware of the rope's existence, so to speak, as they are already kept in place by spring joints.

To unfix a particle trough scripting, set its inverse mass to something larger than zero. The logic behind this is that a particle with zero inverse mass has infinite mass = cannot move at all. See the last bit of:

http://obi.virtualmethodstudio.com/tutorials/scriptingparticles.html

The specific function you want to use is Oni.SetParticleInverseMasses(solver, masses, particle count, offset);


RE: Performance issues - khalvr - 25-01-2018

(25-01-2018, 03:32 PM)josemendez Wrote: Tethers ignore pinned particles, but there's a workaround: you could fix the pinned particles, add tethers, then unfix the particles. That should work.

However I still don't get why you go trough so much trouble just to anchor a particle. Simply creating a handle out of it will "promote" that particle to a GameObject, that you can move around, parent to other objects, etc. Pinning it to a rigidbody w/fixed joint seems a bit convoluted, specially since your rigidbodies do not rely on the rope to keep the appropriate distance between them (you're using joints for this, right?)

Since you have a chain of rigidbodies linked with joints and the rope is merely passive eye candy between each pair of bodies, simply creating handles and parenting them to the rigidbodies should suffice. The rigidbodies do not need to be aware of the rope's existence, so to speak, as they are already kept in place by spring joints.

To unfix a particle trough scripting, set its inverse mass to something larger than zero. The logic behind this is that a particle with zero inverse mass has infinite mass = cannot move at all. See the last bit of:

http://obi.virtualmethodstudio.com/tutorials/scriptingparticles.html

The specific function you want to use is Oni.SetParticleInverseMasses(solver, masses, particle count, offset);

Yes, i am in the process of switching to handles right now, i was just curious in the event that i would try to revisit fully simulated cords with properly configured tether constraints in the future. Also, when using handles, i'm assuming that you don't actually need an ObiRigidbody or ObiCollider on the object containing the handle?

By the way, is there any way of knowing whether a particular particle has a handle associated with it or not? What happens when the rope is re-initialized? Will the handle point to a non-existing particle? Also, one thing which i think you should fix is that whenever you create a new obi component (including the handle), it always ends up at the bottom of the hierarchy of the currently active scene, even if you're working in an entirely different scene. The preferred behavior would be if it was parented to the currently selected object (if there is one), as is the case with all unity objects created through the context menu. It would also be nice if the rope followed the spline while you were editing it (this would potentially make the resolution incorrect, but i think this would be acceptable as you can always re-initialize the rope to handle this). Having to redo 30 pin-constraints or fixed particles just because your rope is slightly out of alignment at one position is really tiresome. I'm also curious as to whether stitches persist after you've re-initialized any of the ropes.


RE: Performance issues - khalvr - 26-01-2018

So, i switched to handles, but now, the cords start flickering. It doesn't look like your normal simulation jitter, but more like the cord model is flickering between two positions instantly. What would be causing this?

EDIT: By the way, even though i put "collision" last in the solver list, i still get particles getting stuck inside colliders. This was probably the largest issue with using ObiRope for the regular cord simulation, rigidbodies would sometimes bounce outside of the play area and get stuck inside the wall. I have reduced the physics timestep to 0.012 and iteration count to 5, but it doesn't help. This application is to be used in a contest, and having critical elements stuck inside walls is just not acceptable.

Also, the error seems to persist even though i remove the ObiRigidbodies. It actually seems to be related to the dynamic mesh creation rather than physics, at least from looking at the stack trace.

Assertion failed: Assertion failed on expression: 'CompareApproximately(det, 1.0F, .005f)'
UnityEngine.Quaternion:FromToRotation(Vector3, Vector3)
Obi.CurveFrame:Transport(Vector3, Vector3, Single) (at Assets/Obi/Scripts/Actors/ObiRope.cs:61)
Obi.ObiRope:UpdateRopeMesh() (at Assets/Obi/Scripts/Actors/ObiRope.cs:962)
Obi.ObiRope:UpdateProceduralRopeMesh() (at Assets/Obi/Scripts/Actors/ObiRope.cs:892)
Obi.ObiRope:UpdateVisualRepresentation() (at Assets/Obi/Scripts/Actors/ObiRope.cs:590)
Obi.ObiRope:OnSolverFrameEnd() (at Assets/Obi/Scripts/Actors/ObiRope.cs:365)
Obi.ObiSolver:EndFrame(Single) (at Assets/Obi/Scripts/Solver/ObiSolver.cs:536)
Obi.ObiSolver:LateUpdate() (at Assets/Obi/Scripts/Solver/ObiSolver.cs:665)

Assertion failed: Assertion failed on expression: 'fRoot >= Vector3f::epsilon'
UnityEngine.Quaternion:FromToRotation(Vector3, Vector3)
Obi.CurveFrame:Transport(Vector3, Vector3, Single) (at Assets/Obi/Scripts/Actors/ObiRope.cs:61)
Obi.ObiRope:UpdateRopeMesh() (at Assets/Obi/Scripts/Actors/ObiRope.cs:962)
Obi.ObiRope:UpdateProceduralRopeMesh() (at Assets/Obi/Scripts/Actors/ObiRope.cs:892)
Obi.ObiRope:UpdateVisualRepresentation() (at Assets/Obi/Scripts/Actors/ObiRope.cs:590)
Obi.ObiRope:OnSolverFrameEnd() (at Assets/Obi/Scripts/Actors/ObiRope.cs:365)
Obi.ObiSolver:EndFrame(Single) (at Assets/Obi/Scripts/Solver/ObiSolver.cs:536)
Obi.ObiSolver:LateUpdate() (at Assets/Obi/Scripts/Solver/ObiSolver.cs:665)

Assertion failed: Invalid worldAABB. Object is too large or too far away from the origin.