Grasshopper

algorithmic modeling for Rhino

The attached Gyroid picture is made up of 1518 closed meshes. Produced by the  attached script. If I were to print this Gyroid ?

1. What's missing to make a 3d printed object? (besides a 3d printer)  :)

2. Do I have to clean up the 1518 closed meshes and make them 1 mesh ?

3. What to do about thickness ? etc.

Views: 15559

Attachments:

Replies to This Discussion

Exoskeleton/Exowire should work ideally for this but there's simply a very strange bug for certain angles that you can fix manually by changing the offending two wires so it works, but it's not only about angle since the exact same wires can suddenly start working fine later! Just adding new items to Rhino and then using undo to get back to your failing geometry will fix it sometimes?! Flipping the pair of curves' directions, either one or both, fixes it. It's just black box broken. It happens for really boring angles near 90 degrees.

Rotating the entire pair in space has no effect.

Rescaling the lines from their joint point has no effect.

Simply cutting and pasting the lines out of Rhino back in *sometimes* fixes it, so it's angle and something else that makes certain lines "toxic."

Duplicating the pair of failed lines via alt-dragging the Rhino gumball fails to fix it.

Running the "line-like curves" through a Line component to give "lines" doesn't fix it.

Re-creating the lines by extracting endpoints fails to fix it.

Each line, if separated from each other works fine.

Grafting makes each line into its own little cylinder minus a hub.

The error is the boilerplate "Object reference not set to an instance of an object."

 

Once the pair spontaneously starts working I cannot reproduce the error with that pair again, though sometimes Rhino undo will get me back to failing.

CAN ANYBODY REPRODUCE THIS WITH MY FILE? If so I can submit a bug report.

Exoskeleton is here: http://www.grasshopper3d.com/group/exoskeleton

Source code is here but it's for compiling, not something I can just test in a C# component out of the box:

https://github.com/davestasiuk/Exoskeleton2/commit/f63c4aa691a7f26b...

Attachments:

These 1518 closed meshes which make up this Gyroid geometry, reminds me of the ParaCloud Gem 3 pattern Modeler I used a few years ago. It had the same problem, it did not make a unified mesh. Hence it re-meshed each of the 1518 meshes individually. After some discussion about this topic at the SketchUp forum someone came up with a Ruby script that concentrated on eliminating the internal structural geometry that was not related to the exterior skin. This then produced a single unified mesh, which could now be re-meshed.

I'm not a programmer. Is it not possible that such an code could not be written for GH?

Intralattice (http://www.grasshopper3d.com/group/intralattice) uses the same concept as Exoskeleton to solidify wireframes, with a few critical differences, as well as being capable of solidifying curve networks.

It generates the solid mesh in about 6 seconds, but there is one problem area in the line array posted by Nik Willmore, where the lines are too close together and the mesh ends up overlapping (see below). This results in a few naked edges. I saw one post by Nik that relaxes the initial gyroid mesh using MeshMachine, this version of the line network would likely not result in an overlap.

The full mesh is shown below.

Note that both Intralattice and Exoskeleton rely heavily on Rhino tolerances to build up the mesh. The line array posted is very small, and this might have something to do with the failures Nik is talking about. For the case above (using Intralattice), I simply scaled up the model and solidified it, you can then scale it back down once mesh computation is complete. Find the .gh file attached.

Attachments:

Yes, because of some units mistranslation the model originally posted was huge, and millions of units away from the origin when I opened it so indeed I scaled it down orders of magnitude just to be able to use my Space Navigator mouse without it flying off the screen.

However, scaling up my posted example pair by 10X or 100X along with the Exowire radius setting does not affect it. Changing Rhino tolerance 1/10th, 1/100th or 10X, 100X also has no effect. Nor does changing units from meters to milimeters with rescaling confirmed.

I'd port open source Exowire to Python if I had time. The theory is here, showing how the wires are simple and the hubs are convex hulls:

http://www.viz.tamu.edu/faculty/ergun/research/topology/papers/brid...

Intralattice indeed works and relies on the Rhino tolerance setting being low enough. I forgot to put it back to a small number just now and Intralattice failed.

Intralattice uses two or often *four* anti-prisms to link hubs, so that's lots of triangles for a 3D print, but the uniformity will make remeshing easy too. A simpler system would merely diagonally triangulate a simple twisted regular prism, like this:

This helps confirm that Exowire has a real bug since, boom, Intralattice to the rescue with the same input geometry and tolerance setting.

The bunching together should be mostly avoided by indeed remeshing the source mesh with MeshMachine to avoid short segments.

Still, Intralattice makes the convex hull hubs too big, bigger than required. The red highlighted hub is way too stretched out tall for this geometry:

Yeah, this is mostly a robustness thing. Before computing the convex hulls, the algorithm figures out suitable node offsets along each strut. To work on curve networks, my approach makes this offset slightly greater than would be required by simple line networks. This offset computation is one of the major differences between Exoskeleton and Intralattice.

I could add an 'offset factor' input, because the issue you mention can get pretty ugly for more complex line networks (i.e. result in really fat nodes), but I also wanted to keep the inputs to a minimum; so that users don't have too many inputs to worry about.

I'd even like to minimize hubs to extremely minimal shortest edge member.

Given that this artifact dominates the result, you could also consider just testing the input for simple lines and black box tweaking it internally, but I certainly appreciate full control. Perhaps only add extra inputs to the more advanced components. I'd like simple prisms too, as an option, or even quad mesh faces for prism struts instead so I have an option to manually triangulate later. I don't like how I can't control two vs. four anti-prisms either. I seem to recall seeing both appear in the result. And changing from triangles all the way up to twelve sided polygons for the convex hub faces is another power user option I'd enjoy.

Nice plug-in to get up to speed on. I wonder if you could include the actual intersection points in the convex hull, so avoid undershoot like this?:

Upon subdividing I do get a more desirable outcome, if I build the convex hub manually to include that point and union it with the old mesh:

Hi Nik,

Thanks for all the feedback! I'll be working on this in a month or so, I'll try to integrate all your requests. I definitely like the idea of including extra inputs/outputs in the more advanced components for users like yourself to play around with.

For the undershoot issue, this is actually unusual. Within the algorithm there is a method that checks for these kinds of "sharp" nodes and adjusts the hull accordingly. Could you possibly send me the curve network you used in the example - I'll debug it and release a hotfix ASAP.

Thanks!

Didn't save it.

Hi Kim, would you tell me names of used plugins? I'm trying to open the file but my components are not enough! i have just some of them like weaverbird, kangaroo, T-splines. thanks!

you need Millipede, then look for Iso Surface comp.

RSS

About

Translate

Search

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service