discuss@lists.openscad.org

OpenSCAD general discussion Mailing-list

View all threads

Inheriting (grand)children?

R
RayBellis
Sun, Dec 31, 2017 12:14 AM

I've devised the attached file which can be used to recursively put
sub-dividers within a unit cube, in my case I use it with a stackable box
I'm working on, with typical usage:

StackableBox(width = 60, depth = 60, height = 15)
subdivide(a = 0, s = [1, 2, 1]) {
subdivide(a = 1, n = 2);
subdivide(a = 1, s = [1, 3, 1]);
}

This actually works fine - it first divides the box in three (with ratios
1:2:1) in the X axis, and then the first division is split in 2 on the Y
axis, the second division gets split with ratio 1:3:1, and since the third
division is missing it repeats the first division again:

http://forum.openscad.org/file/t2120/StackableBox-working.png

What's bugging me is that I wanted to provide utility functions like this:

module subdivideX(n = 2, s = undef) {
subdivide(a = 0, n = n, s = s) children();
}

but if I replace the first subdivide(a = 0, ...) call above with a call to
subdivideX the two sub-children don't work.  It's as if the children()
aren't being passed correctly up the chain.

http://forum.openscad.org/file/t2120/StackableBox-broken.png

I don't get what it is about the children() module that means my little
utility wrapper functions don't work.

subdivide.scad http://forum.openscad.org/file/t2120/subdivide.scad

--
Sent from: http://forum.openscad.org/

I've devised the attached file which can be used to recursively put sub-dividers within a unit cube, in my case I use it with a stackable box I'm working on, with typical usage: StackableBox(width = 60, depth = 60, height = 15) subdivide(a = 0, s = [1, 2, 1]) { subdivide(a = 1, n = 2); subdivide(a = 1, s = [1, 3, 1]); } This actually works fine - it first divides the box in three (with ratios 1:2:1) in the X axis, and then the first division is split in 2 on the Y axis, the second division gets split with ratio 1:3:1, and since the third division is missing it repeats the first division again: <http://forum.openscad.org/file/t2120/StackableBox-working.png> What's bugging me is that I wanted to provide utility functions like this: module subdivideX(n = 2, s = undef) { subdivide(a = 0, n = n, s = s) children(); } but if I replace the first subdivide(a = 0, ...) call above with a call to subdivideX the two sub-children don't work. It's as if the children() aren't being passed correctly up the chain. <http://forum.openscad.org/file/t2120/StackableBox-broken.png> I don't get what it is about the children() module that means my little utility wrapper functions don't work. subdivide.scad <http://forum.openscad.org/file/t2120/subdivide.scad> -- Sent from: http://forum.openscad.org/
M
MichaelAtOz
Sun, Dec 31, 2017 2:35 AM

What you have is the implicit union problem.
Modules (and the main program level) perform a union of all the objects
rather than passing sets of objects.
There has been much discussion and nashing of teeth about it.
There, I believe, is consensus to move to a non-implicit union, but it will
break backwards compatibility, so is being planned along with other major
changes into something like OpenSCAD MkII. So don't hold your breath.


Admin - PM me if you need anything, or if I've done something stupid...

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.

The TPP is no simple “trade agreement.”  Fight it! http://www.ourfairdeal.org/  time is running out!

Sent from: http://forum.openscad.org/

What you have is the implicit union problem. Modules (and the main program level) perform a union of all the objects rather than passing sets of objects. There has been much discussion and nashing of teeth about it. There, I believe, is consensus to move to a non-implicit union, but it will break backwards compatibility, so is being planned along with other major changes into something like OpenSCAD MkII. So don't hold your breath. ----- Admin - PM me if you need anything, or if I've done something stupid... Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above. The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out! -- Sent from: http://forum.openscad.org/
M
MichaelAtOz
Sun, Dec 31, 2017 10:46 PM

p.s. Some reading  GitHub issue
https://github.com/openscad/openscad/issues/350  .


Admin - PM me if you need anything, or if I've done something stupid...

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.

The TPP is no simple “trade agreement.”  Fight it! http://www.ourfairdeal.org/  time is running out!

Sent from: http://forum.openscad.org/

p.s. Some reading GitHub issue <https://github.com/openscad/openscad/issues/350> . ----- Admin - PM me if you need anything, or if I've done something stupid... Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above. The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out! -- Sent from: http://forum.openscad.org/
NH
nop head
Mon, Jan 1, 2018 2:02 AM

I think there are two separate issues: implicit / lazy union evaluation is
a performance thing. The fact that for and modules produce a single group
node instead of an array of children is a different thing entirely.

On 31 December 2017 at 22:46, MichaelAtOz oz.at.michael@gmail.com wrote:

p.s. Some reading  GitHub issue
https://github.com/openscad/openscad/issues/350  .


Admin - PM me if you need anything, or if I've done something stupid...

Unless specifically shown otherwise above, my contribution is in the
Public Domain; to the extent possible under law, I have waived all
copyright and related or neighbouring rights to this work. Obviously
inclusion of works of previous authors is not included in the above.

The TPP is no simple “trade agreement.”  Fight it!
http://www.ourfairdeal.org/  time is running out!

Sent from: http://forum.openscad.org/


OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

I think there are two separate issues: implicit / lazy union evaluation is a performance thing. The fact that for and modules produce a single group node instead of an array of children is a different thing entirely. On 31 December 2017 at 22:46, MichaelAtOz <oz.at.michael@gmail.com> wrote: > p.s. Some reading GitHub issue > <https://github.com/openscad/openscad/issues/350> . > > > > > > ----- > Admin - PM me if you need anything, or if I've done something stupid... > > Unless specifically shown otherwise above, my contribution is in the > Public Domain; to the extent possible under law, I have waived all > copyright and related or neighbouring rights to this work. Obviously > inclusion of works of previous authors is not included in the above. > > The TPP is no simple “trade agreement.” Fight it! > http://www.ourfairdeal.org/ time is running out! > -- > Sent from: http://forum.openscad.org/ > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >