Help Rope saving and restore by Json

[josemendez]

If I do not check whether "i < particlesIndices.Length", then the following code "solver.positions[particlesIndices]" will cause an out-of-bounds error. The number of actor.solverIndices is often much smaller than the number of particles read from the JSON. I believe this may be because, when instantiating the rope, the initial path only sets the start and end point.

Hi,

You're only storing particle positions and total rope length, but not storing constraint counts, parameters, elements, or anything else really. This assumes all other data that makes up the rope is the same for both the rope you store them from and the one you write them to. Is the rope you're using to deserialize your data the same you're using to serialize it?

Based on your post, my guess is that prior to deserializing your data you're instantiating a blueprint with just start/end control points. This will create a straight rope between both points, which will of course be shorter than the original one and have less particles and less constraints as a consequence.

If your goal is to save and then restore the particle positions, you must make sure the rope you're restoring them to is the exact same one you stored them from. This means using the same blueprint, and if you're using a cursor to change its length or you're tearing the rope, both ropes must undergo the same sequence of operations. Otherwise it stands to reason that it might have a different amount of particles, constraints, elements, etc and your code will break.

Or is there a better and more efficient way to generate a rope with a specific shape at runtime based on the data?

This is what blueprints are designed for: they define all properties of a rope just by storing a handful of control points. They also generate elements, constraints and particle data automatically upon being instantiated in a solver. They're also assets (scriptable objects) so they can be automatically serialized to disk. And if you're using asset bundles/addressables, they can also be remotely stored on a server.

Only situation where you can't rely on blueprints alone is when the rope's topology changes at runtime: when you've changed its length using a cursor, or when it has been torn/cut. In these cases you should store particle/element data instead.