Instantiate new rope on tear

[niZmo]

Like the title says I'd like to make a new rope object out of the torn ropes pieces. For what I need to do, I cannot have two pieces of a rope as the same gameObject. I was thinking of using the ObiRopeCursor. I could get the particle where the rope is torn, init a new prefab based of the length of the original rope minus the tear particle index and use the cursor to set the new and the old ropes lengths. Works in theory. Is this the way to go about it or is there an easier way? It would be a nice API addition for obi rope, a little bool parameter under the Tearable param .

[josemendez]

Like the title says I'd like to make a new rope object out of the torn ropes pieces. For what I need to do, I cannot have two pieces of a rope as the same gameObject. I was thinking of using the ObiRopeCursor. I could get the particle where the rope is torn, init a new prefab based of the length of the original rope minus the tear particle index and use the cursor to set the new and the old ropes lengths. Works in theory. Is this the way to go about it or is there an easier way? It would be a nice API addition for obi rope, a little bool parameter under the Tearable param .

Hi Nizmo! 

Why do you need each rope piece to be its own GameObject? remember that the GameObject transform is not affected by the movement of rope particles in any way, so the only benefit you'd get from it is...well, another GameObject.

ObiRopeCursors can make individual rope segments (created by cutting a rope) grow or shrink when positioned at the appropriate place in the rope, so having separate GameObjects for this purpose isn't necessary.

Also having a GameObject per rope piece could spawn lots of them in the worst case (exactly as many GameObjects as particles your original rope had, minus one), hindering performance. Honestly I cannot think of a single advantage or potential use case for this method, that's why I'm curious as to why you need it.

[niZmo]

Hi Nizmo! 

Why do you need each rope piece to be its own GameObject? remember that the GameObject transform is not affected by the movement of rope particles in any way, so the only benefit you'd get from it is...well, another GameObject.

ObiRopeCursors can make individual rope segments (created by cutting a rope) grow or shrink when positioned at the appropriate place in the rope, so having separate GameObjects for this purpose isn't necessary.

Also having a GameObject per rope piece could spawn lots of them in the worst case (exactly as many GameObjects as particles your original rope had, minus one), hindering performance. Honestly I cannot think of a single advantage or potential use case for this method, that's why I'm curious as to why you need it.

My rope are going to actually be wires. Once I cut one I can attach the ends to terminals to conduct electricity. Each wire can have different voltage, amps and what not so I have a component that takes care of what each wire is connect to and how much potential it has. If I cut a rope and it’s on the same gameobject it will be a lot harder to see what electrical potential that wire has. I’d have to keep track of the start and end particles of the torn rope to be able to do what I want. That’s a lot harder than just making a new gameobject that get its own components.

Also I have a highlight script that make the rope a color when touched in VR. Now if I cut a rope and touch a part of it, all the torn parts highlight which is not ideal.

[josemendez]

My rope are going to actually be wires. Once I cut one I can attach the ends to terminals to conduct electricity. Each wire can have different voltage, amps and what not so I have a component that takes care of what each wire is connect to and how much potential it has. If I cut a rope and it’s on the same gameobject it will be a lot harder to see what electrical potential that wire has. I’d have to keep track of the start and end particles of the torn rope to be able to do what I want. That’s a lot harder than just making a new gameobject that get its own components.

Also I have a highlight script that make the rope a color when touched in VR. Now if I cut a rope and touch a part of it, all the torn parts highlight which is not ideal.

Hi Nizmo!

I see. Solving this problem from Obi's end is actually a lot harder/uglier than solving it from yours. Instantiating GameObjects at runtime is usually discouraged in Unity due to performance spikes, so we designed Obi Rope specifically to avoid having multiple GameObjects per rope, or having to instantiate anything at runtime. Also, this way we only need 1 drawcall / mesh per rope, regardless of how many individual pieces it has been cut into. This is critical for mobile games as 100 draw calls are enough to bring most old-ish devices to their knees.

Furthermore, thanks to this all memory allocation can be statically performed to reduce garbage collection to a minimum, and to make memory usage predictable. (we allocate all we need at startup. that's why ropes have a particle pool to grab new particles from when they are torn or they increase their length, instead of just creating brand new particles). 

Physics, rendering, tearing and the rope cursor component would all have to be heavily modified (for the worse, in almost all aspects) to accommodate this GameObject based tearing system.

The approach I'd use is precisely the one you described: keep track of particle pairs and associate the circuit information to them. That's much, much faster (and easier) than having to create new gameobjects each time the rope is torn, complete with its own transform/renderer/rope components, that do very little except hindering performance.

Regarding rope color, particles have a "color" data array that allows you to colorize them individually. I can provide you a rope shader that makes the rope mesh show the color of the particles underneath it, this way you could just say "set the color of particles in the [12,16] range blue" and that rope piece would turn blue.

[niZmo]

Hi Nizmo!

I see. Solving this problem from Obi's end is actually a lot harder/uglier than solving it from yours. Instantiating GameObjects at runtime is usually discouraged in Unity due to performance spikes, so we designed Obi Rope specifically to avoid having multiple GameObjects per rope, or having to instantiate anything at runtime. Also, this way we only need 1 drawcall / mesh per rope, regardless of how many individual pieces it has been cut into. This is critical for mobile games as 100 draw calls are enough to bring most old-ish devices to their knees.

Furthermore, thanks to this all memory allocation can be statically performed to reduce garbage collection to a minimum, and to make memory usage predictable. (we allocate all we need at startup. that's why ropes have a particle pool to grab new particles from when they are torn or they increase their length, instead of just creating brand new particles). 

Physics, rendering, tearing and the rope cursor component would all have to be heavily modified (for the worse, in almost all aspects) to accommodate this GameObject based tearing system.

The approach I'd use is precisely the one you described: keep track of particle pairs and associate the circuit information to them. That's much, much faster (and easier) than having to create new gameobjects each time the rope is torn, complete with its own transform/renderer/rope components, that do very little except hindering performance.

Regarding rope color, particles have a "color" data array that allows you to colorize them individually. I can provide you a rope shader that makes the rope mesh show the color of the particles underneath it, this way you could just say "set the color of particles in the [12,16] range blue" and that rope piece would turn blue.

That shader would be awesome! Alright, I can definitely get away with keeping track of the particles, and being able to highlight without different gameObjects is amazing. Thanks!