07-09-2017, 10:54 AM
(This post was last modified: 07-09-2017, 10:58 AM by josemendez.)
(06-09-2017, 10:42 PM)niZmo Wrote: 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.