Adding Weld to solver causes segv

[SamHSmith]

Hi, I am having some issues with using constraints.

        Weld w = new Weld();
        w.SpringSettings = new SpringSettings(0, 1);
        w.LocalOffset = offset.position;
        w.LocalOrientation = BepuUtilities.Quaternion.Identity;

        weld=LogicMaster.Simulation.Solver.Add(body.Handle, g.body.Handle, w);

This code does not throw any errors but the last line causes the program to crash on the next timestep. Here is the stack trace:

  at BepuUtilities.Collections.QuickList`1:AddUnsafely <0x00091>
  at BepuPhysics.Trees.Tree:RefitAndRefine <0x004eb>
  at BepuPhysics.CollisionDetection.BroadPhase:Update <0x001fb>
  at BepuPhysics.Simulation:CollisionDetection <0x0012b>
  at BepuPhysics.PositionFirstTimestepper:Timestep <0x0022f>
  at BepuPhysics.Simulation:Timestep <0x00132>
  at Fabricor.Main.Logic.LogicMaster:Update <0x005d7>
  at Fabricor.Main.FabricorWindow:OnUpdateFrame <0x000ab>
  at OpenTK.GameWindow:OnUpdateFrameInternal <0x000cf>
  at OpenTK.GameWindow:RaiseUpdateFrame <0x000cb>
  at OpenTK.GameWindow:DispatchUpdateFrame <0x001b7>
  at OpenTK.GameWindow:Run <0x006c7>
  at OpenTK.GameWindow:Run <0x00077>
  at Fabricor.MainClass:Main <0x000ff>
  at <Module>:runtime_invoke_void_object <0x0013d>

Does anybody know what I am doing wrong to cause this?

[RossNordby]

Constraints with a position goal cannot have zero stiffness; it results in a singularity when computing internal CFM/ERP equivalent parameters and NaNs will infect the simulation. Without additional instrumentation, NaNs usually get (catastrophically) detected first in the broad phase.

I added a little bit of validation to catch this sooner: 7df129adff9c54e187425a51ba1cb23ad6302e69

[SamHSmith]

So what setting should I use? Changing the spring settings to 1 and 0.9 pushes the crash further on but It still crashes after a couple seconds.

The reason I am doing this is because I got errors when trying to create a bigcompound of bigcompounds. So I gave up and thought I could weld them together instead. Maybe there is a way to achieve the first approach.

[RossNordby]

A positive frequency and a nonnegative damping ratio should not crash. If you're still seeing a crash, there is something else going on- if you aren't already, I'd recommend running the library in debug mode and seeing if there are any asserts being hit earlier than the final crash. If there are no other obvious culprits, I could use an isolated reproduction case (in the demos or in a standalone minimal application) to analyze it more deeply.

Regarding compounds- nesting is not supported. Compounds and BigCompounds are designed to take a list of convex children directly for reasons of simplicity and performance. If you want to combine two compounds, you can create a new compound that contains all of the children of the two merging compounds directly.

[SamHSmith]

Is there a way to update a shape after it has been added to simulation.shapes. See my problem is that I need to be able to update a really large big compound. It is for a voxel type thing and I need to update this giant bigcompound with out rebuilding the entire object.

[SamHSmith]

Can bepuphysics v2 support this kind of big compound cube collision or should I switch to another physics engine?

[RossNordby]

Is there a way to update a shape after it has been added to simulation.shapes. See my problem is that I need to be able to update a really large big compound. It is for a voxel type thing and I need to update this giant bigcompound with out rebuilding the entire object.

Yes:

ref var compoundReference = ref Simulation.Shapes.GetShape<BigCompound>(indexInShapeBatch);

Or a slightly lower level access, grabbing the direct pointer:

Simulation.Shapes[shapeIndex.Type].GetShapeData(shapeIndex.Index, out void* shapePointer, out _);
ref var compoundReference = ref Unsafe.AsRef<BigCompound>(shapePointer);

Modification to the compound itself assumes some degree of responsibility on the part of the user. The API- like with most things in v2- is very low level and doesn't define a fixed way to interact with the underlying data. If you're making a small change that doesn't significantly affect the topology of the tree, you could get away with just doing the removal (or a refit, if a child moved a bit). For larger movements or topology changes, you'd probably want to consider a RefitAndRefine execution. It incrementally improves the tree. If you ran one of those occasionally or after a batch of changes, the tree would retain a high level of quality.

For extreme changes, you may want to consider running a full new sweep build from scratch.

Can bepuphysics v2 support this kind of big compound cube collision or should I switch to another physics engine?

Yes, it can do it. You might want to look at the CustomVoxelCollidableDemo in the Demos project. Using a BigCompound would work too, but a voxel world tends to have structure that means you don't actually need to have a full compound child definition.

The CustomVoxelCollidableDemo is just an example, though. It's not the best possible voxel implementation- it uses the same acceleration structure as the BigCompound, in fact. But if you wanted to go deeper with customization, it might be a good starting point.

Note that having a few thousand separate static objects in a simulation is perfectly fine, so having a bunch of separate 'chunks' each represented by a BigCompound or some specialized voxel type might be an easy way to handle things for the sake of data streaming and whatnot.