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

Hans L thehans at gmail.com
Wed Nov 20 17:43:01 EST 2019


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

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


More information about the Discuss mailing list