algorithmic modeling for Rhino

Hi there,

I'm creating a honeycomb infill which will be used to generate some G-code for my Ultimaker 2 using Silkworm. Each poly-lines is interpreted as a single printing movement with a lift motion in between each of them.

Therefore I need the least amount of Poly-lines from my 375 lines. I've tried joining them which results in 159 poly-lines and the Pline component doesn't take my boundary into consideration.

Could someone point me in the right direction?

Thanks in advance!



Join Component:


Views: 1491

Replies to This Discussion

For instance this (WIP) stupid thingy does polylines using random pts (use the chaos maker C# if you want proof) based on proximity AND some "meaningful zones" (whatever this means).

It's rather fast since it uses this collection for searching proximity:

Rhino.Collections.Point3dList points = new Rhino.Collections.Point3dList(pList);

instead of:

pList = pList.OrderBy(x => x.DistanceTo(SomeRefPt)).ToList();

In order to work specifically with hex pts ... adjustments in the code are required.


For CNC you could just cut some segments twice to avoid many slow retractions and plunges, but for 3D printing I think the best strategy is a change of geometry away from hexagons.

That said, RhinoCAM is not much better at this, here being minimum distance sorting of your original short segments or with everything completely exploded:

If you want hexagons for some other strategic reason, here I have filtered out the verticals, joined the near horizontals into long lines, so then you at least have a rational approach of laying down long linear sawtooths then little bridges between them with short linear movement between isolated bridges:

However, RhinoCAM with directional sort to create those linear rapids between bridges, is not exactly happier!

Can a 3D printer just ignore the already laid down long runs and then push right through them on a second pass to do the bridges, simply not feeding filament between bridges, but not actually lifting up slowly and back down?

Here's another strategy actually, to LEAVE OUT the bridges completely and make it up by then alternating zig lag line direction between height passes!

That gives:

There is still considerable overlap since the zig-zag lines re-use some of the same segments for different overall angles, but it sounds like they are just raising the print nozzle higher for each pass and it works out anyway and isn't really redundant but in fact bridges are missing in each layer but still work out since they appear in the very next layer again?







  • Add Photos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service