I was experimenting with a rope tethered on one end, with a loose rigidbody attached on the other end.  Then I had a mesh with a big hole in it that I added an Obi Collider to.  I pushed the rigidbody through the hole and it fell through pretty normally.  But then if I start moving the rigidbody it can start to cut through the mesh collider of the model with the hole.

This can seemingly be fixed by adding an Obi Rigidbody to the rigidbody (had to tinker with collision categories so rope wouldn't freak out due to having the end embedded in the rigidbody object, putting them on different categories), and then also setting the attachments dynamic.  I assume that is the correct procedure.

I'm still having issues with initialization though.  Even though the entire rope is suspended above the mesh with the collider before starting, after going into play mode sometimes part of the rope is stuck inside or beneath the mesh with the hole in it.  How to I avoid this reliably?

   

Thanks for any tips,

EDIT:  I added a couple of screenshots for reference.  Put them together in one image as I was having trouble getting it to accept attachments.  One is the layout as it looks in the editor.  The other is in play.  The rope has moved a bunch from it's starting position and part of it has embedded in the mesh beneath it.

- Skotty

One last noob question.  What is the right way to do a long suspended rope (like a power line as an example)?  I played with various stretching parameters, mass scale, and one or two other things, but the rope would always drag all the way to the ground (even with stretching scale at 0.001 and stretch compliance at 0).  The one thing that worked was to reduce gravity in the solver.  I can make that work, but is it the right solution?

I only need a couple of such ropes.  And I could (and may yet) switch those to just static meshes since these particular ones don't really need to move.  But I'd still like to know is there are other parameters I should be adjusting for a long suspended rope.

Thanks,

Skotty

New user here.  Product looks really good so far.  A quick noob question I hope someone doesn't mind answering.  I know there is an Ambient Wind setting on the Obi Solver that ropes react to, but I've been playing around and the rope always seems to stabilize and stop moving (my test rope is hanging suspended between two particle attachments).  If I want some sort of simulated wind turbulence where the rope keeps moving, do I:

1)  Adjust the settings somehow for that?  If so, what's the trick?

2)  Use a script, get the Obi Solver component at runtime, and dynamically manipulate the Ambient Wind value (assuming it's accessible)?

3)  Use a script, dynamically manipulate some control points at runtime to simulate the effect.

4)  Something else.

Thanks!

- Skotty

Hi! I've been trying to find a proper solution to this for awhile but after struggling on it for quite some time and not being able find a relating thread, I decided to ask.

My case is a 2d platformer, I have two player connected to each other utilizing obi rope's particle attachment. However, gameplay requires some specifics I'm having a hard time achieving. The rope as it does and should, restricts the players from running too far from each other, respects colliders, is affected by gravity. The issue is the rope's weight.

The issue with the rope's weight/ or rather MASS SCALE, is that it drags the players down and causes movement to be inconsistent when consistency is needed. This issue is amplified when a bunch of slack is hanging off a ledge and the tries to jump, they'll be pulled right back down. 

So, what I'm hoping for some guidance on is: how do I make the rope's mass negligible when it comes to dragging down on the players, allowing the rope to be a only a distance restraint?

Few Attempted Solutions
Raising player mass seems like a good direction, but then it really starts to break the rope/ make it stretch and clip through colliders. Is the only real solution to that trying to raise the sub-steps of distance constraints and collisions really high?

An idea I had was trying to get the total downward pull of the rope, divide that up by active particles, and then apply a constant force to those particles until the player no longer has a positive y velocity. However, that doesn't seem to work, even if it's gravity is set to 0 to in parallel to the jump. This is probably because the weight of the rope is already below the playing suspended so it's dragged down before it has a change to take of still.

Any help or guidance in the right direction would be super useful! Thanks!

Hello! I've been working on a project with multiple contributors and noticed that the ObiEmitters have a serialized field called solverIndices, inherited from the ObiActor. I've noticed that it's common for the solverIndices to be re-serialized, leading to rather messy diffs.

As far as I can tell, this field seems to only be used for the runtime fluid simulation, and probably shouldn't be serialized, but I'm wondering why it might be.

Is this to survive domain reloads? In that case, there might be other ways around it, like storing the solverIndices that need to survive as part of a ScriptableObjectSingleton. Or would there be any other way to needless diffs?

Hi,

We're using Obi Cloth alongside Lattice Modifier Asset on skinned cloth. Because ObiSkinnedClothRenderer.ValidateRenderer() sets skinnedMeshRenderer.sharedMesh = null at runtime and rendering goes through Graphics.RenderMesh on a batched mesh, any SkinnedMeshRenderer-based modifier silently no-ops — which is a perfectly reasonable design, it just isn't reachable from outside.

We solved it by dispatching the deformer's compute kernel over our renderer's slice of the batch mesh after your render system writes it. That works well, but it needs three protected fields on ObiClothRenderSystem (sortedRenderers, batchList, vertexOffsets), which we currently reach by reflection. Two small additions would remove that entirely:

1. A public renderer → batch-geometry accessor. DynamicRenderBatch and its mesh field are already public; this just exposes the mapping:

// ObiClothRenderSystem
public bool TryGetRenderGeometry(ObiClothRendererBase renderer,
                                out Mesh batchMesh, out int vertexOffset, out int vertexCount)

2. Set GraphicsBuffer.Target.Raw unconditionally in DynamicRenderBatch.Initialize, not only when gpu: true. On the Burst backend we currently set mesh.vertexBufferTarget after the buffers already exist. It does work — your Compute backend relies on the same ordering — but it's undocumented, so we'd rather not depend on it.

^Claude Feedback after finding a solution of integrating

Hello,

I found two contact-related issues that appear to depend on the number of substeps in Obi Rope 6.5.4 using the Burst backend.

Test setup:

- Rod mass: 2.1 kg (21 particles, 0.1 kg each)
- Fixed timestep: 0.01 seconds
- Incline angle: 45 degrees
- Static friction coefficient: 1
- Dynamic friction coefficient: 1
- Rolling contacts: disabled
- Sleep threshold: 0

Under these conditions, both the expected normal force and the tangential component of gravity are approximately 14.57 N.

1. Normal contact force measurement
Simply dividing the final normalImpulse value by either the fixed timestep or the substep duration did not produce an accurate force.
The positional correction applied by the contact constraint is scaled using the number of remaining substeps. 
Does this mean that each change in the normal constraint multiplier must be converted using the remaining time at the corresponding substep?

In my tests, the following conversion produced a normal-force estimate consistent with the expected value:

normal impulse increment = change in normal Lagrange multiplier / (remaining substeps × substep duration)

This requires recording the change in normalImpulse at every substep.
 I could not reconstruct the normal force over the full physics step from the value obtained only in the final collision callback using a single time value.

2. Friction behavior
The friction issue appears to affect not only force measurement but also the motion produced by the simulation.
With one substep, the cable remained approximately in equilibrium on the 45-degree incline. 
However, with two or more substeps, the cable slid down the incline even though the timestep, friction coefficients and constraint iteration count were unchanged.

In a representative test with three substeps:

- Normal force: approximately 14.57 N
- Friction force actually applied by the simulation: approximately 10.3 N
- Expected limiting Coulomb friction: approximately 14.57 N

The friction force reconstructed from the contact data agreed with the value calculated independently from the cable’s momentum change. 
Therefore, the lower friction value was not only caused by an error in reading the collision callback. The simulation itself appeared to apply approximately 10.3 N of friction.
This suggests that the normal impulse used to calculate the Coulomb friction limit may be underestimated when multiple substeps are used.
To address this behavior, I converted the change in the normal Lagrange multiplier at each substep into a normal impulse using the corresponding remaining interval.
I then accumulated these impulses and used the accumulated value to calculate the Coulomb friction limit.

I would like to confirm the following points:

1. In Obi 6.5.4, does normalImpulse require a correction that accounts for the number of remaining substeps?
2. In the Burst backend, can the friction limit used by the simulation depend on the number of substeps?
3. Is converting each substep’s change in the normal Lagrange multiplier using its corresponding remaining interval, accumulating the resulting normal impulses, and using them for the Coulomb friction limit consistent with the intended solver implementation?
4. Has this behavior been changed in newer versions of Obi?

Thank you.

Hi, I am working on making a tubular structure which can be squashed, stretched, twisted etc..... I've tried to make one using cloth physics, the problem there is that it cant revert back to it its original shape and it collapses, I want logic which can retain back to its original shape, supports compression, cutting/tearing, allows internal collisions and lets objects pass through it. open for any suggestions as I am a beginner.

Hey all!

Long time Obi user here. We have just released a trailer and Steampage for our game that is making extensive use of Obi. Actually, all of the game is made using Obi - I had to drop rigid body-Obi interactions to get the physics as tight as possible.



Please consider wishlisting here:
https://store.steampowered.com/app/43729...xpedition/

hi, I'm trying to set up the common use case of an animated character with softbody physics layered on top.

I tried copying the setup from the FBVS sample scene, but the simulation doesn't seem connected to the character's skeleton at all, and just falls to the ground.

How does the FBVS establish a one-way constraint from the softbody particles? Does the solver just detect that there are skeletal particles in the blueprint? Are there restrictions on how the skeleton hierarchy must be set up? I've reviewed the manual in depth but it doesn't have many details.

here's a video that shows the various issues i'm hitting, as well as the scene and blueprint setup. warning slightly NSFW: link

(i did use a skin map to mask out parts of the character, but disabled it to record the video so i could show more clearly what's going on)

I hope I can get it working; excited about the potential!