Close point joint together

Hi guys.

I have problem with joint close points.

I have this :

Its looks pretty fine for me but my next step is to create
tsPipe
Uses T-Splines to pipe curves

But i need connected points.

I tried https://www.grasshopper3d.com/profiles/blogs/topologizer-network-cleanup?id=2985220%3ABlogPost%3A753116&page=2#comments

but he doesnt work for me …

Any idea ?

Thank you peter !

Peter,

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).

best

1 Like

Thank you …

I try again another way via this proces : https://www.grasshopper3d.com/profiles/blogs/introducing-exoskeleton-a-wireframe-thickening-tool?id=2985220%3ABlogPost%3A752263&page=2#comments

And my gh script show wrong on kangaroo duplicate :

I dont know … i am lost :smiley:

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.

1 Like

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).

1 Like

I tried … this is my gh script … Very thank you for your help.

puk_2.gh (10.7 KB)

NO … this is not the proper way to cut the mustard.

Demo how-to-do-it (with ExoW but try the other options as well) in a couple of minutes.

1 Like

Here comes the pain:

The def is 2 parts: the easy (for kids) and the tricky (for the real men).

Using : Topologizer, ExoW, IntraLattice, WB (Catmull-Clark) + the clean lines thingy (K1/K2).

As the values are … ExoW works (but don’t bet your life on it).

Thicken_TestUser_25A.3dm (198.3 KB)
Thicken_TestUser_25A.gh (22.2 KB)

The liquid part is slow: meaning that set the path to none while you are after your Graph. After that > Ave, Imperator, morituri te salutant.

For the record you can use TSplines on the Graph (but is even slower).

1 Like

Oh man … you are God. Very thank youuuuu. I have to check progress and your gh script.

Its perfect !

Btw i have 2 worngs but script is working.

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).

Get the trad update:

Thicken_TestUser_25B.gh (27.6 KB)

Uncomment the R6 (del //) line and comment the R5 (add //) one:

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?).

1 Like

BTW: Given a graph try Daniel’s latest stuff as well > Skeleton fattener + mesh cage morph

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.

But you must be a total freak (best avoid it).

Starts from random collection of boxes like that:

You are crazy man :slight_smile: … Maybe you can create some tutorials on gumroad for small price because you have a gift :slight_smile: (i dont know way how tto learn gh . i do only try/mistake technique and dont know scripting or code.

Not my game, I’m afraid.

Get the freaky part as well … meaning attractors that yield variable radii for that ^%^% ExoW.

Thicken_TestUser_25C.gh (154.2 KB)

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.

1 Like