Tons of problems trying to simulate simple rope without elasticity

[Romahaaa]

I can't see any links to the updated scene. Can you share it so that I may take a look?

Oh, sorry, I didn't click "Add attachement". Here it is.

Regarding pin constraints - even setting it to 100 didn't help. There is still a gap between paperclip and rope end. Paperclip mass is just  0.01.

Not sure what you mean. Triggers are part of Unity, Obi's solver interpolation has no effect on them. If you're referring to rigidbody interpolation, then yes this is to be expected: interpolation derives rendering state from physical state: objects are drawn where they should be according to render time, but as far as the physics engine goes (this includes triggers) they're located elsewhere since simulation time != render time. Same for extrapolation. I don't think this can be prevented.

No, it's not about physics interpolation because it switched off. It's easier to check the scene I attached instead of describing it. You may see the cylinder collider under the paperclip and while the paperclip position not changed (at least visually) in static state, paperclip collider triggers with that cylinder collider

[josemendez]

Oh, sorry, I didn't click "Add attachement". Here it is.

Regarding pin constraints - even setting it to 100 didn't help. There is still a gap between paperclip and rope end. Paperclip mass is just  0.01.


No, it's not about physics interpolation because it switched off. It's easier to check the scene I attached instead of describing it. You may see the cylinder collider under the paperclip and while the paperclip position not changed (at least visually) in static state, paperclip collider triggers with that cylinder collider

Hi there,

Thanks! Took a look at the updated scene, seems the culprit is just the scale at which simulation is performed. The gap between the rope and the clip is about 2 millimeters wide (0.002 world space units). This is caused by numerical accuracy within the solver: many operations have a certain accuracy limit (epsilon) to avoid division by zero. Furthermore, Unity's physics engine is velocity-based. Obi is position-based, which means adjustments to meet constraints are done at the positional level, this grants it unconditional stability since all calculations are independent of the timestep size. However when applying adjustments to Unity rigidbodies, it's not possible to directly set the position of a point in the rigidbody: it must be indirectly adjusted by applying an impulse to it. Both the epsilon and the fact that rigidbody positions are indirectly adjusted trough velocity corrections contribute to this.

There's a way to get around it though: hook to the actor's OnInterpolate event, and set the renderable particle position to the attach point on the object. This does not affect physics, but will visually close the gap with 100% accuracy as we're just copying the attachment position to the particle every frame before rendering. I've attached a modified ObiParticleAttachment.cs script that does this. In case you're interested, the code looks like this:

Code:

private void M_Actor_OnInterpolate(ObiActor actor)
        {
            if (enabled && m_AttachmentType == AttachmentType.Dynamic && m_Actor.isLoaded && isBound)
            {

                var solver = m_Actor.solver;

                var actorConstraints = m_Actor.GetConstraintsByType(Oni.ConstraintType.Pin) as ObiConstraints<ObiPinConstraintsBatch>;

                if (actorConstraints != null && pinBatch != null)
                {
                    int pinBatchIndex = actorConstraints.batches.IndexOf(pinBatch);
                    if (pinBatchIndex >= 0 && pinBatchIndex < actor.solverBatchOffsets[(int)Oni.ConstraintType.Pin].Count)
                    {
                        for (int i = 0; i < pinBatch.activeConstraintCount; i++)
                        {
                            var attachPoint = pinBatch.pinBodies[i].owner.transform.TransformPoint(pinBatch.offsets[i]);

                            // Force the visual position of the particle to match the collider's place:
                            solver.renderablePositions[pinBatch.particleIndices[i]] = solver.transform.InverseTransformPoint(attachPoint);
                        }
                    }
                }
            }
        }

You could also do this on a separate component, but having it built-in in the attachment component is probably more comfortable.This will get rid of the gap for good:



At this size though, even the slightest numerical inaccuracy becomes large enough to be noticed. You will also encounter issues with depth testing, shadows, vertex shimmering when away from the world origin, and a whole other lot of problems - that can be alleviated by adjusting camera far/near planes, shadow biases, using camera-relative rendering, using a very small physics timestep... but will make your life harder than it needs to be.

As an experiment, I created a stack of 3 2x2x2 millimeter boxes, but PhysX is unable to accurately perform collision detection. The boxes clip trough each other on the first frame and the stack immediately falls. Once on the floor, they start to slide around.




I'd guess the issue with the trigger also stems from this. If your game revolves around very small objects, I'd just fake the scale: Make everything larger in world units, and rely on relative sizes between objects to give the player the impression they're smaller. For instance if you have a paperclip and a human character, make both x 5 larger than their usual size. Since the player can only judge the size of the clip by comparing it to the human, it will appear to be very small even if it's actually not that small.

Let me know if I can help you in any way.

kind regards,

[Romahaaa]

I'd guess the issue with the trigger also stems from this. If your game revolves around very small objects, I'd just fake the scale: Make everything larger in world units, and rely on relative sizes between objects to give the player the impression they're smaller. For instance if you have a paperclip and a human character, make both x 5 larger than their usual size. Since the player can only judge the size of the clip by comparing it to the human, it will appear to be very small even if it's actually not that small.

This will not work in my case developing for AR. However, I did the tests and realized that Trigger events are not correct using MeshCollider, even with the Convex option... I didn't know that, or maybe that's kind of Unity bug.. latest 2021.2 is pretty buggy. So, replacing it to the capsule collider, everything works as expected.

There's a way to get around it though: hook to the actor's OnInterpolate event, and set the renderable particle position to the attach point on the object. This does not affect physics, but will visually close the gap with 100% accuracy as we're just copying the attachment position to the particle every frame before rendering. I've attached a modified ObiParticleAttachment.cs script that does this. In case you're interested, the code looks like this

Thanks for the script!

Btw, did you notice the real size paper clip movement when rope doesn't move? The only way I found to fix it is to set rigidbody drag and angular drag to 1. Seems paperclip still receive some impulse from the rope even when it's static

[josemendez]

This will not work in my case developing for AR.

Why not? you should be able to just scale the XR rig up. Never tried this to be honest, but some games I've played make the player larger or smaller in world space units. Unity's manual also mentions this:
https://docs.unity3d.com/Manual/configur...or-xr.html

Change the position and rotation of the XR Rig GameObject so it matches the position of the current Main Camera. If you’re applying a scale transformation to the Main Camera, make sure that you also apply this scale to the XR Rig GameObject. If you scale the XR Rig, it’s highly recommended to use a uniform scale across all three axes.

Thanks for the script!

Btw, did you notice the real size paper clip movement when rope doesn't move? The only way I found to fix it is to set rigidbody drag and angular drag to 1. Seems paperclip still receive some impulse from the rope even when it's static

Yes, this is probably due to floating point precision issues too. Objects suspended from a rope will always receive an impulse, if it's only to counteract gravity. However if their velocity is very small, Obi will apply an impulse of zero magnitude as it falls below epsilon. On the next frame, the body accelerates and the separating velocity between rope and object becomes once again enough for a corrective impulse to be applied. This will result in spurious movement or very small jittering.

Generally speaking, making things really small in games is just not a good idea. Precision issues will start plaguing both rendering and simulation, the only real fix for this is using doubles for everything but it's just too costly.

[Romahaaa]

Why not? you should be able to just scale the XR rig up.

Never tried as well. Maybe later will check it, but for now, for a single scene this setup works (more or less)

Thanks for the support. I had some weird pencil and paperclip collisions issues on free fall (probably caused by some rope force) but solved it setting both rigidbodies drag to 1 and max friction physics materials. I hope that's done for now..

[josemendez]

Never tried as well. Maybe later will check it, but for now, for a single scene this setup works (more or less)

Thanks for the support. I had some weird pencil and paperclip collisions issues on free fall (probably caused by some rope force) but solved it setting both rigidbodies drag to 1 and max friction physics materials. I hope that's done for now..

You're welcome! let me know if you need any help.

[Romahaaa]

Unfortunately I still have the issue.
There is still a gap between paperclip and rope even after replacing the script you provided.
   

[josemendez]

Unfortunately I still have the issue.
There is still a gap between paperclip and rope even after replacing the script you provided.

Hi!

I tried the script before giving it to you, it basically copies the particle position to the attachment position during interpolation (which happens in LateUpdate). It's impossible for a gap to appear unless the clip is being translated after the updater's LateUpdate().

Would it be possible for you to share the scene where this happens so that i can take a look?

[Romahaaa]

Would it be possible for you to share the scene where this happens so that i can take a look?

Sorry for later reply.
That attachement behaviour looks very weird. In some cases, it works well in Editor, but creating iOS build it looks like before with a gap.
More interesting the fact, that after that build, in Editor it returned to the "gap" old version as well. I can't tell you exactly, how this happens. Tried to change interations - nothing helps. 

One more huuuge show stopper in Unity Editor Windows versions has been found: collision contraint does such a huge lags when paperclip is moved into the water (water has Collider components set to trigger). Switching constrain off revoves all the lags.
I really don't know does it rely to asset or some 3rd party packages, like Burst and Job, but I didn't have it it on my 7 years old Macbook. PC is times more powerful than my old Macbook.

[josemendez]

Sorry for later reply.
That attachement behaviour looks very weird. In some cases, it works well in Editor, but creating iOS build it looks like before with a gap.
More interesting the fact, that after that build, in Editor it returned to the "gap" old version as well. I can't tell you exactly, how this happens. Tried to change interations - nothing helps. 

Iterations will have no effect on the gap if you're using the modified attachment script shared here, as all it does is move the last particle in the rope to the point on the rigidbody. Did you make any changes to the script?

One more huuuge show stopper in Unity Editor Windows versions has been found: collision contraint does such a huge lags when paperclip is moved into the water (water has Collider components set to trigger). Switching constrain off revoves all the lags.
I really don't know does it rely to asset or some 3rd party packages, like Burst and Job, but I didn't have it it on my 7 years old Macbook. PC is times more powerful than my old Macbook.

If you're using the Burst backend, Obi relies on Burst and Jobs to perform the simulation. There should be no discernible difference between MacOS and Windows. I'd recommend profiling to see what's causing the lag, you can share a screenshot of the profiler if you need help interpreting it.

kind regards,