a working solution with replacing this line of code with:
Dim charList As New List(Of Char)(charArr)
Is this because of a version incompatibility (I'm using Rhino 4.0, and GH 0.8.0062)? Just curious.
Regards,
JJ…
f the mesh was self-intersecting everywhere. So instead I used Millipede (isosurface) to get the same undulations, but ignore the complex 'folds', you can see the difference in cross section thickness. I then tessellated it with the inverse pattern of the outer surface.
To make it a single 3d printable mesh, i just deleted a single face on inner and outer skin, then lofted the naked edges. (creating a tiny hole through the model). Therefore creating a single mesh that folds in on itself, not sure if there is a better way of defining the space between two meshes as the solid area...
Full GH (Kangaroo - Meshmachine - Weaverbird - Millipede)
Special thanks to Laurent Delrieu for his interesting offset mesh method that i based my approach on.
http://www.grasshopper3d.com/forum/topics/offset-mesh-problems-with-3d-mesh-with-weaverbird…
Added by Nick Tyrer at 5:25am on December 10, 2015
GH) > then define (still in GH) some instance definition (or many: case variants) > then place it according some "policy" (3d point grid and the likes). Note: Only doable with code, mind (C# in my case).
Obviously you can skip the creation part and instruct GH to deal with instance definitions already listed in the Block Manager (say: find the block named "cell666_B3" blah, blah) ... but that means that you can only use them (meaning a rather "limited" parametric approach) and not make them from scratch (meaning a true parametric approach).
But I guess that you've tried the block way in the Rhino environment already. That said I use rather solely this approach in GH and yields quite manageable object collections - I would say "real-time" response (up to 20K instances) but I use dedicated Xeon E5 1630 V3 workstations (with NVida Quadros K4200 and up for the graphic response part of the equation) so the "performance" is rather a subjective thing.
Modifications:
easily doable with GH (on instance definitions at placing time: since you need only to scale them and not vary their topology).
Anyway post a portion of the R file.…
FORE MeshMachine (rather better) or after
BTW: For a mesh with 7M points ... well... you'll need some proper CPU to deal in a reasonable amount of time (what about a Xeon E5 1630 V3?).
Alternatively find a friend who knows very well Modo ... and see first hand what the US Movie Industry is all about.…
hreads where Thread I solves object A1 and Thread II solves object A2. As soon as A1 is completed, Thread I can move on to object B1 and as soon as A2 completes, Thread II can move on to object B3 (whichever comes first). When both A1 and A2 are complete, we can spawn a new thread (III) to take care of object B2.
If B2 completes before B3, then Thread III will terminate. If B3 completes before B2, then Thread II terminates. Whichever thread is last will pick up execution of object C3. And so on and so forth.
This sort of threading is actually not guaranteed to help much though, as it is likely that the bottleneck components in the network will still need to be handled by a single thread.
A more efficient solution would be to divvy up the execution per component to multiple threads. If you're trying to compute the Curve Closest Point for 10,000 points and your machine contains 4 cores, then we can assign 2,500 points to the first core, 2,500 points to the second core etc.
This approach will actually work when there's only a few bottleneck components and it also means the order in which components are solved is no longer important.
An even more fine-grained approach to threading would be to make the Curve Closest Point function in the Rhino SDK threaded. There's a lot of looping going on in any given Curve CP computation so the curve could be broken up into loose spans where each span is solved by a different core. Then the partial results get consolidated once all threads finish.
The benefit here is that it would be multi-core for everyone, not just Grasshopper components.
The bad news: Some functions in Rhino are not thread-safe. Meaning that data structures such as NurbsCurves cannot be modified from multiple threads at once as it will compromise their validity. You might well end up with invalid curves and quite possible weird crashes. In very bad cases it might even be that a specific function in our SDK can only be running once, so even if you were to duplicate the curve it would still not work.
Until our SDK is thread-safe there can be no global threading in Grasshopper. I don't know where we're headed with this, but I do know that we've started using some threaded algorithms in the display as of Rhino5, so it seems we're at least getting our feet wet.
--
David Rutten
david@mcneel.com
Seattle, WA…
Added by David Rutten at 5:47pm on November 17, 2010