Bug / Crash Baking a rope is causing unity crashes (unity 6.0.29f)

[gnovos]

I'm either doing something completely wrong, or else running into a editor-crashing bug.

Let me start by stating my goal in case I'm completely barking up the wrong tree.  What I want is to have an ObiRope swing for a few seconds, then freeze it into place and then use it as just a standard mesh from that point on.  The way I'm trying to solve this is code like this:

Code:

    public void BakeRope()
    {
        if (ToBake.actor.isLoaded)
        {
            var system = ToBake.actor.solver.GetRenderSystem<ObiRopeExtrudedRenderer>() as ObiExtrudedRopeRenderSystem;

            if (system != null)
            {
                var mesh = new Mesh();
                system.BakeMesh(ToBake, ref mesh, true);
                Rope.enabled = false;
                ToBake.enabled = false;
                Filter.sharedMesh = mesh;
            }
        }
    }

This *sometimes* works.  But it often simply crashes the editor (and a similar crash in a full build).

The relevant part of the crash output looks like this:

Code:

0x00000243F7763DAB (Mono JIT Code) UnityEngine.Mesh:SetSubMesh (int,UnityEngine.Rendering.SubMeshDescriptor,UnityEngine.Rendering.MeshUpdateFlags)
0x0000024250625E13 (Mono JIT Code) Obi.ProceduralRenderBatch`1<Obi.ProceduralRopeVertex>:BakeMesh (int,int,int,int,UnityEngine.Matrix4x4,UnityEngine.Mesh&,bool)
0x00000242506252AB (Mono JIT Code) Obi.ObiExtrudedRopeRenderSystem:BakeMesh (Obi.ObiRopeExtrudedRenderer,UnityEngine.Mesh&,bool)

My question is basically, is this a bug or is there some more proper way to lock a rope's mesh into place and stop the obrirope calculations on demand?

[josemendez]

Hi,

I'm unable to reproduce this. Which simulation backend are you using? Asking because baking works slightly differently depending on whether mesh data is already on the CPU (When using the Burst backend) or when it needs to be read back from the GPU (Compute backend).

Note that baking a mesh is extremely expensive, so not generally used at runtime. This is more of an editor tool. The typical approach to stop updating a simulation is to set the solver's maxStepsPerFrame to 0. This will keep rendering all actors managed by the solver, but will completely stop the simulation. This does not however allow to stop the simulation of specific ropes, only entire solvers.

kind regards,

[gnovos]

Hi, thanks for the reply!  So, this is on the GPU back end, and I'm using the new GPU resident Drawer and GPU occlusion culling in unity 6.  I don't know if those things matter, but since I don't know how they work exactly, so maybe they're interfering?   Regardless, what I'm trying to do is allow the player to make permanent bridges out of ropes.  While the bridge is being constructed, the rope can be dragged and will jiggle around as normal, but once the player is done placing it and after the rope stops swinging, it's done building, and then becomes permanently fixed and will never move again.  I just need the mesh itself and no longer need any calculations after that.  There might be any number of these bridges so I want to make sure they aren't needlessly running calculations even though they'll never move again since I already have a tight cpu budget.  Is there a better way to do this?

[josemendez]

Hi, thanks for the reply!  So, this is on the GPU back end, and I'm using the new GPU resident Drawer and GPU occlusion culling in unity 6.  I don't know if those things matter, but since I don't know how they work exactly, so maybe they're interfering? 

They should not stand in each other's way, even though it's all done in the GPU they're separate systems.

 Regardless, what I'm trying to do is allow the player to make permanent bridges out of ropes.  While the bridge is being constructed, the rope can be dragged and will jiggle around as normal, but once the player is done placing it and after the rope stops swinging, it's done building, and then becomes permanently fixed and will never move again.  I just need the mesh itself and no longer need any calculations after that.  There might be any number of these bridges so I want to make sure they aren't needlessly running calculations even though they'll never move again since I already have a tight cpu budget.  Is there a better way to do this?

Yes, in that case you'll need to bake the meshes. I'll try to reproduce this and get back to you asap.

kind regards,

[gnovos]

Something weird to note, when I build the game and quit using Application.Quit I get a lot of these messages, usually one or two per rope: 

Code:

GarbageCollector disposing of ComputeBuffer. Please use ComputeBuffer.Release() or .Dispose() to manually release the buffer.
GarbageCollector disposing of GraphicsBuffer. Please use GraphicsBuffer.Release() or .Dispose() to manually release the buffer.

I disabled all the Obi stuff and those messages went away, making me think the source is Obi somehow, but I went through all the code and it seems at a glance to to clean itself up properly so I don't have a clue why it's happening.  I don't know if that's related or not.  If you can't reproduce I'm wondering if my graphics card is somehow just on the verge of crapping out.  I'll try to find another machine to test on.  Cheers.

[josemendez]

Hi,

Could reproduce the original issue while baking ObiRopeExtrudedRenderer. Looks like the issue has to do with baking ropes using a non-zero decimation factor in their ObiPathSmoother, trying to bake them results in incorrect vertex indices being passed to the baked mesh. Will get back to you with a patch asap.

kind regards,

[josemendez]

Hi,

Attached you'll find a patched version of  Obi/Scripts/Common/Rendering/RenderBatches/ProceduralRenderBatch.cs. Replace the one in your project with this, it should fix the issue.

Let me know if the problem persists or if you find any other issue.

kind regards,