25-06-2024, 09:23 AM
(This post was last modified: 25-06-2024, 09:33 AM by josemendez.)
(25-06-2024, 09:02 AM)tapLucas Wrote: Before I was preparing to implement the function of restoring ropes with data, I saw the above two posts in this forum. They all used the method of particle positions to restore the original shape of the rope, and from the responses in the posts, they seem to have succeeded.
Both the above posts use the exact same rope for both serialization and deserialization, which doesn't seem to be your case: you don't have any pre-existing rope to set particle positions to, since the original rope is gone. All you have is the data in your JSON, so you need it to contain a complete description of the rope.
Creating a different rope and then just setting the position of its particles won't work since the amount of particles and their order in the rope won't be the same, the rest distance between them won't be the same, the constraints holding them together won't be the same, etc.
To give you a real world example: imagine someone built a car, and then sent you data so you can build the exact same car without having ever seen it before. However this data only consists of the color of the car and the type of gearbox used. How can you be expected to build the same thing?
(25-06-2024, 09:02 AM)tapLucas Wrote: In addition, after using the Obi Rope plugin, my understanding is that it only requires basic particles to draw a complete rope.
Not at all: particles are just lumps of mass, all they can do by themselves is fall due to gravity. They need to somehow relate to and interact with each other in order to form any coherent shape such as a rope. This is done using constraints. In case of a rope, this involves distance and bend constraints. Quoting the asset's description:
Quote:Everything in Obi is made out of small spheres called particles. Particles can interact with each other, affect and be affected by other objects through the use of constraints.
Additionally, information about the topology of the rope needs to be stored for cases where the rope is cut/resized at runtime and particles/constraints need to be created/destroyed/reordered. This is done using elements.
Also particles have a lot more data than just positions: they have a size, they have mass, etc. Storing particle positions alone is not nearly enough to completely define a rope, or any kind of deformable object really.
(25-06-2024, 09:02 AM)tapLucas Wrote: Because I am developing a game that can be social in the future. For example, I made some complex entangled ropes, and when I want to share them with friends for decryption, I only need to serialize the rope data into JSON. Essentially, what is shared is just a string of characters.
If you want to send text data (instead of binary) over the network JSON is a good choice. However you can't just send particle positions unless all other data is the same both on the sending and the receiving end.
Assuming you want to store and send all the necessary data, and that your rope's topology doesn't change at runtime (no resizing or tearing) your best course of action is to store the blueprint's control points in JSON instead.
kind regards,