[OpenSCAD] "Lazy union" is now experimental in snapshots

Revar Desmera revarbat at gmail.com
Wed Nov 20 19:15:41 EST 2019

I have a request...  Please require something in the language to turn on lazy unions, so that I can use both files that use it, and older files that require the old behavior without having to change the preferences setting each time.

Maybe something at root level like:


- Revar


> On Nov 20, 2019, at 2:43 PM, Hans L <thehans at gmail.com> wrote:
> The code for this was recently merged and should be available in the latest nightly snapshots.  As with other experimental features, it must be enabled in your preferences to make use of it.
> The feature removes "implicit union" from the following builtin modules:
>   - for 
>   - children
>   - let
>   - if, if/else
>   - echo
>   - assert
>   - (root aka top-level, and root modifier: '!' )
> So children of these module types will basically be interpreted as a list of geometries(aka list nodes) that are applied to the next parent up, instead of grouping and performing union every time.
> This has potential to vastly speed up rendering of some types of models.
> Marius began work on this years ago, and I've recently updated his branch and added + fixed a few things to prepare it for merging.  So big thanks to Marius for doing the brunt of the work so far!
> The plan is to eventually support many other modules including: 
>   - (user-defined modules)
>   - (the various builtin transformations)
>   - color
>   - render
>   - projection
>   - (*maybe* offset, linear_extrude, and rotate_extrude) 
> Those last 3 operate on groups of 2D geometries for which union is already fast. so those currently have lowest priority unless someone has a case for needing them.
> It was decided that rather than waiting for the changes to be implemented on every possible module type, we should do this incrementally so that some progress can be made and this long-awaited feature can begin getting tested by adventurous users.
> For anyone wanting to test it out:  
> Be aware that there are some situations where these change will affect output geometry.
> In the following "for" is used as an example, but the same applies to any of the currently implemented modules:
> difference() { for(...) ... }
>     This will result in the object from the first iteration being subtracted by all subsequent iterations.  
>     (Only relevant when a list node is the *first* term in the difference operation)
> intersection() { for(...) ... }
>     This will act the same as "intersection_for" which will eventually be deprecated.  
>     (Unlike difference, this applies to list nodes as terms in *any* position)
> minkowski() { for(...) ... }
>     This will perform minkowski sum such that  each iteration counts as a single term in the operation.
> Additionally, when exporting multiple modules which are called directly from the top-level (or where all parents of a module up to the top-level are list nodes), these will result in distinct non-unioned geometries added to the exported file.  If such objects actually intersect, this may produce invalid output, and may be dependent on the consuming program(slicer etc) for whether this actually works or not.
> On the other hand, intersecting geometries may actually be desirable for some cases such as 2D DXF export to be used in laser engraving tool paths, where lines happen to cross.
> It is currently up to the user to decide when union is actually necessary.  if you want to play it safe you can always wrap your top level in one big union to behave same as before.
> There should be no change to behavior unless the "lazy-union" feature is enabled in preferences.  If you find any unexpected behavior as a result of the recent changes, please report it.
> The original issue and discussion of these changes is tracked here: https://github.com/openscad/openscad/issues/350 <https://github.com/openscad/openscad/issues/350>
> - Hans Loeblich
> _______________________________________________
> OpenSCAD mailing list
> Discuss at lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20191120/44994b16/attachment.html>

More information about the Discuss mailing list