Tons of problems trying to simulate simple rope without elasticity

[Romahaaa]

Did you make any changes to the script?

Of course! As I said, yesterday I saw it working well in MacOS Unity Editor, created the build for iOS and it the gap was there. After that it was wrong in MacOS Unity Editor as well. No changes were made during that process.. really weird

UPDATE!
I found the way to reporoduce the issue. Important to note that my scenes are part of addressables groups. For this current scene I used Local Group temporarily to include it in device build. When scene is completed, I move it to Remote. 
So, it's in LocalGroup. Let's start fromthe point when new scripts works and there is no gap.

1. build/update addressables
   
2. run Editor with "Use Asset Database" Play mode scrupt - the gap appears. Same if you build for device.
   
3. to fix it, need to remove ObiParticleAttachment component from the rope and add new now with the same params
   
4. run Editor - works 
   

[josemendez]

Of course! As I said, yesterday I saw it working well in MacOS Unity Editor, created the build for iOS and it the gap was there. After that it was wrong in MacOS Unity Editor as well. No changes were made during that process.. really weird

UPDATE!
I found the way to reporoduce the issue. Important to note that my scenes are part of addressables groups. For this current scene I used Local Group temporarily to include it in device build. When scene is completed, I move it to Remote. 
So, it's in LocalGroup. Let's start fromthe point when new scripts works and there is no gap.

1. build/update addressables
   
2. run Editor with "Use Asset Database" Play mode scrupt - the gap appears. Same if you build for device.
   
3. to fix it, need to remove ObiParticleAttachment component from the rope and add new now with the same params
   
4. run Editor - works 
   

Hi there!

Will try to reproduce it using addressables, and get back to you.

[Romahaaa]

Hi there!

Will try to reproduce it using addressables, and get back to you.

Any update?

[josemendez]

Any update?

So far I've tried the steps you outlined and I've been unable to reproduce this. I'm trying to figure out if component update orders might play a role in this, will post any findings later today.

[Romahaaa]

So far I've tried the steps you outlined and I've been unable to reproduce this. I'm trying to figure out if component update orders might play a role in this, will post any findings later today.

Hm.. Then it will be pretty hard to find the real issue... Maybe some 3rd party asset conflict..

[josemendez]

Hm.. Then it will be pretty hard to find the real issue... Maybe some 3rd party asset conflict..

Hi there,

Could successfully reproduce, find and fix the issue. The culprit was indeed component update order:

The modified script I sent you hooks to the actor's OnInterpolate event. There, it forces the renderable position of the attached particle to be that of the attachment point. So far so good.

Problem is, the ObiPathSmoother component that prepares the rope for rendering also does its work by subscribing to in OnInterpolate. Both ObiParticleAttachment and ObiPathSmoother subscribe to OnInterpolate() during their OnEnable() method.

Since the order in which Unity calls events (Awake(),OnEnable(),Update(), etc) for different objects is undefined by default, you get two possible outcomes:

A) the attachment subscribes first, the path smoother second. Every frame, the attachment modifies the particle's position and then the smoother renders it. All works good.

B) the path smoother subscribes first, the attachment second. Every frame, the smoother renders the rope and then the attachment modifies the particle's position, but this has no effect since the rope has already been rendered. Bummer.

This was hard to reproduce since either A) or B) would happen entirely *at random*. Can be fixed by changing script update order in Unity, but the best, most robust fix is to ensure the attachment snaps the particle position before OnInterpolate. This can be done by subscribing to the solver's OnInterpolate (which is called right before all actors have their OnInterpolate event triggered) instead of the actor's.

I've attached an patched script. My apologies for not catching this one sooner!

let me know if I can be of further help.

[Romahaaa]

let me know if I can be of further help.

Hi,

Just now I found a time to return to that project. The connection point seems ok now, but... I was surprised that my scene with ObiRope which worked absolutely smoothly before now (after updating to Unity 2021.2.17f1) lag soooo much. Up to 500ms on scene start and ~100ms all the time after. 
Please check profiler screenshot here

[josemendez]

Hi,

Just now I found a time to return to that project. The connection point seems ok now, but... I was surprised that my scene with ObiRope which worked absolutely smoothly before now (after updating to Unity 2021.2.17f1) lag soooo much. Up to 500ms on scene start and ~100ms all the time after. 
Please check profiler screenshot here

According to your profiler, FixedUpdate() is being called 50 times per frame. Normally it would be called 0-1 times. So this means your game is doing x50 the amount of physics work per frame it should do.

This means: your code is running extremely slow, your timestep settings are way off, or both.

You'll get sluggish performance if there's any kind of debugging mode enabled. Either deep debugging or the jobs debugger will make all code in your game run really slow.

Your timestep settings may be an issue too. Make sure your maximum fixed timestep is not some huge value, it should usually be a small multiple of the fixed timestep. Eg; for a fixed timestep of 0.02, use a maximum fixed timestep of 0.04, 0.06, or 0.08. These settings can be found in Unity's Time options (Project Settings->Time)

[Romahaaa]

According to your profiler, FixedUpdate() is being called 50 times per frame. Normally it would be called 0-1 times. So this means your game is doing x50 the amount of physics work per frame it should do.

This means: your code is running extremely slow, your timestep settings are way off, or both.

You'll get sluggish performance if there's any kind of debugging mode enabled. Either deep debugging or the jobs debugger will make all code in your game run really slow.

Your timestep settings may be an issue too. Make sure your maximum fixed timestep is not some huge value, it should usually be a small multiple of the fixed timestep. Eg; for a fixed timestep of 0.02, use a maximum fixed timestep of 0.04, 0.06, or 0.08. These settings can be found in Unity's Time options (Project Settings->Time)

The only changes I made set timestep from 0.02 to 0.01 as you recomended before for proper Rope simulation.
I disabled Jobs Debugger, and profiler deep profiling switched off.

The result on timestep 0.01 here. How you may see, there are 50 calls at the beginning and it falls to 20 after some 5 seconds.

The result on timestep 0.02 here. It runs much beter after 5 seconds, but at the beginning there is a huge spike still. 

To keep the rope behaviour realistic I need to keep timestep 0.01. That just didn't work better on higher values. But.. the weird think that scene was completed and tested on the devices about a month ago, and everything was ok there. Since that time I have updated Unity version from 2021.2.7 to 2021.2.17. Nothing else was changed.

Of course, I tried to disable Rope on the scene at all to eliminate the issue, and without ObiRope everything is smooth even on 0.01

[josemendez]

The only changes I made set timestep from 0.02 to 0.01 as you recomended before for proper Rope simulation.

A timestep of 0.01 is fine. Note that changing the timestep affects all physics in your scene (Obi or not).
What's your maximum fixed timestep value? Assuming your timestep is 0.01, it must be something like 0.5 for Unity to think it needs to take 50 physics steps every frame?

The only other thing that comes to mind: is Burst compilation enabled at all?

The result on timestep 0.02 here. It runs much beter after 5 seconds, but at the beginning there is a huge spike still.

By default, Burst uses async compilation so there will be a large spike at startup, while Unity compiles the code. Disabling it should make any spikes go away. See: http://obi.virtualmethodstudio.com/manua...kends.html

"keep in mind that Burst uses asynchronous compilation in the editor by default. This means that the first few frames of simulation will be noticeably slower, as Burst is still compiling jobs while the scene runs. You can enable synchronous compilation in the Jobs->Burst menu, this will force Burst to compile all jobs before entering play mode."