Help Rope saving and restore by Json

[tapLucas]

You're setting the blueprint's resolution to 100. It can't go past 1 (distance between particle centers == rope thickness). Is this the same resolution of the blueprint you originally created?. Also make sure the blueprint thickness is the same. Otherwise the amount of particles in the blueprint as well as the distance between them will be different.

The blueprint's resolution should be 1; that was my mistake, a paste error.

Also keep in mind that Obi is a position-based engine. This means velocities are derived from positional deltas, you should set both solver.positions as well as solver.prevPositions to the same values, otherwise particle velocities will be non-zero at the start because velocity = (pos-prevpos) / time.


This will only happen if your ropes have had their length changed at runtime using a cursor, or if they have been cut. Otherwise order should be contiguous. If you're not doing either, then it means you're either storing or loading particles in the wrong order.

I will try setting the prevPositions, indeed, I  didn't set them in the code.


Well, I did indeed change the length of the rope during runtime using the cursor. Previously, I had written a random algorithm to generate key points for the rope's path, and then I added these key points to the controlPoints to make the rope generate according to this path. This approach resulted in a very long rope, with excess length bunched up, but the interweaving between the ropes was indeed effective, so I had to contract it until all the ropes were tightened, at which point the ropes had no excess length and all maintained the randomly generated interweaving state. I am not sure if this approach is reasonable.  Random algorithm is really tough to me. (I am eager to receive some recommendations for good entanglement generation algorithms. )

---

Also keep in mind that Obi is a position-based engine. This means velocities are derived from positional deltas, you should set both solver.positions as well as solver.prevPositions to the same values, otherwise particle velocities will be non-zero at the start because velocity = (pos-prevpos) / time.


This will only happen if your ropes have had their length changed at runtime using a cursor, or if they have been cut. Otherwise order should be contiguous. If you're not doing either, then it means you're either storing or loading particles in the wrong order.

kind regards

I have tried setting solver.positions and solver.prevPositions, but it didn't have much effect.

For now, it seems I have hit a deadlock. Contracting the rope to reduce the impact of the random path generation on it appears to be inevitable for me at this point.

---

This will only happen if your ropes have had their length changed at runtime using a cursor, or if they have been cut. Otherwise order should be contiguous. If you're not doing either, then it means you're either storing or loading particles in the wrong order.

When I stored the particles before, I directly iterated through rope.solverIndices. If it's because I changed the length of the rope, which caused the order of the particles to be disrupted, Then rope.elements must be continuous. I tried only using rope.elements when storing, and assigning directly to solver.positions[particlesIndices[i]] during restore, but it still didn't work. The root cause is that the order in rope.solver.positions is disordered, right?