My gyroid prints are FDM and in PLA, but I haven't needed internal supports, only support at the base. On Fri, Apr 26, 2019, at 7:22 PM, David Coneff wrote: > Gyroids certainly look like a good shape that could be cut off by any arbitrary boundary. I'm not sure how I would generate one that has an empty internal volume though, plus that would require generating supports within the empty volume since I'm FDM printing and parts of that shape would end up free-floating if printed layer by layer. Hilbert curves by comparison would be pretty easy to print, even if not efficient from a pumping perspective. > > The plan was to use slow convective flow rather than an actively pumped fluid. Drag forces become less of an issue at lower speeds but a gyroid would definitely be more efficient for passive circulation if I could get the model generated. > > On Fri, Apr 26, 2019 at 2:26 PM Doug Moen <doug@moens.org> wrote: >> __ >> The gyroid surface is a good starting point for making heat exchangers. 3D printed gyroids look really cool, plus gyroids are actually used by engineers for heat exchange. >> >> On Fri, Apr 26, 2019, at 1:16 PM, David Coneff wrote: >>> I didn't notice that before, yes it's 2D after all. That's easy enough to modify into 3D with linear extrusion and make an empty pipe with it. I'll see what I can do. >>> >>> As for 3D systems, that would certainly be interesting if there's a way to do hilbert curves that fill a volume. Perhaps it is outside the scope of L-systems, but a really useful feature would be defining a shape that is the boundary for what is to be filled and having the algorithm fill it in right up to the boundary. Most implementations of this type of algorithm work on ant-crawl logic that evaluates the local space for something it would collide against. I don't think OpenSCAD's language supports that sort of algorithm since it doesn't have a true sequential iteration of its for() loop, but simple to implement in python and create an importable path that OpenSCAD could use. >>> >>> In any case, what you've done will suffice. Hilbert curves that fill a square shaped space can be stacked to fill a cubic volume, so as long as that is the shape of the container I'm using for the pipework I could make a hilbert-curve based heat exchanger with my 3D printer. >>> >>> On Thu, Apr 25, 2019 at 8:05 PM Hans L <thehans@gmail.com> wrote: >>>> By the way, I haven't found very much documentation on 3D L-systems, aside from a few brief mentions like this which lays out the operator conventions they use in some proprietary software: https://morphocode.com/3d-branching-structures-with-rabbit/ >>>> >>>> >>>> >>>> On Thu, Apr 25, 2019 at 8:57 PM Hans L <thehans@gmail.com> wrote: >>>>> Hi David, >>>>> >>>>> Actually the only usage of polygon is for the special case of the koch snowflake, and the other curves are created with unions of 2D rectangles (and cricles if rounded=true) inside the modules named "segmented_lines"(lines 302-309) and "line"(343-353). >>>>> Fortunately 2D union is exceptionally fast in OpenSCAD thanks to the clipper library which it uses for those. >>>>> >>>>> There are currently no extrudes and the output is strictly 2D, maybe you are thrown off by OpenSCAD's preview default of displaying 2d objects as having a thickness? This is sort of a limitation of how the preview functionality provided by OpenCSG relies on having polyhedra to display. >>>>> If you render with F6 you will see the CGAL 2D representation which maybe is more familiar. This 2D output can be used to export dxf for example which I view as mostly useful for laser engraving/cutting type applications, or maybe pen plotters (I started toying with the idea of building my own pen plotter a while ago but never quite finished it). >>>>> >>>>> I have thought some about extending this into 3 dimensions but is not currently designed for such a task, and would require a more extensive rewrite. Also to function in a way analogous to how it currently works, it would still still rely on a large union of 3d objects which would be quite heavy for moderate n. >>>>> >>>>> I am aware of only a couple examples of 3D analogues of 2D space filling curves, like the hilbert, or sierpinksi arrowhead. >>>>> I am fascinated by how these are generated and would be interested if there were any sort of algorithm for deriving the 3d rule set based on a 2d ruleset. For example What would a 3d dragon curve look like? Really interesting to think about, but I have no idea if all such curves necessarily imply that 3d versions even exist. The rulesets for rotations become more complex as you have to account for negative and positive rotations along 3 axes relative to the current direction vector (+/- pitch, roll, yaw). >>>>> >>>>> A long time ago i wrote a sort of 3d hilbert curve "screensaver" type visualization using opengl which i had a lot of fun with, where the successive iterations "grew" out of the existing segments over time. Unfortunately I have lost that code to time and old obsolete hard drives. >>>>> >>>>> Cheers, >>>>> Hans Loeblich >>>>> >>>>> >>>>> >>>>> On Thu, Apr 25, 2019 at 2:58 PM David Coneff <david.coneff@gmail.com> wrote: >>>>>> That L-systems script is really well done! Very organized and easy to read. I haven't played with the grammar of L-systems, but uncommenting the examples showed me it executes very quickly for a reasonable size system. A cursory search for "extrude", "cylinder" and "cube" which don't show up tell me that you must be constructing these shapes by calculating all the points of a path and sweeping a polygon along that path, or something similar. >>>>>> >>>>>> My main use for space-filling curves would be to make pipe networks that fill a 3D volume, or alternatively cover a defined area of a flat surface which could then be stacked to fill a volume with the same cross-sectional area with regular inlets/outlets in predictable locations. I don't see an easy way to modify this code to construct a Hilbert or Peano curve with an empty hole through the middle of the path. If you could help point me to what section of the script does that work I'd be grateful. Otherwise this code looks great - doesn't rely on computationally expensive operations like difference() and union() of 3D primitives to make a fractal which is how I see these things implemented a lot of the time. >>>>>> >>>>>> >>>>>> >>>>>> On Sat, Mar 23, 2019 at 12:42 AM Hans L <thehans@gmail.com> wrote: >>>>>>> Hello again >>>>>>> >>>>>>> Its been a while, but I have recently revisited and completely re-worked my L-system script to be more efficient and support more advanced features. >>>>>>> There are now commands to "M"ove without drawing, and "[" save and restore "]" position on a stack. >>>>>>> There are a number of new examples including penrose tiling, fractal plants etc which use these new features. >>>>>>> >>>>>>> The main interface for specifying rules, and which characters draw and move has been simplified as well: >>>>>>> https://gist.github.com/thehans/a1494db8046a58832e2ebb10a5908a66 >>>>>>> >>>>>>> Let me know what you think. I'd also love to hear any suggestions for other interesting L-systems that could be added to the samples. I've implemented most of the common ones I've found around the web so far. >>>>>>> >>>>>>> Hans >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sat, Feb 24, 2018 at 2:26 PM Dan Shriver <tabbydan@gmail.com> wrote: >>>>>>>> Not sure if people are interested. I wrote a rather simple fractal generating tool. I know I had it working with spheres and cubes, maybe or maybe not with dodecahedrons. >>>>>>>> >>>>>>>> Ideally I'd like it to work with all platonic solids as well as other solids (it would be great if it did all the solids on "the wallace line" but as many on this forum know math is not my strong suit) >>>>>>>> >>>>>>>> It takes a solid and then makes N smaller solids around the main one and so on. The program can change N on the different generations (making it grow or shrink). >>>>>>>> >>>>>>>> I only had it correct for spheres and cubes because I could easily figure out how to make subsidiary volumes at a given distance from the center. >>>>>>>> >>>>>>>> If you want I can "release" this code for general use. >>>>>>>> >>>>>>>> On Sat, Feb 24, 2018 at 3:12 PM, Hans L <thehans@gmail.com> wrote: >>>>>>>>> Greetings Fractal Fans, >>>>>>>>> >>>>>>>>> The recursion issue I stumbled upon earlier in this thread spurred me >>>>>>>>> to go down a rabbit hole of profiling and optimization. And I'm happy >>>>>>>>> to announce that there have been substantial improvements to memory >>>>>>>>> consumption(specifically for deep nestiing / recursive scripts) in >>>>>>>>> addition to some string processing speedups for OpenSCAD. >>>>>>>>> >>>>>>>>> The latest OpenSCAD dev nightlies should include these changes. In >>>>>>>>> testing out the L_system script, I've been able to bump iteration >>>>>>>>> levels a couple more while using less RAM than before. >>>>>>>>> >>>>>>>>> I think there are still more potential performance enhancements that >>>>>>>>> could be made for OpenSCAD, particularly around improving CGAL cache >>>>>>>>> hit rate(which I think would matter a lot for more general modeling >>>>>>>>> use-cases than fractals). And I sort of only really addressed one >>>>>>>>> half of the string processing issue(the performance difference of >>>>>>>>> which is more noticeable using tree=false in L_systems.scad, if >>>>>>>>> comparing OpenSCAD versions). >>>>>>>>> >>>>>>>>> I also updated the script a bit, added an option for whether or not to >>>>>>>>> round the corners with circles, and added a new "Terdragon" curve >>>>>>>>> https://en.wikipedia.org/wiki/Dragon_curve#Terdragon >>>>>>>>> https://gist.github.com/thehans/a1494db8046a58832e2ebb10a5908a66 >>>>>>>>> >>>>>>>>> I've found this script to be an interesting benchmark, and very >>>>>>>>> revealing in profiling the OpenSCAD code. In case anyone is >>>>>>>>> wondering, I used perf tools on linux to take samples of an OpenSCAD >>>>>>>>> debug build during render. And used flamegraphs (eg. >>>>>>>>> http://www.brendangregg.com/flamegraphs.html and >>>>>>>>> https://github.com/brendangregg/FlameGraph ) to visualize the output. >>>>>>>>> Specifically I used this frontend https://github.com/KDAB/hotspot to >>>>>>>>> generate the flamegraphs. The interface makes it a little more >>>>>>>>> convenient to attach to processes in the GUI, but I found it can also >>>>>>>>> be a bit slow to load when viewing the results of a recording . >>>>>>>>> Flamegraphs are are really nice way to visualize where CPU spending >>>>>>>>> its time(among other things, but I haven't really gotten into much >>>>>>>>> more than basic use cases). >>>>>>>>> >>>>>>>>> -Hans >>>>>>>>> >>>>>>>>> On Sat, Feb 17, 2018 at 7:12 AM, doug moen <doug@moens.org> wrote: >>>>>>>>> > David Coneff said: "a klein bottle ... is easily defined as an f-rep ... I >>>>>>>>> > imagine curv would be able to do it nearly instantly if I plugged in the >>>>>>>>> > right equation" >>>>>>>>> > >>>>>>>>> > Unfortunately, you can't plug an arbitrary distance function into an F-Rep >>>>>>>>> > system and expect it to work. Different F-Rep systems place different >>>>>>>>> > restrictions on the structure of a distance field in order to make rendering >>>>>>>>> > possible. Curv and Libfive have different restrictions, which makes them >>>>>>>>> > good for different classes of distance functions. >>>>>>>>> > >>>>>>>>> > Curv is good for deep zooms into fractals, but not good for algebraic >>>>>>>>> > surfaces like the Klein bottle immersion into R^3. >>>>>>>>> > >>>>>>>>> > Libfive is good for algebraic surfaces (the klein bottle "just works"), but >>>>>>>>> > bad for fractals (the Menger sponge demo in libfive fails to render for >>>>>>>>> > order 4 and greater). >>>>>>>>> > >>>>>>>>> > In either system, it's possible to modify a bad distance field to make it >>>>>>>>> > renderable, but this has multiple levels of difficulty. I managed to get >>>>>>>>> > Menger 4 and 5 to work in Libfive (it gets exponentially slower as the order >>>>>>>>> > increases). So far, I only have an approximate solution to the Klein bottle >>>>>>>>> > in Curv. >>>>>>>>> > >>>>>>>>> > In the case of libfive, the menger sponge demo uses high level CSG >>>>>>>>> > operations, but still fails to render. In Curv, with the Klein bottle >>>>>>>>> > example, you are defining a new distance field from scratch using math, >>>>>>>>> > which intrinsically requires a higher level of skill than just plugging CSG >>>>>>>>> > operations together. A well designed F-Rep system will provide a set of >>>>>>>>> > basic CSG operations and primitives that are guaranteed to produce good >>>>>>>>> > distance functions: this is something that is available in Curv, but not >>>>>>>>> > possible in Libfive. >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > On 16 February 2018 at 16:07, David Coneff <david.coneff@gmail.com> wrote: >>>>>>>>> >> >>>>>>>>> >> Curv looks quite interesting >>>>>>>>> >> https://github.com/doug-moen/curv >>>>>>>>> >> >>>>>>>>> >> From the history/rationale section, looks like you have tried to fill a >>>>>>>>> >> gap I was feeling very sorely last year when I got started on the 3D >>>>>>>>> >> modelling/printing. The first model I wanted to re-create was a klein bottle >>>>>>>>> >> that I found on thingiverse, however it's non-trivial to make a wire-frame >>>>>>>>> >> of one, and the shape is easily defined as an f-rep but not easily >>>>>>>>> >> translated into even a continuous-surface model from OpenSCAD primitives. I >>>>>>>>> >> ended up giving up and trying some other stuff. I imagine curv would be able >>>>>>>>> >> to do it nearly instantly if I plugged in the right equation - really glad >>>>>>>>> >> you focused on GPU rendering vs. multi-threaded CPU. It's been my feeling >>>>>>>>> >> that this type of code is what we really need to be using for scientific >>>>>>>>> >> visualization as well since the inherent resolution of any data is preserved >>>>>>>>> >> rather than obscured by rasterization processes - being able to deep-zoom is >>>>>>>>> >> a big deal. Guess I'll be getting Ubuntu going soon so I can try this out >>>>>>>>> >> rather than prioritizing Keeter's stuff. From the sound of it, would be much >>>>>>>>> >> more of a pain in the ass to get his installed if it's requiring the latest >>>>>>>>> >> ubuntu releases and unusual library packages. I'm not enough of a >>>>>>>>> >> linux/low-level programmer guy to navigate all the errors that happen trying >>>>>>>>> >> to get that stuff working. Hopefully your build instructions work for me! >>>>>>>>> >> Looks short and sweet. >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> On Fri, Feb 16, 2018 at 1:21 PM, doug moen <doug@moens.org> wrote: >>>>>>>>> >>> >>>>>>>>> >>> Hans: Thanks, that's nice code. >>>>>>>>> >>> >>>>>>>>> >>> NateTG: Yes, it was the example that I tried, a few years back. >>>>>>>>> >>> >>>>>>>>> >>> On 16 February 2018 at 14:48, NateTG <nate-openscadforum@pedantic.org> >>>>>>>>> >>> wrote: >>>>>>>>> >>>> >>>>>>>>> >>>> > In OpenSCAD, I didn't succeed in rendering a sponge greater than N=3, >>>>>>>>> >>>> > due >>>>>>>>> >>>> to slowness of CSG operations. An order 4 sponge has 160,000 subcubes, >>>>>>>>> >>>> which >>>>>>>>> >>>> is a lot of triangles. >>>>>>>>> >>>> >>>>>>>>> >>>> Did you try the old example? >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> https://github.com/openscad/openscad/blob/4a0ac7b2fa6e8ca390e3b95e1c2d2541cf9d77af/examples/Old/example024.scad >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> -- >>>>>>>>> >>>> Sent from: http://forum.openscad.org/ >>>>>>>>> >>>> >>>>>>>>> >>>> _______________________________________________ >>>>>>>>> >>>> OpenSCAD mailing list >>>>>>>>> >>>> Discuss@lists.openscad.org >>>>>>>>> >>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> >>> _______________________________________________ >>>>>>>>> >>> OpenSCAD mailing list >>>>>>>>> >>> Discuss@lists.openscad.org >>>>>>>>> >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>>>>>> >>> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> _______________________________________________ >>>>>>>>> >> OpenSCAD mailing list >>>>>>>>> >> Discuss@lists.openscad.org >>>>>>>>> >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>>>>>> >> >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > _______________________________________________ >>>>>>>>> > OpenSCAD mailing list >>>>>>>>> > Discuss@lists.openscad.org >>>>>>>>> > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>>>>>> > >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> OpenSCAD mailing list >>>>>>>>> Discuss@lists.openscad.org >>>>>>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OpenSCAD mailing list >>>>>>>> Discuss@lists.openscad.org >>>>>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>>>> _______________________________________________ >>>>>>> OpenSCAD mailing list >>>>>>> Discuss@lists.openscad.org >>>>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>>> _______________________________________________ >>>>>> OpenSCAD mailing list >>>>>> Discuss@lists.openscad.org >>>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>> _______________________________________________ >>>> OpenSCAD mailing list >>>> Discuss@lists.openscad.org >>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >