07-09-2017, 02:14 PM
(07-09-2017, 10:54 AM)josemendez Wrote: 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!