Passing function literals to builtin modules.
What built in module would you like to see extended to accept function
literals as parameter?
--
Sent from: http://forum.openscad.org/
Data generation for surface() and a comparator for search().
-Revar
On Jan 1, 2021, at 9:13 AM, TLC123 torleif.ceder@gmail.com wrote:
What built in module would you like to see extended to accept function
literals as parameter?
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
yes search for all non matching pattern would be very useful.
--
Sent from: http://forum.openscad.org/
On 07.01.21 20:37, TLC123 wrote:
yes search for all non matching pattern would be very useful.
Yep, search seems a good candidate, however I would not
extend the existing search as it's an abomination with
regard to usage.
ciao,
Torsten.
Dare a i say Multmatrix (with fourth row unlocked), a powder-keg that could
do some real damage.
--
Sent from: http://forum.openscad.org/
I'm thinking that a very general transform module which takes a function
literal to modify points/faces could be the solution to a lot of
problems/limitations including perspective projection, as TLC123 alludes to.
Module(s) could be defined as:
transform3d(f) { ... }
transform2d(f) { ... }
The transform module would perform an implicit render() of its child
modules, then apply function f once on the results.
The function passed in would take geometry data in the same form as
polyhedron/polygon and return a pair of modified [ points, faces | paths ]
which the module would use to replace the geometry.
So, as a trivial example of function signature, the identity functions for
these modules would be:
f=function(points, faces) [points, faces];
f=function(points, paths) [points, paths];
On Fri, Jan 8, 2021 at 9:44 AM TLC123 torleif.ceder@gmail.com wrote:
Dare a i say Multmatrix (with fourth row unlocked), a powder-keg that could
do some real damage.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
So this would give user functions access to the geometry? This would be
great.
thehans wrote
I'm thinking that a very general transform module which takes a function
literal to modify points/faces could be the solution to a lot of
problems/limitations including perspective projection, as TLC123 alludes
to.
Module(s) could be defined as:
transform3d(f) { ... }
transform2d(f) { ... }
The transform module would perform an implicit render() of its child
modules, then apply function f once on the results.
The function passed in would take geometry data in the same form as
polyhedron/polygon and return a pair of modified [ points, faces | paths ]
which the module would use to replace the geometry.
So, as a trivial example of function signature, the identity functions for
these modules would be:
f=function(points, faces) [points, faces];
f=function(points, paths) [points, paths];
On Fri, Jan 8, 2021 at 9:44 AM TLC123 <
torleif.ceder@
> wrote:
Dare a i say Multmatrix (with fourth row unlocked), a powder-keg that
could
do some real damage.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@.openscad
Discuss@.openscad
--
Sent from: http://forum.openscad.org/
and effectively break the fast preview, slower full render model that
underpins OpenSCAD. But it's already cracked with Minkowski et al...
-----Original Message-----
From: Discuss [mailto:discuss-bounces@lists.openscad.org] On Behalf Of adrianv
Sent: Sat, 9 Jan 2021 08:47
To: discuss@lists.openscad.org
Subject: Re: [OpenSCAD] Passing function literals to builtin modules.
So this would give user functions access to the geometry? This would be
great.
thehans wrote
I'm thinking that a very general transform module which takes a function
literal to modify points/faces could be the solution to a lot of
problems/limitations including perspective projection, as TLC123 alludes
to.
Module(s) could be defined as:
transform3d(f) { ... }
transform2d(f) { ... }
The transform module would perform an implicit render() of its child
modules, then apply function f once on the results.
The function passed in would take geometry data in the same form as
polyhedron/polygon and return a pair of modified [ points, faces | paths ]
which the module would use to replace the geometry.
So, as a trivial example of function signature, the identity functions for
these modules would be:
f=function(points, faces) [points, faces];
f=function(points, paths) [points, paths];
On Fri, Jan 8, 2021 at 9:44 AM TLC123 <
torleif.ceder@
> wrote:
Dare a i say Multmatrix (with fourth row unlocked), a powder-keg that
could
do some real damage.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@.openscad
Discuss@.openscad
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
--
This email has been checked for viruses by AVG.
https://www.avg.com
I think taking some hit to preview performance would be a price many would
gladly pay for access to geometry data. And it's not that render() itself
is inherently slow, it just depends how many CGAL Nef Polyhedron operations
it contains (3D boolean ops for the most part), and the complexity of the
models involved. In cases where the child geometry is something like a
linear_extrude or rotate_extrude for example, then CGAL wouldn't need to be
involved at all.
I guess another possible option could be to perform the transform function
on all child nodes individually, and not force a render...
Though I'm not sure if that's quite as useful, or even feasible to
implement without introducing a whole new set of tricky edge cases and
unforeseen complications.
Hans
On Fri, Jan 8, 2021 at 3:59 PM Michael Marx michael@marx.id.au wrote:
and effectively break the fast preview, slower full render model that
underpins OpenSCAD. But it's already cracked with Minkowski et al...
-----Original Message-----
From: Discuss [mailto:discuss-bounces@lists.openscad.org] On Behalf Of
adrianv
Sent: Sat, 9 Jan 2021 08:47
To: discuss@lists.openscad.org
Subject: Re: [OpenSCAD] Passing function literals to builtin modules.
So this would give user functions access to the geometry? This would be
great.
thehans wrote
I'm thinking that a very general transform module which takes a
function
literal to modify points/faces could be the solution to a lot of
problems/limitations including perspective projection, as TLC123
alludes
to.
Module(s) could be defined as:
transform3d(f) { ... }
transform2d(f) { ... }
The transform module would perform an implicit render() of its child
modules, then apply function f once on the results.
The function passed in would take geometry data in the same form as
polyhedron/polygon and return a pair of modified [ points, faces |
paths ]
which the module would use to replace the geometry.
So, as a trivial example of function signature, the identity functions
for
these modules would be:
f=function(points, faces) [points, faces];
f=function(points, paths) [points, paths];
On Fri, Jan 8, 2021 at 9:44 AM TLC123 <
torleif.ceder@
> wrote:
Dare a i say Multmatrix (with fourth row unlocked), a powder-keg that
could
do some real damage.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@.openscad
Discuss@.openscad
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
--
This email has been checked for viruses by AVG.
https://www.avg.com
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
[ pass geometry to arbitrary function ]
Does render() run at the right time to be helpful?
I don't know beans about the actual implementation, but my mental model
and experimentation says that the "execution" of the program is a
distinct step earlier than any rendering. The render() module doesn't
cause its children to be rendered right then and there. Rather, it's a
node in the CSG tree that causes its children to be rendered using CGAL
rather than using CSG, even when doing a preview.
Here's a test program. It takes about 10 seconds on my (older and low
end) desktop, so long enough to be clear and short enough not to be
annoying. All of the echo output comes out instantly, before any of the
rendering starts. (Unsurprisingly, with the render()s, it's about the
same amount of time for F5 or F6.)
module teardrop(k) {
junk = echo("1", k);
echo("2", k);
for (i=[1:0.5:5]) translate([i,0,0]*k) sphere(i);
junk2 = echo("3", k);
echo("4", k);
}
render() teardrop(3);
render() translate([0,20,0]) teardrop(4);
It also makes an interesting shape. That's just a happy accident; I
wanted something simple that would multiply up into easily visible
render times.
It seems like the proposed transform module would have to move the CGAL
step much earlier in the processing pipeline.