This mess is solvable via Graph connectivity and some coding … but in order to avoid reinventing the wheel I would strongly suggest to get your Voronoi edges connected correctly instead of spending time and effort for absolutely no reason.
PS: Other than that … TS is dead (Autodesk did it again: the equivalent of Adobe killing 3D PDF). So try other solutions for thickening graphs the likes of ExoW(best IF it works), IntraLattice (bad even if it works), Dendro (no idea) etc etc : search this and the old (also dead) Forum. Plus: Daniel (the K2 man) did some stuff lately on that matter (but I have not tested a thing).
Kangaroo’s removeDuplicateLines only works with lines, not curves. Obviously your error sign shows that there’s some curves in your input data.
And you should flatten the lines input. Your image also shows your data has data tree, not a single list of data.
If you are OK with Lines (and who could tell the difference? - nobody for sure: since the end result is liquid curvy … why bother IF the axis are curves ???) use Proximity3D that can control the dMin/dMax and avoid lot’s of issues for nodes engulfed in the mesh (as is the usual case with ExoW failures - for reason or no reason). Since the nature of Voronoi is random by default (meaning tiny edges) … is the 100% wrong approach to do that kind of stuff (unless you want a bunch of faceted solids no matter how tiny they are).
That said P3D does duplicates since ouputs connections on a per node basis (meaning that for some thicken app to work you should flatten the result and remove duplicate lines via K1/K2 - or I can provide a small C# that does that).
Yikes … I use R5 (thus the option used for the Mesh from Brep Method is 100% valid ). For what GH/R usage is in the practice … R6/GH 1 have nothing to offer (plus the joy of bugs etc etc).
For the orange thingy … If the gate redirects the Graph to IntraLattice … then ExoW has no input and thus complains a bit. Switching input to ExoW leaves IntraLattice complaining blah, blah (but who cares?).
BTW: I do hope that this is just a thingy for artistic purposes. If is some sort of AEC … you date 100% the wrong girl.
BTW: Given an edgy Brep (like the one used as demo) it could be wise (as an option) to add vertices (and points on edges [N: proportional to the min edge Length]) to the pts collection - prior P3D - in order to achieve some sort of “recognizable” graph (VS the donor object). Given a mesh … well … that escalates rapidly towards 100% code driven solutions.
BTW: For freaks who lost the measure of things (easy these days) there’s another liquid approach (Is real-time meaning that’s 200++ times faster [VS the tricky part]) using 100% C# code, no ExoW or anything similar … just that K2 thingy on recursively made boxes. Now if the boxes are “thin”/elongated/many/proper … you can imagine the results.
You are crazy man … Maybe you can create some tutorials on gumroad for small price because you have a gift (i dont know way how tto learn gh . i do only try/mistake technique and dont know scripting or code.
Warning: despite several checks on the graph edges … ExoW works when it works - most propably Daniel’s stuff is the proper answer [not tested] for that kind of stuff.