Custom Unit Cell Bug in IntraLattice Plug-In

IntraLattice is an important plug-in since it affords arbitrary 3D lattices of lines or even curves to be thickened into strut/hub systems very quickly compared to marching cubes methods. It does so by turning lines into stacks of anti-prisms and then calculating a triangulated convex hull around each hub that uses the vertices of the ends of such struts. The low poly result can be subdivided (Weaverbird Loop) to smooth it.

It comes with several preset unit cell types for filling arbitrary bodies with a lattice, and also has a custom unit cell component. But it's broken.

IntraLattice has a tolerance bug that is easy to fix by just scaling your model up 10X when you notice bad mesh results. This is a separate issue.

It's as if it doesn't like lines to end on edges of the unit cell, only faces and corners. A diagonal line from edge-to-edge (and then all lines split with each other) goes missing, half missing, or oddly enough becomes zig-zag in the array when it should be straight.

I also don't like that the developer added a limitation error warning that all faces must have a line on them. This means I can't fill space with layered spaces in between trusswork, for instance.

The custom unit cell code also sadly rejects curves, yet IntraLattice itself can handle curves just fine.

I also note that that clean-up component only removes duplicate lines, fine, but it doesn't join pairs of co-linear lines, something that occurs often when playing around with unit cells. This seems to cause bad meshes since it tries to put a hub where the line segments need merely be joined or treated as one line.

There's also a bug in the nice custom mesh preview component that sometimes has the preview stuck on even if you delete the component from the Grasshopper canvas since disabling it or shutting off preview of it fails.

It's been two years since an update to this open source plug-in, so I've contacted the developers on Github since the contact form is Server Error 500: http://intralattice.com/contact/

On Github, he promises a new version in 2017 as a stand-alone application, so I hope this extends to Grasshopper in some way, if not directly, then as some way to hook into it.

Replies to This Discussion

Permalink Reply by Nik Willmore on October 10, 2017 at 11:04pm

Sadly, if I ramp up the size of the mesh balloon to even just three times bigger, I get a final Python script, the one that joins line pairs, error, which occurs immediately when I try to test the script, not after any churning:

Runtime error (IndexOutOfRangeException): index out of range: 0

Traceback:
line 13, in script

Before that step, the curve array forms fine in Grasshopper, all 13K of them. It does churn extremely slowly away if I comment out line 13, and I can have it print the CURVES_CONTAINER size to see it grab two curves at a time out of it:

CURVES_CONTAINER.Add(Rhino.Geometry.Curve.JoinCurves(pair)[0])

Ah, it's the [0] part which I use since Rhinocommon so often spits out a list of outputs instead of just giving me my geometry.

I get the same error with just:

print Rhino.Geometry.Curve.JoinCurves(pair)[0]

Taking off the [0] which grabs the first item says the pair is empty:

Array[Curve](())

Switching back to a smaller balloon mesh, I see the healthy output:

Array[Curve]((<Rhino.Geometry.PolyCurve object at 0x00000000000000E3 [Rhino.Geometry.PolyCurve]>))

...and after adding [0] back, it prints:

<Rhino.Geometry.PolyCurve object at 0x0000000000000253 [Rhino.Geometry.PolyCurve]>

Ah, it's because my little point comparison loop is getting no hits, no matches of points to endpoints. It may just be a tolerance thing on a bigger scale. The endpoints are returning with 14 decimal places.

...yet if I try to test for distance being less than 0.001 instead point equality, same thing happens.

Do I need an RTree?

Permalink Reply by Nik Willmore on October 10, 2017 at 11:56pm

To not be such a perfectionist, I just wrapped the offending line in a try statement and it now works on large bodies, albeit after ~7 minutes, only failing to find a curve pair to join a single time:

Attachments:

Intralattice H Custom Cell.gh, 63 KB

Permalink Reply by Nik Willmore on October 11, 2017 at 1:03am

A twisty unit cell, anybody? Alas, IntraLattice Homogen is now failing for the entire array even though over half of it at a time will work fine, with perfect hubs. I can't isolate anything, it's just larger collections that are poison. So I had to graft the input to IntraLattice, to force it to not make any hubs, just struts.

ZBrush is happy to Boolean this though, where Rhino and Rhino 6 WIP fail.

Here is a raw test script with the arrayed curves (which were converted to polylines to get IntraLattice to work at all) running into IntraLattice.

Attachments:

TEMP A.gh, 78 KB

Permalink Reply by Nik Willmore on October 11, 2017 at 1:33am

In fact ZBrush 4R8P2 can remesh it while adding great smoothing body, akin to a marching cubes result:

That was from the Subtool palette:

Oh, wow, they have vastly improved their old Unified Skin command that couldn't do super-fine resolution, and added smoothing to it. If I turn off Polish, the voxels appear:

Permalink Reply by Nik Willmore on October 11, 2017 at 1:58am

...so what's needed is a ZBrush remote control from Grasshopper. ZBrush has a ZScript language but is a very odd program so that would require lots of kludges if it will work at all. It's also expensive for clients, as an addition to any script I make them.

Though Mesh Pipes works fine for that strategy, seen here, IntraLattice is still twice as fast.

Permalink Reply by Nik Willmore on October 11, 2017 at 3:41pm

Updated script that converts curves in the unit cell to polylines.

Attachments:

Intralattice I Custom Cell.gh, 130 KB

Permalink Reply by Nik Willmore on October 11, 2017 at 4:23pm

The ZBrush strategy, now that ZBrush has a sort of hard core, very fast, marching cubes routine, becomes a new quest for automation, since ZBrush has ZScript and can be launched from the command line (and thus Python) with a selected script as an argument. It uses OBJ files, which are ASCII so I can write them easily with Python. Usually you then have to invoke a button though, but I think an 'if' statement that is always true will also do.

The ZBrush rapid remeshing is a form of Boolean union that Rhino will simply not do, let alone fast. But also, crucially, now that I'm playing with IntraLattice custom unit cells, I realize that some interesting curved wire cells not only won't work for existing IntraLattice, but won't work in principle because they smoothly merge into hubs via fattened strut *overlap*.

ZBrush in few seconds:

You cannot find this performance in open source code out there, code that works, that you can make easy for a client or a coworker to install in a few minutes. This quality of code is in programs and is often a trade secret, let alone possibly patented instead of open source.