15-07-2021, 03:38 PM
(This post was last modified: 15-07-2021, 03:40 PM by josemendez.)
(15-07-2021, 03:20 PM)xeetsh Wrote: Yeah that also makes kind of no sense to me. I'll try building a minimal scene with the rope in it where the problem occures as I can't send you the entire project (It's really big and I'm afraid I'm not allowed to send the whole project anyways) I'll hit you up once I've have something I can send to you.
On another note I'm afraid in an isolated context everything will work fine as I tried to put the rope from a Obi demo scene in my scene and for some reason the performance also dropped way down. The PhysicsFixedUpdate of the Obi Fixed Updater took 80ms in my scene and 0.8ms in the demo scene with exactly the same setup. Of course my scene is really complex, with a lot of normal and also Obi colliders but I placed the demo nowhere near any of them floating way above the ground. Maybe this info is of any help.
What are your project timestep settings? If the exact same rope runs in 0.8 ms in the sample scene but 80 ms in yours, makes me suspect that death spiraling might be the problem.
Look if FixedUpdate() is called more than once per frame in the profiler. That would mean adding the rope puts just enough strain on your scene to send the entire physics loop over the edge and start updating more than once per frame since it can't keep up with rendering.
Also, one thing I just noticed is that you have "Substep Unity physics" enabled in your ObiFixedUpdater, but you're not using substepping at all (just 1 substep/frame). This will make all physics in your scene appear under the ObiFixedUpdater() call in the profiler, as Obi is in charge of updating all physics in the scene when this is enabled. So these 9 ms in your original profiler pic account for the rope, plus all other physics happening in your scene. Not that it really matters, but can be confusing.