Shortest Walk Tapered Branching Script

This is the script of Daniel Abalde's Peacock tapered offset post, here:

http://www.grasshopper3d.com/photo/the-variable-offset-component-sp...

Replies to This Discussion

Permalink Reply by Nik Willmore on February 13, 2016 at 5:35am

I'd already written an STL reader so had it ready. An STL writer will take more work. I have to think a bit about the speed of settings-tweaking workflow, for that versus what I already have.

Each run it would save instead of read an STL file and Tetgen would then also read the STL file. But I don't then have to read it in again from Python, since I already would have the mesh input to Python by wire. Sounds like it would be OK speed wise.

Ah, that would also crucially remove the oddity of needing an ASCII format STL file being made by the user. That's worth hiding in the background indeed since it's not a normal thing to create.

Permalink Reply by Thomas Helzle on February 13, 2016 at 7:24am

Ah, I didn't realize you read the stl "by hand", I somehow thought you could use Rhinos import/export tools for that in a script.

As for speed: maybe it could have a toggle button for manually firing the process, since it usually does not need to be recreated all the time?

I still haven't really dug into Grasshopper coding much since so far most things could be done with existing tools...

Thank you!

Tom

Permalink Reply by Nicolai Bauchrowitz on February 13, 2016 at 5:45am

Nice!

Still playing around with the (now working- BIG Thank you!) Variable Pipes. Will test it on the Voronoi Output later.

Have you considered making the several tetgen Flags / command line swichtes (e.g. the -q Flag) available as numeric inputs? I dont know if this is a complicated task but it would be nice to have control over the in-depth tetrahedrailisation which currently seems to be directly bound to the prevouosly generated input mesh (via Meshmachine). It seems that the -a volume constraint can only make cells smaller, not bigger...

Permalink Reply by Nik Willmore on February 13, 2016 at 5:54am

There's a reference to the flags at the end of the Python script and you can just double click it open to alter the flags at will and use the Test button to run it:

Just don't touch the -a%s or it will break the Python flow.

With the a flag set large, which I earlier mislabeled as a minimum instead of maximum, the inner tetrahedra get about as big as they possibly can while being within the -q constraints I have set that seems to give the most uniform result, the most regular tetrahedra, without freezing Tetgen. So yeah, loosen up the regularity of the tetrahedra and I guess then they can grow bigger faster by being more radical in shape! From the manual:

Do you want to automate the q settings? It's easy enough to do so manually via code.

The -O flag I can't get to do a damn thing. Try try again and the output is exactly the same as seen by sliding a baked output over and making a new one, then selecting the same portion of each via marquee and you immediately see the exact same yellow selected parts in both. I emailed the developer, at least.

Permalink Reply by Nicolai Bauchrowitz on February 14, 2016 at 10:11am

Hey Nik, thanks for the advice. I played with the -q otpions, wich helped me to reduce the line count from 45.000 to about 3500 in my guitar body model I posted earlier. I already made it ultra-rough with Mesh machine (target edge length 8 at 60 iterations).

I had the variable pipes running through cocoon last night, expecting already several hours of calculation time, but unfortunately, my Graphics Card ran out of memory as I clicked the cocoon component. No so clever to click it though, but I realized that I have to furher reduce either the lines (why cant tetgen have a minimum edge length flag? In the manual it reads you must specify a .var File to do that.

A .var file allows you to specify maximum area constraints on facets and maximum length constraints on segments. They are used for mesh refinement.

This however is really unuseful since you cannot just say "No tet can have an edge length shorter than "xx" (somewhat like Meshmachine with the target edge length) but as I understood, works only for specified areas (in the var file).

So I looked at cocoon to simplify the Marching cubes settings. I tweaked them to be not quite rough so that MM can just make it pretty enough to use.

The result is quite pleasing and very close to what I was looking for:

Another approach would be to skip the "Pipe Variable" and replace it by a Curve Charge with all the lines AND several Radii plugged into it. A while ago I noticed you can plug several Radii in, but I couldn't replicate my findings from back then today.
However, it seems that the brep charge is super-slow compared to the curve charge.

Permalink Reply by Nik Willmore on February 14, 2016 at 10:24am

I've been confused so far about the Tetgen settings files since I can't figure out which are global settings (easy) versus local settings which are very confusing since I don't know ahead of time what the lines, faces and vertices will be, now do I? Often I can't even tell if the manual is referring to the essentially 2D surface mesh or the fully 3D tetrahedral "mesh" or what a "facet" is (face?). Global settings don't seem to belong in a separate file instead of a flag, but if they are local settings, are they using multiple surface meshes or inner meshes for control or something? I so far have no idea.

Permalink Reply by Nik Willmore on February 13, 2016 at 2:17pm

Updated version of Tetgen parser: no more ASCII format STL file, that happens in the background as long as you have a Tetgen directory in your main C: drive. Of course you can change this directory in the code by double clicking to see the Python.

I separated boundary (clipped) Voronoi cells from interior ones.

It's fast enough that with the Voronoi and Tet mesh output switches toggled off you still get tetrahedral points and lines for previews as you work. Even with Tet mesh output on, it's still plenty rapid.

The mesh must be fully triangulated, or my STL writer will output each quad as only a triangle and an open triangle and who knows what Tetgen will do with holes.

Deviled Voronoi are now possible:

The internal -q Tetgen command line flag in the Python can allow the tetrahedra to be more extreme in sharp angles to allow them to grow bigger away from the boundary, or at least part of them, as they retain a sharp pointy corner towards the boundary.

The point of all this is to escape from the ugliness of random 3D point Voronoi in favor of evenly distributed 3D points, with boundary mesh control over the surface cells that then transition smoothly to the interior.

Tetgen.exe pre-compiled binaries for Windows X32 and X64:

https://github.com/JuliaGeometry/tetgen.dependency

Attachments:

Tetgen Parser N MAKES STL TEMP FILE.gh, 41 KB

Permalink Reply by Kim hauer on February 13, 2016 at 3:52pm

Very nice!

......now is this going to work with more complex geometry shapes?

I will do some testing

......thanks Nik!

Permalink Reply by Nik Willmore on February 14, 2016 at 12:47pm

Ugh, more work.

It thinks all those are interior cells too. Tetrahedra are fine.

Permalink Reply by Nicolai Bauchrowitz on February 14, 2016 at 12:58pm

Whoa. That is one spiky bunny.

Sure you can fix this ;-) . Looks like they tend towards the bounding box of the bunny....

Permalink Reply by Nik Willmore on February 15, 2016 at 3:37am

Fixed it, at the expense of speed since splitting and rejoining is faster than Rhinocommon CreateBooleanIntersection, but bookeeping is too difficult to figure out which fragments are outside the solid to be thrown away. Their area center often lies within the solid even if they are outside since after splitting with a curved mesh they can form a bowl. Checking many points of a fragment may be slow too, I imagine.

A simple obloid takes under a minute but the bunny mesh takes ten minutes. Then again the resulting model is also hard to manipulate in Rhino, so really is huge.

An email from the Tetgen developer is encouraging, so I can switch back to faster Tetgen Voronoi one day, but the slow step is the Boolean intersection of the mesh turned into a NURBS polysurface (brep) with all the cells that extend out to an overall bounding box. Tested in Rhino, it's indeed slow. Tetgen will likely not be providing clipped Voronoi output, ever, I imagine, though I put in a request. Actually, it's rather easy to test for outer/inner fragments after splitting Tetgen Voronoi cells since the outer ones are open instead of closed so when split have either one open edge loop or two.

"Hi Nik Willmore,

Thank you for your bug report.
I will check it and fix it in the next release version.

For the -O option, it currently only supports numbers from 1 to 9.
The current implementation for the -O option may not be suitable to use a larger number.
It needs to be improved in the future.

By the way, the grasshopper3d project seems very interesting.

Thanks again

Hang Si /span>si@wias-berlin.de>"

Enclosed is the update that now has a rather short script.

Turning off Grasshopper preview mesh at the right of the toolbar can save lots of time when tweaking parameters since that's a lot of preview meshes to create from NURBS breps.

Attachments:

Tetgen Parser P USES RHINO BOOLEAN DIFFERENCE.gh, 44 KB

Permalink Reply by Nik Willmore on February 15, 2016 at 3:53am

Weaverbird Split Triangles can improve the Tetgen tetrahedral display, which look weird in Rhino since each face is a single face, I believe:

I included the bakeAttributes component in the Tetgen Parser since I realized instead of an obscure plug-in it's just a C# script by Giulio Piacentino.