DC
David Coneff
Sat, Mar 25, 2017 8:00 PM
Doug,
What you're referring to is B-REP (boundary representation), and OpenSCAD
would need to be rebuilt from the ground up to do that unfortunately.
ImplicitCAD, Antimony http://www.mattkeeter.com/projects/antimony/3/, and
BRL-CAD are examples of open-source software that does that. I looked into
using them instead, but ran into roadblocks pretty immediately -
ImplicitCAD is built mainly for linux, and none of the dev's have windows
machines to test a windows build on, I tried installing it and couldn't get
it done; Antimony is built for linux and OS-X and has an experimental
windows build (haven't tried it yet); BRL-CAD is probably a great piece of
software for an experienced developer but has a very steep learning curve
since it is meant for managing very large, multi-purpose designs (e.g.,
having a full operational schematic of the parts for a tank, and being able
to both create a nice 3D rendering of it as well as CAD files of each
individual part for giving a manufacturer a dimensional specification for
an order).
Antimony http://www.mattkeeter.com/projects/antimony/3/ has the most
forward thinking GUI interface that naturally keeps track of the branching
of successive operations on an object (intersections, subtractions, locking
the relation of the dimension of a second part based on a first part,
etc.). If I had a linux OS installed or could get one to dual boot just for
using that piece of software, I would. I believe OpenSCAD's popularity
within the 3D printing community comes from the accessibility of the
documentation, ease of install without errors on every platform, and the
quick-render ability to iterate your design before doing a full render.
ImplicitCAD showed similar promise in being easy to use, but was never
developed to the level that it had the quick render / GUI apparatus to
check your design with each change you make - you'd have to run a render
from the command line and then open the generated image file which is a
rather clunky process, but since it naturally runs multi-threaded from the
ground up with implicit surfaces (B-REP), the render time is much faster
(seconds vs. minutes to hours in OpenSCAD) for relatively simple stuff like
these meshes.
If there were some developers willing to really put in the time, that type
of render engine could probably be integrated into OpenSCAD, but it would
take a lot of effort and you can't complain too much when someone gives you
software for free! I think OpenSCAD's primary usefulness is for either
generating extremely simple models, or modifying existing ones that are
imported. One example is a wire-mesh klein bottle I found on thingiverse
http://www.thingiverse.com/thing:525567 - it doesn't have an open hole
where the pipe intersects the side of the bottle, so I imported it into
OpenSCAD and did a boolean operation to cut a hole, and added a ring to
create a clean support structure for the intersection of the pipe and the
bottle. The result turned out perfect when I printed it.
While I'd like to do more complicated things with OpenSCAD, it is not
well-suited to do the more organic designs like voronoi meshes. I made a
basic wire-frame library, but since OpenSCAD doesn't like to deal with
for() loops of greater than 10,000 iterations without some great pain,
you're really better off generating mesh point sets using an external
scripting library like SolidPython if you're insistent on using OpenSCAD
for the render itself. I've done a few experiments with SolidPython, and it
is pretty good at generating the polyehdron facet sets that OpenSCAD
understands, and OpenSCAD definitely renders them much faster since it
doesn't have to do any of the successive boolean operations itself.
On Sat, Mar 25, 2017 at 11:35 AM, doug moen doug@moens.org wrote:
OpenSCAD is an awesome tool, but I don't think its design is the best for
doing George Hart style fractals, lattices, etc.
Consider Parkinbot's lattice, a union of spheres and cylinders. OpenSCAD
converts these spheres and cylinders into mesh approximations as early as
possible, and then uses a very expensive mesh-based union operator
(currently from CGAL) to perform the union. The performance and memory
consumption degrades non-linearly as $fn gets higher. That will still be
true if OpenSCAD switches to Carve.
A better approach, I think, it to represent spheres and cylinders exactly,
using a very cheap representation (origin, radius, height), and delay the
construction of the mesh until the final stage of rendering, using high
level information from the CSG tree to pick rendering strategies.
OpenSCAD is also single threaded. I think the best performance will result
from doing the rendering on the GPU, because then you can take advantage of
massive parallelism.
I'm interested in exploring these ideas within an open source project.
On 25 March 2017 at 07:14, arnholm@arnholm.org wrote:
On 2017-03-25 00:54, doug moen wrote:
Well, I think that even 23 seconds is a long time for such a trivial
construction. It really ought to be a fraction of a second.
Of course one wants everything at no cost, but that is not going to
happen. It is better to evaluate what the main factors are and what
realistically can be achieved. The number of facets is obviously one major
factor, but it isn't the only answer.
My little example showed it is possible to improve ~an order of magnitude
just by using another boolean engine. There are also other paths to pursue,
such as multi-threaded processing, which I will try at some stage. The
numbers I gave were just snapshots of current working implementations for
comparison, both single threaded.
Another thing I tried was observing memory use. I factored the dimensions
up by 2 and watched memory use. For this relatively small model,
OpenSCAD/CGAL required more than 6GB of ram (64bit), which seems hard to
justify. That alone is a major performance issue. My Carve-based engine was
never higher than 400MB ram for the same problem, so you are looking at an
order of magnitude difference there.
Carsten Arnholm
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Doug,
What you're referring to is B-REP (boundary representation), and OpenSCAD
would need to be rebuilt from the ground up to do that unfortunately.
ImplicitCAD, Antimony <http://www.mattkeeter.com/projects/antimony/3/>, and
BRL-CAD are examples of open-source software that does that. I looked into
using them instead, but ran into roadblocks pretty immediately -
ImplicitCAD is built mainly for linux, and none of the dev's have windows
machines to test a windows build on, I tried installing it and couldn't get
it done; Antimony is built for linux and OS-X and has an experimental
windows build (haven't tried it yet); BRL-CAD is probably a great piece of
software for an experienced developer but has a very steep learning curve
since it is meant for managing very large, multi-purpose designs (e.g.,
having a full operational schematic of the parts for a tank, and being able
to both create a nice 3D rendering of it as well as CAD files of each
individual part for giving a manufacturer a dimensional specification for
an order).
Antimony <http://www.mattkeeter.com/projects/antimony/3/> has the most
forward thinking GUI interface that naturally keeps track of the branching
of successive operations on an object (intersections, subtractions, locking
the relation of the dimension of a second part based on a first part,
etc.). If I had a linux OS installed or could get one to dual boot just for
using that piece of software, I would. I believe OpenSCAD's popularity
within the 3D printing community comes from the accessibility of the
documentation, ease of install without errors on every platform, and the
quick-render ability to iterate your design before doing a full render.
ImplicitCAD showed similar promise in being easy to use, but was never
developed to the level that it had the quick render / GUI apparatus to
check your design with each change you make - you'd have to run a render
from the command line and then open the generated image file which is a
rather clunky process, but since it naturally runs multi-threaded from the
ground up with implicit surfaces (B-REP), the render time is much faster
(seconds vs. minutes to hours in OpenSCAD) for relatively simple stuff like
these meshes.
If there were some developers willing to really put in the time, that type
of render engine could probably be integrated into OpenSCAD, but it would
take a lot of effort and you can't complain too much when someone gives you
software for free! I think OpenSCAD's primary usefulness is for either
generating extremely simple models, or modifying existing ones that are
imported. One example is a wire-mesh klein bottle I found on thingiverse
<http://www.thingiverse.com/thing:525567> - it doesn't have an open hole
where the pipe intersects the side of the bottle, so I imported it into
OpenSCAD and did a boolean operation to cut a hole, and added a ring to
create a clean support structure for the intersection of the pipe and the
bottle. The result turned out perfect when I printed it.
While I'd like to do more complicated things with OpenSCAD, it is not
well-suited to do the more organic designs like voronoi meshes. I made a
basic wire-frame library, but since OpenSCAD doesn't like to deal with
for() loops of greater than 10,000 iterations without some great pain,
you're really better off generating mesh point sets using an external
scripting library like SolidPython if you're insistent on using OpenSCAD
for the render itself. I've done a few experiments with SolidPython, and it
is pretty good at generating the polyehdron facet sets that OpenSCAD
understands, and OpenSCAD definitely renders them much faster since it
doesn't have to do any of the successive boolean operations itself.
On Sat, Mar 25, 2017 at 11:35 AM, doug moen <doug@moens.org> wrote:
> OpenSCAD is an awesome tool, but I don't think its design is the best for
> doing George Hart style fractals, lattices, etc.
>
> Consider Parkinbot's lattice, a union of spheres and cylinders. OpenSCAD
> converts these spheres and cylinders into mesh approximations as early as
> possible, and then uses a very expensive mesh-based union operator
> (currently from CGAL) to perform the union. The performance and memory
> consumption degrades non-linearly as $fn gets higher. That will still be
> true if OpenSCAD switches to Carve.
>
> A better approach, I think, it to represent spheres and cylinders exactly,
> using a very cheap representation (origin, radius, height), and delay the
> construction of the mesh until the final stage of rendering, using high
> level information from the CSG tree to pick rendering strategies.
>
> OpenSCAD is also single threaded. I think the best performance will result
> from doing the rendering on the GPU, because then you can take advantage of
> massive parallelism.
>
> I'm interested in exploring these ideas within an open source project.
>
> On 25 March 2017 at 07:14, <arnholm@arnholm.org> wrote:
>
>> On 2017-03-25 00:54, doug moen wrote:
>>
>>> Well, I think that even 23 seconds is a long time for such a trivial
>>> construction. It really ought to be a fraction of a second.
>>>
>>
>> Of course one wants everything at no cost, but that is not going to
>> happen. It is better to evaluate what the main factors are and what
>> realistically can be achieved. The number of facets is obviously one major
>> factor, but it isn't the only answer.
>>
>> My little example showed it is possible to improve ~an order of magnitude
>> just by using another boolean engine. There are also other paths to pursue,
>> such as multi-threaded processing, which I will try at some stage. The
>> numbers I gave were just snapshots of current working implementations for
>> comparison, both single threaded.
>>
>> Another thing I tried was observing memory use. I factored the dimensions
>> up by 2 and watched memory use. For this relatively small model,
>> OpenSCAD/CGAL required more than 6GB of ram (64bit), which seems hard to
>> justify. That alone is a major performance issue. My Carve-based engine was
>> never higher than 400MB ram for the same problem, so you are looking at an
>> order of magnitude difference there.
>>
>>
>> Carsten Arnholm
>>
>> _______________________________________________
>> 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
>
>
DC
David Coneff
Sat, Mar 25, 2017 8:21 PM
As an aside, Making this sort of lattice structure would be hugely more
efficient in OpenSCAD if the cylinders were replaced with rectangular
cubes. Cubes have such a simple vertex structure that they are handled by
both CGAL and OpenGL with ease. If you're trying to make a lattice of a
certain size and just want to make a mock-up before doing a full render, it
would make more sense to start with code that can replace the geometric
primitive with a simpler one first, and do the final render for STL export
(if you're 3D printing it) with the cylinders later. Ultimately though, the
slowness is a product of how OpenSCAD operates at a pretty base level and
F-REP/ B-REP is the only way to make it faster and truly multi-threaded.
On Sat, Mar 25, 2017 at 2:00 PM, David Coneff david.coneff@gmail.com
wrote:
Doug,
What you're referring to is B-REP (boundary representation), and OpenSCAD
would need to be rebuilt from the ground up to do that unfortunately.
ImplicitCAD, Antimony http://www.mattkeeter.com/projects/antimony/3/,
and BRL-CAD are examples of open-source software that does that. I looked
into using them instead, but ran into roadblocks pretty immediately -
ImplicitCAD is built mainly for linux, and none of the dev's have windows
machines to test a windows build on, I tried installing it and couldn't get
it done; Antimony is built for linux and OS-X and has an experimental
windows build (haven't tried it yet); BRL-CAD is probably a great piece of
software for an experienced developer but has a very steep learning curve
since it is meant for managing very large, multi-purpose designs (e.g.,
having a full operational schematic of the parts for a tank, and being able
to both create a nice 3D rendering of it as well as CAD files of each
individual part for giving a manufacturer a dimensional specification for
an order).
Antimony http://www.mattkeeter.com/projects/antimony/3/ has the most
forward thinking GUI interface that naturally keeps track of the branching
of successive operations on an object (intersections, subtractions, locking
the relation of the dimension of a second part based on a first part,
etc.). If I had a linux OS installed or could get one to dual boot just for
using that piece of software, I would. I believe OpenSCAD's popularity
within the 3D printing community comes from the accessibility of the
documentation, ease of install without errors on every platform, and the
quick-render ability to iterate your design before doing a full render.
ImplicitCAD showed similar promise in being easy to use, but was never
developed to the level that it had the quick render / GUI apparatus to
check your design with each change you make - you'd have to run a render
from the command line and then open the generated image file which is a
rather clunky process, but since it naturally runs multi-threaded from the
ground up with implicit surfaces (B-REP), the render time is much faster
(seconds vs. minutes to hours in OpenSCAD) for relatively simple stuff like
these meshes.
If there were some developers willing to really put in the time, that type
of render engine could probably be integrated into OpenSCAD, but it would
take a lot of effort and you can't complain too much when someone gives you
software for free! I think OpenSCAD's primary usefulness is for either
generating extremely simple models, or modifying existing ones that are
imported. One example is a wire-mesh klein bottle I found on thingiverse
http://www.thingiverse.com/thing:525567 - it doesn't have an open hole
where the pipe intersects the side of the bottle, so I imported it into
OpenSCAD and did a boolean operation to cut a hole, and added a ring to
create a clean support structure for the intersection of the pipe and the
bottle. The result turned out perfect when I printed it.
While I'd like to do more complicated things with OpenSCAD, it is not
well-suited to do the more organic designs like voronoi meshes. I made a
basic wire-frame library, but since OpenSCAD doesn't like to deal with
for() loops of greater than 10,000 iterations without some great pain,
you're really better off generating mesh point sets using an external
scripting library like SolidPython if you're insistent on using OpenSCAD
for the render itself. I've done a few experiments with SolidPython, and it
is pretty good at generating the polyehdron facet sets that OpenSCAD
understands, and OpenSCAD definitely renders them much faster since it
doesn't have to do any of the successive boolean operations itself.
On Sat, Mar 25, 2017 at 11:35 AM, doug moen doug@moens.org wrote:
OpenSCAD is an awesome tool, but I don't think its design is the best for
doing George Hart style fractals, lattices, etc.
Consider Parkinbot's lattice, a union of spheres and cylinders. OpenSCAD
converts these spheres and cylinders into mesh approximations as early as
possible, and then uses a very expensive mesh-based union operator
(currently from CGAL) to perform the union. The performance and memory
consumption degrades non-linearly as $fn gets higher. That will still be
true if OpenSCAD switches to Carve.
A better approach, I think, it to represent spheres and cylinders
exactly, using a very cheap representation (origin, radius, height), and
delay the construction of the mesh until the final stage of rendering,
using high level information from the CSG tree to pick rendering strategies.
OpenSCAD is also single threaded. I think the best performance will
result from doing the rendering on the GPU, because then you can take
advantage of massive parallelism.
I'm interested in exploring these ideas within an open source project.
On 25 March 2017 at 07:14, arnholm@arnholm.org wrote:
On 2017-03-25 00:54, doug moen wrote:
Well, I think that even 23 seconds is a long time for such a trivial
construction. It really ought to be a fraction of a second.
Of course one wants everything at no cost, but that is not going to
happen. It is better to evaluate what the main factors are and what
realistically can be achieved. The number of facets is obviously one major
factor, but it isn't the only answer.
My little example showed it is possible to improve ~an order of
magnitude just by using another boolean engine. There are also other paths
to pursue, such as multi-threaded processing, which I will try at some
stage. The numbers I gave were just snapshots of current working
implementations for comparison, both single threaded.
Another thing I tried was observing memory use. I factored the
dimensions up by 2 and watched memory use. For this relatively small model,
OpenSCAD/CGAL required more than 6GB of ram (64bit), which seems hard to
justify. That alone is a major performance issue. My Carve-based engine was
never higher than 400MB ram for the same problem, so you are looking at an
order of magnitude difference there.
Carsten Arnholm
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
As an aside, Making this sort of lattice structure would be hugely more
efficient in OpenSCAD if the cylinders were replaced with rectangular
cubes. Cubes have such a simple vertex structure that they are handled by
both CGAL and OpenGL with ease. If you're trying to make a lattice of a
certain size and just want to make a mock-up before doing a full render, it
would make more sense to start with code that can replace the geometric
primitive with a simpler one first, and do the final render for STL export
(if you're 3D printing it) with the cylinders later. Ultimately though, the
slowness is a product of how OpenSCAD operates at a pretty base level and
F-REP/ B-REP is the only way to make it faster and truly multi-threaded.
On Sat, Mar 25, 2017 at 2:00 PM, David Coneff <david.coneff@gmail.com>
wrote:
> Doug,
>
> What you're referring to is B-REP (boundary representation), and OpenSCAD
> would need to be rebuilt from the ground up to do that unfortunately.
> ImplicitCAD, Antimony <http://www.mattkeeter.com/projects/antimony/3/>,
> and BRL-CAD are examples of open-source software that does that. I looked
> into using them instead, but ran into roadblocks pretty immediately -
> ImplicitCAD is built mainly for linux, and none of the dev's have windows
> machines to test a windows build on, I tried installing it and couldn't get
> it done; Antimony is built for linux and OS-X and has an experimental
> windows build (haven't tried it yet); BRL-CAD is probably a great piece of
> software for an experienced developer but has a very steep learning curve
> since it is meant for managing very large, multi-purpose designs (e.g.,
> having a full operational schematic of the parts for a tank, and being able
> to both create a nice 3D rendering of it as well as CAD files of each
> individual part for giving a manufacturer a dimensional specification for
> an order).
>
> Antimony <http://www.mattkeeter.com/projects/antimony/3/> has the most
> forward thinking GUI interface that naturally keeps track of the branching
> of successive operations on an object (intersections, subtractions, locking
> the relation of the dimension of a second part based on a first part,
> etc.). If I had a linux OS installed or could get one to dual boot just for
> using that piece of software, I would. I believe OpenSCAD's popularity
> within the 3D printing community comes from the accessibility of the
> documentation, ease of install without errors on every platform, and the
> quick-render ability to iterate your design before doing a full render.
> ImplicitCAD showed similar promise in being easy to use, but was never
> developed to the level that it had the quick render / GUI apparatus to
> check your design with each change you make - you'd have to run a render
> from the command line and then open the generated image file which is a
> rather clunky process, but since it naturally runs multi-threaded from the
> ground up with implicit surfaces (B-REP), the render time is much faster
> (seconds vs. minutes to hours in OpenSCAD) for relatively simple stuff like
> these meshes.
>
> If there were some developers willing to really put in the time, that type
> of render engine could probably be integrated into OpenSCAD, but it would
> take a lot of effort and you can't complain too much when someone gives you
> software for free! I think OpenSCAD's primary usefulness is for either
> generating extremely simple models, or modifying existing ones that are
> imported. One example is a wire-mesh klein bottle I found on thingiverse
> <http://www.thingiverse.com/thing:525567> - it doesn't have an open hole
> where the pipe intersects the side of the bottle, so I imported it into
> OpenSCAD and did a boolean operation to cut a hole, and added a ring to
> create a clean support structure for the intersection of the pipe and the
> bottle. The result turned out perfect when I printed it.
>
> While I'd like to do more complicated things with OpenSCAD, it is not
> well-suited to do the more organic designs like voronoi meshes. I made a
> basic wire-frame library, but since OpenSCAD doesn't like to deal with
> for() loops of greater than 10,000 iterations without some great pain,
> you're really better off generating mesh point sets using an external
> scripting library like SolidPython if you're insistent on using OpenSCAD
> for the render itself. I've done a few experiments with SolidPython, and it
> is pretty good at generating the polyehdron facet sets that OpenSCAD
> understands, and OpenSCAD definitely renders them much faster since it
> doesn't have to do any of the successive boolean operations itself.
>
> On Sat, Mar 25, 2017 at 11:35 AM, doug moen <doug@moens.org> wrote:
>
>> OpenSCAD is an awesome tool, but I don't think its design is the best for
>> doing George Hart style fractals, lattices, etc.
>>
>> Consider Parkinbot's lattice, a union of spheres and cylinders. OpenSCAD
>> converts these spheres and cylinders into mesh approximations as early as
>> possible, and then uses a very expensive mesh-based union operator
>> (currently from CGAL) to perform the union. The performance and memory
>> consumption degrades non-linearly as $fn gets higher. That will still be
>> true if OpenSCAD switches to Carve.
>>
>> A better approach, I think, it to represent spheres and cylinders
>> exactly, using a very cheap representation (origin, radius, height), and
>> delay the construction of the mesh until the final stage of rendering,
>> using high level information from the CSG tree to pick rendering strategies.
>>
>> OpenSCAD is also single threaded. I think the best performance will
>> result from doing the rendering on the GPU, because then you can take
>> advantage of massive parallelism.
>>
>> I'm interested in exploring these ideas within an open source project.
>>
>> On 25 March 2017 at 07:14, <arnholm@arnholm.org> wrote:
>>
>>> On 2017-03-25 00:54, doug moen wrote:
>>>
>>>> Well, I think that even 23 seconds is a long time for such a trivial
>>>> construction. It really ought to be a fraction of a second.
>>>>
>>>
>>> Of course one wants everything at no cost, but that is not going to
>>> happen. It is better to evaluate what the main factors are and what
>>> realistically can be achieved. The number of facets is obviously one major
>>> factor, but it isn't the only answer.
>>>
>>> My little example showed it is possible to improve ~an order of
>>> magnitude just by using another boolean engine. There are also other paths
>>> to pursue, such as multi-threaded processing, which I will try at some
>>> stage. The numbers I gave were just snapshots of current working
>>> implementations for comparison, both single threaded.
>>>
>>> Another thing I tried was observing memory use. I factored the
>>> dimensions up by 2 and watched memory use. For this relatively small model,
>>> OpenSCAD/CGAL required more than 6GB of ram (64bit), which seems hard to
>>> justify. That alone is a major performance issue. My Carve-based engine was
>>> never higher than 400MB ram for the same problem, so you are looking at an
>>> order of magnitude difference there.
>>>
>>>
>>> Carsten Arnholm
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
DM
doug moen
Sat, Mar 25, 2017 9:09 PM
Hi David.
B-Rep means boundary representation: a shape is represented by its
boundary. OpenSCAD's mesh/polyhedron representation is a kind of B-Rep.
NURBS are another kind of boundary representation. CSG means that you
represent a shape as a tree of primitive shapes and operations on those
shapes (like boolean operations and affine transformations). OpenSCAD
evaluates a program to construct a CSG, which is then converted to a mesh
(B-Rep) using CGAL et al.
I've looked at BRL-CAD, but I encountered the same learning curve problem,
and haven't tried to use it. It seems to use CSG and two kinds of B-Rep
(NURBS and meshes) to represent shapes. I don't see any support for F-Rep.
F-Rep is functional representation. There is no explicit representation of
a shape's boundary. Instead, there is a distance function that maps every
point [x,y,z] in 3-space onto a signed distance value, which indicates the
distance of the point from the boundary of the object, and the sign
indicates whether the point is inside or outside of the object. Antimony
and ImplicitCAD use F-Rep. Although they can export STL files, they can't
directly manipulate B-Rep representations the same way OpenSCAD can.
I've read the source code for ImplicitCAD and Antimony, and I'm currently
trying to build an F-Rep geometry kernel that runs on a GPU, to see if it
will have the performance characteristics I want. F-Rep has very cheap
boolean operations, and avoids the cost of performing boolean operations on
polyhedral approximations of curved surfaces. Also, F-Rep is easy to
parallelize on a GPU. So right now it looks like a good way to achieve my
goals. Eventually, though, I'd like to extend this to an F-Rep/B-Rep hybrid
system, to make it more general purpose.
It would be difficult to integrate my work back into OpenSCAD. One problem
is that my approach represents shapes as functions, and requires a
functional language with first class function values (ie, closures), and
it's very difficult to retrofit this feature into OpenSCAD without breaking
backward compatibility. Another problem is due to the fact that I don't
convert curved surfaces into polygons before applying boolean operations
and other transformations. They remain as mathematically exact curved
surfaces. In OpenSCAD, users rely on the fact that circle, sphere and
cylinder return polygons and polyhedra, not curved shapes. Eg,
circle(r,$fn=6) is a regular hexagon. My system has circle and
regular_polygon as separate primitives. So that would be another backward
compatibility problem.
On 25 March 2017 at 16:00, David Coneff david.coneff@gmail.com wrote:
Doug,
What you're referring to is B-REP (boundary representation), and OpenSCAD
would need to be rebuilt from the ground up to do that unfortunately.
ImplicitCAD, Antimony http://www.mattkeeter.com/projects/antimony/3/,
and BRL-CAD are examples of open-source software that does that. I looked
into using them instead, but ran into roadblocks pretty immediately -
ImplicitCAD is built mainly for linux, and none of the dev's have windows
machines to test a windows build on, I tried installing it and couldn't get
it done; Antimony is built for linux and OS-X and has an experimental
windows build (haven't tried it yet); BRL-CAD is probably a great piece of
software for an experienced developer but has a very steep learning curve
since it is meant for managing very large, multi-purpose designs (e.g.,
having a full operational schematic of the parts for a tank, and being able
to both create a nice 3D rendering of it as well as CAD files of each
individual part for giving a manufacturer a dimensional specification for
an order).
Antimony http://www.mattkeeter.com/projects/antimony/3/ has the most
forward thinking GUI interface that naturally keeps track of the branching
of successive operations on an object (intersections, subtractions, locking
the relation of the dimension of a second part based on a first part,
etc.). If I had a linux OS installed or could get one to dual boot just for
using that piece of software, I would. I believe OpenSCAD's popularity
within the 3D printing community comes from the accessibility of the
documentation, ease of install without errors on every platform, and the
quick-render ability to iterate your design before doing a full render.
ImplicitCAD showed similar promise in being easy to use, but was never
developed to the level that it had the quick render / GUI apparatus to
check your design with each change you make - you'd have to run a render
from the command line and then open the generated image file which is a
rather clunky process, but since it naturally runs multi-threaded from the
ground up with implicit surfaces (B-REP), the render time is much faster
(seconds vs. minutes to hours in OpenSCAD) for relatively simple stuff like
these meshes.
If there were some developers willing to really put in the time, that type
of render engine could probably be integrated into OpenSCAD, but it would
take a lot of effort and you can't complain too much when someone gives you
software for free! I think OpenSCAD's primary usefulness is for either
generating extremely simple models, or modifying existing ones that are
imported. One example is a wire-mesh klein bottle I found on thingiverse
http://www.thingiverse.com/thing:525567 - it doesn't have an open hole
where the pipe intersects the side of the bottle, so I imported it into
OpenSCAD and did a boolean operation to cut a hole, and added a ring to
create a clean support structure for the intersection of the pipe and the
bottle. The result turned out perfect when I printed it.
While I'd like to do more complicated things with OpenSCAD, it is not
well-suited to do the more organic designs like voronoi meshes. I made a
basic wire-frame library, but since OpenSCAD doesn't like to deal with
for() loops of greater than 10,000 iterations without some great pain,
you're really better off generating mesh point sets using an external
scripting library like SolidPython if you're insistent on using OpenSCAD
for the render itself. I've done a few experiments with SolidPython, and it
is pretty good at generating the polyehdron facet sets that OpenSCAD
understands, and OpenSCAD definitely renders them much faster since it
doesn't have to do any of the successive boolean operations itself.
On Sat, Mar 25, 2017 at 11:35 AM, doug moen doug@moens.org wrote:
OpenSCAD is an awesome tool, but I don't think its design is the best for
doing George Hart style fractals, lattices, etc.
Consider Parkinbot's lattice, a union of spheres and cylinders. OpenSCAD
converts these spheres and cylinders into mesh approximations as early as
possible, and then uses a very expensive mesh-based union operator
(currently from CGAL) to perform the union. The performance and memory
consumption degrades non-linearly as $fn gets higher. That will still be
true if OpenSCAD switches to Carve.
A better approach, I think, it to represent spheres and cylinders
exactly, using a very cheap representation (origin, radius, height), and
delay the construction of the mesh until the final stage of rendering,
using high level information from the CSG tree to pick rendering strategies.
OpenSCAD is also single threaded. I think the best performance will
result from doing the rendering on the GPU, because then you can take
advantage of massive parallelism.
I'm interested in exploring these ideas within an open source project.
On 25 March 2017 at 07:14, arnholm@arnholm.org wrote:
On 2017-03-25 00:54, doug moen wrote:
Well, I think that even 23 seconds is a long time for such a trivial
construction. It really ought to be a fraction of a second.
Of course one wants everything at no cost, but that is not going to
happen. It is better to evaluate what the main factors are and what
realistically can be achieved. The number of facets is obviously one major
factor, but it isn't the only answer.
My little example showed it is possible to improve ~an order of
magnitude just by using another boolean engine. There are also other paths
to pursue, such as multi-threaded processing, which I will try at some
stage. The numbers I gave were just snapshots of current working
implementations for comparison, both single threaded.
Another thing I tried was observing memory use. I factored the
dimensions up by 2 and watched memory use. For this relatively small model,
OpenSCAD/CGAL required more than 6GB of ram (64bit), which seems hard to
justify. That alone is a major performance issue. My Carve-based engine was
never higher than 400MB ram for the same problem, so you are looking at an
order of magnitude difference there.
Carsten Arnholm
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Hi David.
B-Rep means boundary representation: a shape is represented by its
boundary. OpenSCAD's mesh/polyhedron representation is a kind of B-Rep.
NURBS are another kind of boundary representation. CSG means that you
represent a shape as a tree of primitive shapes and operations on those
shapes (like boolean operations and affine transformations). OpenSCAD
evaluates a program to construct a CSG, which is then converted to a mesh
(B-Rep) using CGAL et al.
I've looked at BRL-CAD, but I encountered the same learning curve problem,
and haven't tried to use it. It seems to use CSG and two kinds of B-Rep
(NURBS and meshes) to represent shapes. I don't see any support for F-Rep.
F-Rep is functional representation. There is no explicit representation of
a shape's boundary. Instead, there is a distance function that maps every
point [x,y,z] in 3-space onto a signed distance value, which indicates the
distance of the point from the boundary of the object, and the sign
indicates whether the point is inside or outside of the object. Antimony
and ImplicitCAD use F-Rep. Although they can export STL files, they can't
directly manipulate B-Rep representations the same way OpenSCAD can.
I've read the source code for ImplicitCAD and Antimony, and I'm currently
trying to build an F-Rep geometry kernel that runs on a GPU, to see if it
will have the performance characteristics I want. F-Rep has very cheap
boolean operations, and avoids the cost of performing boolean operations on
polyhedral approximations of curved surfaces. Also, F-Rep is easy to
parallelize on a GPU. So right now it looks like a good way to achieve my
goals. Eventually, though, I'd like to extend this to an F-Rep/B-Rep hybrid
system, to make it more general purpose.
It would be difficult to integrate my work back into OpenSCAD. One problem
is that my approach represents shapes as functions, and requires a
functional language with first class function values (ie, closures), and
it's very difficult to retrofit this feature into OpenSCAD without breaking
backward compatibility. Another problem is due to the fact that I don't
convert curved surfaces into polygons before applying boolean operations
and other transformations. They remain as mathematically exact curved
surfaces. In OpenSCAD, users rely on the fact that circle, sphere and
cylinder return polygons and polyhedra, not curved shapes. Eg,
circle(r,$fn=6) is a regular hexagon. My system has circle and
regular_polygon as separate primitives. So that would be another backward
compatibility problem.
On 25 March 2017 at 16:00, David Coneff <david.coneff@gmail.com> wrote:
> Doug,
>
> What you're referring to is B-REP (boundary representation), and OpenSCAD
> would need to be rebuilt from the ground up to do that unfortunately.
> ImplicitCAD, Antimony <http://www.mattkeeter.com/projects/antimony/3/>,
> and BRL-CAD are examples of open-source software that does that. I looked
> into using them instead, but ran into roadblocks pretty immediately -
> ImplicitCAD is built mainly for linux, and none of the dev's have windows
> machines to test a windows build on, I tried installing it and couldn't get
> it done; Antimony is built for linux and OS-X and has an experimental
> windows build (haven't tried it yet); BRL-CAD is probably a great piece of
> software for an experienced developer but has a very steep learning curve
> since it is meant for managing very large, multi-purpose designs (e.g.,
> having a full operational schematic of the parts for a tank, and being able
> to both create a nice 3D rendering of it as well as CAD files of each
> individual part for giving a manufacturer a dimensional specification for
> an order).
>
> Antimony <http://www.mattkeeter.com/projects/antimony/3/> has the most
> forward thinking GUI interface that naturally keeps track of the branching
> of successive operations on an object (intersections, subtractions, locking
> the relation of the dimension of a second part based on a first part,
> etc.). If I had a linux OS installed or could get one to dual boot just for
> using that piece of software, I would. I believe OpenSCAD's popularity
> within the 3D printing community comes from the accessibility of the
> documentation, ease of install without errors on every platform, and the
> quick-render ability to iterate your design before doing a full render.
> ImplicitCAD showed similar promise in being easy to use, but was never
> developed to the level that it had the quick render / GUI apparatus to
> check your design with each change you make - you'd have to run a render
> from the command line and then open the generated image file which is a
> rather clunky process, but since it naturally runs multi-threaded from the
> ground up with implicit surfaces (B-REP), the render time is much faster
> (seconds vs. minutes to hours in OpenSCAD) for relatively simple stuff like
> these meshes.
>
> If there were some developers willing to really put in the time, that type
> of render engine could probably be integrated into OpenSCAD, but it would
> take a lot of effort and you can't complain too much when someone gives you
> software for free! I think OpenSCAD's primary usefulness is for either
> generating extremely simple models, or modifying existing ones that are
> imported. One example is a wire-mesh klein bottle I found on thingiverse
> <http://www.thingiverse.com/thing:525567> - it doesn't have an open hole
> where the pipe intersects the side of the bottle, so I imported it into
> OpenSCAD and did a boolean operation to cut a hole, and added a ring to
> create a clean support structure for the intersection of the pipe and the
> bottle. The result turned out perfect when I printed it.
>
> While I'd like to do more complicated things with OpenSCAD, it is not
> well-suited to do the more organic designs like voronoi meshes. I made a
> basic wire-frame library, but since OpenSCAD doesn't like to deal with
> for() loops of greater than 10,000 iterations without some great pain,
> you're really better off generating mesh point sets using an external
> scripting library like SolidPython if you're insistent on using OpenSCAD
> for the render itself. I've done a few experiments with SolidPython, and it
> is pretty good at generating the polyehdron facet sets that OpenSCAD
> understands, and OpenSCAD definitely renders them much faster since it
> doesn't have to do any of the successive boolean operations itself.
>
> On Sat, Mar 25, 2017 at 11:35 AM, doug moen <doug@moens.org> wrote:
>
>> OpenSCAD is an awesome tool, but I don't think its design is the best for
>> doing George Hart style fractals, lattices, etc.
>>
>> Consider Parkinbot's lattice, a union of spheres and cylinders. OpenSCAD
>> converts these spheres and cylinders into mesh approximations as early as
>> possible, and then uses a very expensive mesh-based union operator
>> (currently from CGAL) to perform the union. The performance and memory
>> consumption degrades non-linearly as $fn gets higher. That will still be
>> true if OpenSCAD switches to Carve.
>>
>> A better approach, I think, it to represent spheres and cylinders
>> exactly, using a very cheap representation (origin, radius, height), and
>> delay the construction of the mesh until the final stage of rendering,
>> using high level information from the CSG tree to pick rendering strategies.
>>
>> OpenSCAD is also single threaded. I think the best performance will
>> result from doing the rendering on the GPU, because then you can take
>> advantage of massive parallelism.
>>
>> I'm interested in exploring these ideas within an open source project.
>>
>> On 25 March 2017 at 07:14, <arnholm@arnholm.org> wrote:
>>
>>> On 2017-03-25 00:54, doug moen wrote:
>>>
>>>> Well, I think that even 23 seconds is a long time for such a trivial
>>>> construction. It really ought to be a fraction of a second.
>>>>
>>>
>>> Of course one wants everything at no cost, but that is not going to
>>> happen. It is better to evaluate what the main factors are and what
>>> realistically can be achieved. The number of facets is obviously one major
>>> factor, but it isn't the only answer.
>>>
>>> My little example showed it is possible to improve ~an order of
>>> magnitude just by using another boolean engine. There are also other paths
>>> to pursue, such as multi-threaded processing, which I will try at some
>>> stage. The numbers I gave were just snapshots of current working
>>> implementations for comparison, both single threaded.
>>>
>>> Another thing I tried was observing memory use. I factored the
>>> dimensions up by 2 and watched memory use. For this relatively small model,
>>> OpenSCAD/CGAL required more than 6GB of ram (64bit), which seems hard to
>>> justify. That alone is a major performance issue. My Carve-based engine was
>>> never higher than 400MB ram for the same problem, so you are looking at an
>>> order of magnitude difference there.
>>>
>>>
>>> Carsten Arnholm
>>>
>>> _______________________________________________
>>> 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
>
>
R
Ronaldo
Sat, Mar 25, 2017 9:27 PM
A better approach, I think, it to represent spheres and cylinders exactly,
using a very cheap representation (origin, radius, height), and delay the
construction of the mesh until the final stage of rendering, using high
level information from the CSG tree to pick rendering strategies.
OpenSCAD is also single threaded. I think the best performance will result
from doing the rendering on the GPU, because then you can take advantage
of
massive parallelism.
Although there are many independent ways OpenSCAD could follow to accelerate
the render, the simpler one that could give us immediate gain is to use
bounding boxes (and/or even better octrees). An array of just 6x6 disjoint
spheres takes almost 140 sec to render in my machine, about 75% of the
running time is needed when they overlap.
r = 10;
//s = 25; // disjoint
s = 15; // overlap
n = 6;
for(i=[0:n-1], j=[0:n-1]) translate([si,sj,0]) sphere(r);
doug.moen wrote
> A better approach, I think, it to represent spheres and cylinders exactly,
> using a very cheap representation (origin, radius, height), and delay the
> construction of the mesh until the final stage of rendering, using high
> level information from the CSG tree to pick rendering strategies.
>
> OpenSCAD is also single threaded. I think the best performance will result
> from doing the rendering on the GPU, because then you can take advantage
> of
> massive parallelism.
Although there are many independent ways OpenSCAD could follow to accelerate
the render, the simpler one that could give us immediate gain is to use
bounding boxes (and/or even better octrees). An array of just 6x6 disjoint
spheres takes almost 140 sec to render in my machine, about 75% of the
running time is needed when they overlap.
> r = 10;
> //s = 25; // disjoint
> s = 15; // overlap
> n = 6;
> for(i=[0:n-1], j=[0:n-1]) translate([s*i,s*j,0]) sphere(r);
--
View this message in context: http://forum.openscad.org/Lattice-structure-tp21001p21034.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
DC
David Coneff
Sat, Mar 25, 2017 9:50 PM
You're right, I mixed up some of the details between F-REP and B-REP. F-REP
definitely seems like the way to go, I'm not certain but I think Blender is
a hybrid F-REP/B-REP system - even simple things like cubes with filleted
corners that would slow down OpenSCAD's engine enormously for manipulation
in the GUI run very smoothly in Blender. It even has a terminal for running
python scripts! Only thing is, it also has an extremely steep learning
curve due to its very multi-purpose nature (animation, model production,
etc.) despite the much slicker interface and active development community
compared to BRL-CAD. I'm probably still going to invest some time in
learning that software as well since it is the fastest path to more organic
designs and creating computationally generated designs with python scripts,
but for the moment I can get more done in a day with OpenSCAD than Blender
since I spend so much time just fighting the GUI and various quirks of
Blender. Any advanced tool is bound to have those problems with a learning
curve though.
If OpenSCAD is to have F-REP as a hybrid system, there will inevitably be
some breaks in the backward compatibility, and IMO that's not something to
be avoided. The use of circle($fn=6) to get a hexagon is at best a hacky
use of the available tool for what the program was at its inception in
order to get the job done. It is better to proceed with being able to use
exact representations and provide alternative functions for regular
polyhedra. OpenSCAD's simplicity of scripting + an easy preview + free to
download is what makes it important to the majority of designers I think.
If development moved in the direction of utilizing the GPU core that nearly
everyone has these days, the performance would be amazing. I have a pretty
decent gaming rig that can handle the excesses of OpenSCAD's RAM usage, but
the single-threaded nature of it really holds it back. If I were a more
knowledgeable programmer I'd volunteer to get into the guts of it, but I
only have a rudimentary understanding of how to use git so far and am still
learning quite a bit. Ultimately though I need to spend time on creating 3D
designs, not the programs that create them, since that's where income is
likely to come from for me and I have a few ideas I'm only a couple steps
from being able to create using OpenSCAD as it is.
On Sat, Mar 25, 2017 at 3:09 PM, doug moen doug@moens.org wrote:
Hi David.
B-Rep means boundary representation: a shape is represented by its
boundary. OpenSCAD's mesh/polyhedron representation is a kind of B-Rep.
NURBS are another kind of boundary representation. CSG means that you
represent a shape as a tree of primitive shapes and operations on those
shapes (like boolean operations and affine transformations). OpenSCAD
evaluates a program to construct a CSG, which is then converted to a mesh
(B-Rep) using CGAL et al.
I've looked at BRL-CAD, but I encountered the same learning curve problem,
and haven't tried to use it. It seems to use CSG and two kinds of B-Rep
(NURBS and meshes) to represent shapes. I don't see any support for F-Rep.
F-Rep is functional representation. There is no explicit representation of
a shape's boundary. Instead, there is a distance function that maps every
point [x,y,z] in 3-space onto a signed distance value, which indicates the
distance of the point from the boundary of the object, and the sign
indicates whether the point is inside or outside of the object. Antimony
and ImplicitCAD use F-Rep. Although they can export STL files, they can't
directly manipulate B-Rep representations the same way OpenSCAD can.
I've read the source code for ImplicitCAD and Antimony, and I'm currently
trying to build an F-Rep geometry kernel that runs on a GPU, to see if it
will have the performance characteristics I want. F-Rep has very cheap
boolean operations, and avoids the cost of performing boolean operations on
polyhedral approximations of curved surfaces. Also, F-Rep is easy to
parallelize on a GPU. So right now it looks like a good way to achieve my
goals. Eventually, though, I'd like to extend this to an F-Rep/B-Rep hybrid
system, to make it more general purpose.
It would be difficult to integrate my work back into OpenSCAD. One problem
is that my approach represents shapes as functions, and requires a
functional language with first class function values (ie, closures), and
it's very difficult to retrofit this feature into OpenSCAD without breaking
backward compatibility. Another problem is due to the fact that I don't
convert curved surfaces into polygons before applying boolean operations
and other transformations. They remain as mathematically exact curved
surfaces. In OpenSCAD, users rely on the fact that circle, sphere and
cylinder return polygons and polyhedra, not curved shapes. Eg,
circle(r,$fn=6) is a regular hexagon. My system has circle and
regular_polygon as separate primitives. So that would be another backward
compatibility problem.
On 25 March 2017 at 16:00, David Coneff david.coneff@gmail.com wrote:
Doug,
What you're referring to is B-REP (boundary representation), and OpenSCAD
would need to be rebuilt from the ground up to do that unfortunately.
ImplicitCAD, Antimony http://www.mattkeeter.com/projects/antimony/3/,
and BRL-CAD are examples of open-source software that does that. I looked
into using them instead, but ran into roadblocks pretty immediately -
ImplicitCAD is built mainly for linux, and none of the dev's have windows
machines to test a windows build on, I tried installing it and couldn't get
it done; Antimony is built for linux and OS-X and has an experimental
windows build (haven't tried it yet); BRL-CAD is probably a great piece of
software for an experienced developer but has a very steep learning curve
since it is meant for managing very large, multi-purpose designs (e.g.,
having a full operational schematic of the parts for a tank, and being able
to both create a nice 3D rendering of it as well as CAD files of each
individual part for giving a manufacturer a dimensional specification for
an order).
Antimony http://www.mattkeeter.com/projects/antimony/3/ has the most
forward thinking GUI interface that naturally keeps track of the branching
of successive operations on an object (intersections, subtractions, locking
the relation of the dimension of a second part based on a first part,
etc.). If I had a linux OS installed or could get one to dual boot just for
using that piece of software, I would. I believe OpenSCAD's popularity
within the 3D printing community comes from the accessibility of the
documentation, ease of install without errors on every platform, and the
quick-render ability to iterate your design before doing a full render.
ImplicitCAD showed similar promise in being easy to use, but was never
developed to the level that it had the quick render / GUI apparatus to
check your design with each change you make - you'd have to run a render
from the command line and then open the generated image file which is a
rather clunky process, but since it naturally runs multi-threaded from the
ground up with implicit surfaces (B-REP), the render time is much faster
(seconds vs. minutes to hours in OpenSCAD) for relatively simple stuff like
these meshes.
If there were some developers willing to really put in the time, that
type of render engine could probably be integrated into OpenSCAD, but it
would take a lot of effort and you can't complain too much when someone
gives you software for free! I think OpenSCAD's primary usefulness is for
either generating extremely simple models, or modifying existing ones that
are imported. One example is a wire-mesh klein bottle I found on
thingiverse http://www.thingiverse.com/thing:525567 - it doesn't have
an open hole where the pipe intersects the side of the bottle, so I
imported it into OpenSCAD and did a boolean operation to cut a hole, and
added a ring to create a clean support structure for the intersection of
the pipe and the bottle. The result turned out perfect when I printed it.
While I'd like to do more complicated things with OpenSCAD, it is not
well-suited to do the more organic designs like voronoi meshes. I made a
basic wire-frame library, but since OpenSCAD doesn't like to deal with
for() loops of greater than 10,000 iterations without some great pain,
you're really better off generating mesh point sets using an external
scripting library like SolidPython if you're insistent on using OpenSCAD
for the render itself. I've done a few experiments with SolidPython, and it
is pretty good at generating the polyehdron facet sets that OpenSCAD
understands, and OpenSCAD definitely renders them much faster since it
doesn't have to do any of the successive boolean operations itself.
On Sat, Mar 25, 2017 at 11:35 AM, doug moen doug@moens.org wrote:
OpenSCAD is an awesome tool, but I don't think its design is the best
for doing George Hart style fractals, lattices, etc.
Consider Parkinbot's lattice, a union of spheres and cylinders. OpenSCAD
converts these spheres and cylinders into mesh approximations as early as
possible, and then uses a very expensive mesh-based union operator
(currently from CGAL) to perform the union. The performance and memory
consumption degrades non-linearly as $fn gets higher. That will still be
true if OpenSCAD switches to Carve.
A better approach, I think, it to represent spheres and cylinders
exactly, using a very cheap representation (origin, radius, height), and
delay the construction of the mesh until the final stage of rendering,
using high level information from the CSG tree to pick rendering strategies.
OpenSCAD is also single threaded. I think the best performance will
result from doing the rendering on the GPU, because then you can take
advantage of massive parallelism.
I'm interested in exploring these ideas within an open source project.
On 25 March 2017 at 07:14, arnholm@arnholm.org wrote:
On 2017-03-25 00:54, doug moen wrote:
Well, I think that even 23 seconds is a long time for such a trivial
construction. It really ought to be a fraction of a second.
Of course one wants everything at no cost, but that is not going to
happen. It is better to evaluate what the main factors are and what
realistically can be achieved. The number of facets is obviously one major
factor, but it isn't the only answer.
My little example showed it is possible to improve ~an order of
magnitude just by using another boolean engine. There are also other paths
to pursue, such as multi-threaded processing, which I will try at some
stage. The numbers I gave were just snapshots of current working
implementations for comparison, both single threaded.
Another thing I tried was observing memory use. I factored the
dimensions up by 2 and watched memory use. For this relatively small model,
OpenSCAD/CGAL required more than 6GB of ram (64bit), which seems hard to
justify. That alone is a major performance issue. My Carve-based engine was
never higher than 400MB ram for the same problem, so you are looking at an
order of magnitude difference there.
Carsten Arnholm
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
You're right, I mixed up some of the details between F-REP and B-REP. F-REP
definitely seems like the way to go, I'm not certain but I think Blender is
a hybrid F-REP/B-REP system - even simple things like cubes with filleted
corners that would slow down OpenSCAD's engine enormously for manipulation
in the GUI run very smoothly in Blender. It even has a terminal for running
python scripts! Only thing is, it also has an extremely steep learning
curve due to its very multi-purpose nature (animation, model production,
etc.) despite the much slicker interface and active development community
compared to BRL-CAD. I'm probably still going to invest some time in
learning that software as well since it is the fastest path to more organic
designs and creating computationally generated designs with python scripts,
but for the moment I can get more done in a day with OpenSCAD than Blender
since I spend so much time just fighting the GUI and various quirks of
Blender. Any advanced tool is bound to have those problems with a learning
curve though.
If OpenSCAD is to have F-REP as a hybrid system, there will inevitably be
some breaks in the backward compatibility, and IMO that's not something to
be avoided. The use of circle($fn=6) to get a hexagon is at best a hacky
use of the available tool for what the program was at its inception in
order to get the job done. It is better to proceed with being able to use
exact representations and provide alternative functions for regular
polyhedra. OpenSCAD's simplicity of scripting + an easy preview + free to
download is what makes it important to the majority of designers I think.
If development moved in the direction of utilizing the GPU core that nearly
everyone has these days, the performance would be amazing. I have a pretty
decent gaming rig that can handle the excesses of OpenSCAD's RAM usage, but
the single-threaded nature of it really holds it back. If I were a more
knowledgeable programmer I'd volunteer to get into the guts of it, but I
only have a rudimentary understanding of how to use git so far and am still
learning quite a bit. Ultimately though I need to spend time on creating 3D
designs, not the programs that create them, since that's where income is
likely to come from for me and I have a few ideas I'm only a couple steps
from being able to create using OpenSCAD as it is.
On Sat, Mar 25, 2017 at 3:09 PM, doug moen <doug@moens.org> wrote:
> Hi David.
>
> B-Rep means boundary representation: a shape is represented by its
> boundary. OpenSCAD's mesh/polyhedron representation is a kind of B-Rep.
> NURBS are another kind of boundary representation. CSG means that you
> represent a shape as a tree of primitive shapes and operations on those
> shapes (like boolean operations and affine transformations). OpenSCAD
> evaluates a program to construct a CSG, which is then converted to a mesh
> (B-Rep) using CGAL et al.
>
> I've looked at BRL-CAD, but I encountered the same learning curve problem,
> and haven't tried to use it. It seems to use CSG and two kinds of B-Rep
> (NURBS and meshes) to represent shapes. I don't see any support for F-Rep.
>
> F-Rep is functional representation. There is no explicit representation of
> a shape's boundary. Instead, there is a distance function that maps every
> point [x,y,z] in 3-space onto a signed distance value, which indicates the
> distance of the point from the boundary of the object, and the sign
> indicates whether the point is inside or outside of the object. Antimony
> and ImplicitCAD use F-Rep. Although they can export STL files, they can't
> directly manipulate B-Rep representations the same way OpenSCAD can.
>
> I've read the source code for ImplicitCAD and Antimony, and I'm currently
> trying to build an F-Rep geometry kernel that runs on a GPU, to see if it
> will have the performance characteristics I want. F-Rep has very cheap
> boolean operations, and avoids the cost of performing boolean operations on
> polyhedral approximations of curved surfaces. Also, F-Rep is easy to
> parallelize on a GPU. So right now it looks like a good way to achieve my
> goals. Eventually, though, I'd like to extend this to an F-Rep/B-Rep hybrid
> system, to make it more general purpose.
>
> It would be difficult to integrate my work back into OpenSCAD. One problem
> is that my approach represents shapes as functions, and requires a
> functional language with first class function values (ie, closures), and
> it's very difficult to retrofit this feature into OpenSCAD without breaking
> backward compatibility. Another problem is due to the fact that I don't
> convert curved surfaces into polygons before applying boolean operations
> and other transformations. They remain as mathematically exact curved
> surfaces. In OpenSCAD, users rely on the fact that circle, sphere and
> cylinder return polygons and polyhedra, not curved shapes. Eg,
> circle(r,$fn=6) is a regular hexagon. My system has circle and
> regular_polygon as separate primitives. So that would be another backward
> compatibility problem.
>
> On 25 March 2017 at 16:00, David Coneff <david.coneff@gmail.com> wrote:
>
>> Doug,
>>
>> What you're referring to is B-REP (boundary representation), and OpenSCAD
>> would need to be rebuilt from the ground up to do that unfortunately.
>> ImplicitCAD, Antimony <http://www.mattkeeter.com/projects/antimony/3/>,
>> and BRL-CAD are examples of open-source software that does that. I looked
>> into using them instead, but ran into roadblocks pretty immediately -
>> ImplicitCAD is built mainly for linux, and none of the dev's have windows
>> machines to test a windows build on, I tried installing it and couldn't get
>> it done; Antimony is built for linux and OS-X and has an experimental
>> windows build (haven't tried it yet); BRL-CAD is probably a great piece of
>> software for an experienced developer but has a very steep learning curve
>> since it is meant for managing very large, multi-purpose designs (e.g.,
>> having a full operational schematic of the parts for a tank, and being able
>> to both create a nice 3D rendering of it as well as CAD files of each
>> individual part for giving a manufacturer a dimensional specification for
>> an order).
>>
>> Antimony <http://www.mattkeeter.com/projects/antimony/3/> has the most
>> forward thinking GUI interface that naturally keeps track of the branching
>> of successive operations on an object (intersections, subtractions, locking
>> the relation of the dimension of a second part based on a first part,
>> etc.). If I had a linux OS installed or could get one to dual boot just for
>> using that piece of software, I would. I believe OpenSCAD's popularity
>> within the 3D printing community comes from the accessibility of the
>> documentation, ease of install without errors on every platform, and the
>> quick-render ability to iterate your design before doing a full render.
>> ImplicitCAD showed similar promise in being easy to use, but was never
>> developed to the level that it had the quick render / GUI apparatus to
>> check your design with each change you make - you'd have to run a render
>> from the command line and then open the generated image file which is a
>> rather clunky process, but since it naturally runs multi-threaded from the
>> ground up with implicit surfaces (B-REP), the render time is much faster
>> (seconds vs. minutes to hours in OpenSCAD) for relatively simple stuff like
>> these meshes.
>>
>> If there were some developers willing to really put in the time, that
>> type of render engine could probably be integrated into OpenSCAD, but it
>> would take a lot of effort and you can't complain too much when someone
>> gives you software for free! I think OpenSCAD's primary usefulness is for
>> either generating extremely simple models, or modifying existing ones that
>> are imported. One example is a wire-mesh klein bottle I found on
>> thingiverse <http://www.thingiverse.com/thing:525567> - it doesn't have
>> an open hole where the pipe intersects the side of the bottle, so I
>> imported it into OpenSCAD and did a boolean operation to cut a hole, and
>> added a ring to create a clean support structure for the intersection of
>> the pipe and the bottle. The result turned out perfect when I printed it.
>>
>> While I'd like to do more complicated things with OpenSCAD, it is not
>> well-suited to do the more organic designs like voronoi meshes. I made a
>> basic wire-frame library, but since OpenSCAD doesn't like to deal with
>> for() loops of greater than 10,000 iterations without some great pain,
>> you're really better off generating mesh point sets using an external
>> scripting library like SolidPython if you're insistent on using OpenSCAD
>> for the render itself. I've done a few experiments with SolidPython, and it
>> is pretty good at generating the polyehdron facet sets that OpenSCAD
>> understands, and OpenSCAD definitely renders them much faster since it
>> doesn't have to do any of the successive boolean operations itself.
>>
>> On Sat, Mar 25, 2017 at 11:35 AM, doug moen <doug@moens.org> wrote:
>>
>>> OpenSCAD is an awesome tool, but I don't think its design is the best
>>> for doing George Hart style fractals, lattices, etc.
>>>
>>> Consider Parkinbot's lattice, a union of spheres and cylinders. OpenSCAD
>>> converts these spheres and cylinders into mesh approximations as early as
>>> possible, and then uses a very expensive mesh-based union operator
>>> (currently from CGAL) to perform the union. The performance and memory
>>> consumption degrades non-linearly as $fn gets higher. That will still be
>>> true if OpenSCAD switches to Carve.
>>>
>>> A better approach, I think, it to represent spheres and cylinders
>>> exactly, using a very cheap representation (origin, radius, height), and
>>> delay the construction of the mesh until the final stage of rendering,
>>> using high level information from the CSG tree to pick rendering strategies.
>>>
>>> OpenSCAD is also single threaded. I think the best performance will
>>> result from doing the rendering on the GPU, because then you can take
>>> advantage of massive parallelism.
>>>
>>> I'm interested in exploring these ideas within an open source project.
>>>
>>> On 25 March 2017 at 07:14, <arnholm@arnholm.org> wrote:
>>>
>>>> On 2017-03-25 00:54, doug moen wrote:
>>>>
>>>>> Well, I think that even 23 seconds is a long time for such a trivial
>>>>> construction. It really ought to be a fraction of a second.
>>>>>
>>>>
>>>> Of course one wants everything at no cost, but that is not going to
>>>> happen. It is better to evaluate what the main factors are and what
>>>> realistically can be achieved. The number of facets is obviously one major
>>>> factor, but it isn't the only answer.
>>>>
>>>> My little example showed it is possible to improve ~an order of
>>>> magnitude just by using another boolean engine. There are also other paths
>>>> to pursue, such as multi-threaded processing, which I will try at some
>>>> stage. The numbers I gave were just snapshots of current working
>>>> implementations for comparison, both single threaded.
>>>>
>>>> Another thing I tried was observing memory use. I factored the
>>>> dimensions up by 2 and watched memory use. For this relatively small model,
>>>> OpenSCAD/CGAL required more than 6GB of ram (64bit), which seems hard to
>>>> justify. That alone is a major performance issue. My Carve-based engine was
>>>> never higher than 400MB ram for the same problem, so you are looking at an
>>>> order of magnitude difference there.
>>>>
>>>>
>>>> Carsten Arnholm
>>>>
>>>> _______________________________________________
>>>> 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
>
>
DM
doug moen
Sat, Mar 25, 2017 10:50 PM
I didn't get too far into Blender, because of the learning curve. Blender
supports Bezier curves and NURBS (aka B-Rep), either of which could be used
to represent cubes with rounded corners. However, you are correct, Blender
also supports F-Rep. At least, it has metaballs, which are F-Rep objects,
but I don't know how deep the F-Rep support goes.
On 25 March 2017 at 17:50, David Coneff david.coneff@gmail.com wrote:
You're right, I mixed up some of the details between F-REP and B-REP.
F-REP definitely seems like the way to go, I'm not certain but I think
Blender is a hybrid F-REP/B-REP system - even simple things like cubes with
filleted corners that would slow down OpenSCAD's engine enormously for
manipulation in the GUI run very smoothly in Blender. It even has a
terminal for running python scripts! Only thing is, it also has an
extremely steep learning curve due to its very multi-purpose nature
(animation, model production, etc.) despite the much slicker interface and
active development community compared to BRL-CAD. I'm probably still going
to invest some time in learning that software as well since it is the
fastest path to more organic designs and creating computationally generated
designs with python scripts, but for the moment I can get more done in a
day with OpenSCAD than Blender since I spend so much time just fighting the
GUI and various quirks of Blender. Any advanced tool is bound to have those
problems with a learning curve though.
If OpenSCAD is to have F-REP as a hybrid system, there will inevitably be
some breaks in the backward compatibility, and IMO that's not something to
be avoided. The use of circle($fn=6) to get a hexagon is at best a hacky
use of the available tool for what the program was at its inception in
order to get the job done. It is better to proceed with being able to use
exact representations and provide alternative functions for regular
polyhedra. OpenSCAD's simplicity of scripting + an easy preview + free to
download is what makes it important to the majority of designers I think.
If development moved in the direction of utilizing the GPU core that nearly
everyone has these days, the performance would be amazing. I have a pretty
decent gaming rig that can handle the excesses of OpenSCAD's RAM usage, but
the single-threaded nature of it really holds it back. If I were a more
knowledgeable programmer I'd volunteer to get into the guts of it, but I
only have a rudimentary understanding of how to use git so far and am still
learning quite a bit. Ultimately though I need to spend time on creating 3D
designs, not the programs that create them, since that's where income is
likely to come from for me and I have a few ideas I'm only a couple steps
from being able to create using OpenSCAD as it is.
On Sat, Mar 25, 2017 at 3:09 PM, doug moen doug@moens.org wrote:
Hi David.
B-Rep means boundary representation: a shape is represented by its
boundary. OpenSCAD's mesh/polyhedron representation is a kind of B-Rep.
NURBS are another kind of boundary representation. CSG means that you
represent a shape as a tree of primitive shapes and operations on those
shapes (like boolean operations and affine transformations). OpenSCAD
evaluates a program to construct a CSG, which is then converted to a mesh
(B-Rep) using CGAL et al.
I've looked at BRL-CAD, but I encountered the same learning curve
problem, and haven't tried to use it. It seems to use CSG and two kinds of
B-Rep (NURBS and meshes) to represent shapes. I don't see any support for
F-Rep.
F-Rep is functional representation. There is no explicit representation
of a shape's boundary. Instead, there is a distance function that maps
every point [x,y,z] in 3-space onto a signed distance value, which
indicates the distance of the point from the boundary of the object, and
the sign indicates whether the point is inside or outside of the object.
Antimony and ImplicitCAD use F-Rep. Although they can export STL files,
they can't directly manipulate B-Rep representations the same way OpenSCAD
can.
I've read the source code for ImplicitCAD and Antimony, and I'm currently
trying to build an F-Rep geometry kernel that runs on a GPU, to see if it
will have the performance characteristics I want. F-Rep has very cheap
boolean operations, and avoids the cost of performing boolean operations on
polyhedral approximations of curved surfaces. Also, F-Rep is easy to
parallelize on a GPU. So right now it looks like a good way to achieve my
goals. Eventually, though, I'd like to extend this to an F-Rep/B-Rep hybrid
system, to make it more general purpose.
It would be difficult to integrate my work back into OpenSCAD. One
problem is that my approach represents shapes as functions, and requires a
functional language with first class function values (ie, closures), and
it's very difficult to retrofit this feature into OpenSCAD without breaking
backward compatibility. Another problem is due to the fact that I don't
convert curved surfaces into polygons before applying boolean operations
and other transformations. They remain as mathematically exact curved
surfaces. In OpenSCAD, users rely on the fact that circle, sphere and
cylinder return polygons and polyhedra, not curved shapes. Eg,
circle(r,$fn=6) is a regular hexagon. My system has circle and
regular_polygon as separate primitives. So that would be another backward
compatibility problem.
On 25 March 2017 at 16:00, David Coneff david.coneff@gmail.com wrote:
Doug,
What you're referring to is B-REP (boundary representation), and
OpenSCAD would need to be rebuilt from the ground up to do that
unfortunately. ImplicitCAD, Antimony
http://www.mattkeeter.com/projects/antimony/3/, and BRL-CAD are
examples of open-source software that does that. I looked into using them
instead, but ran into roadblocks pretty immediately - ImplicitCAD is built
mainly for linux, and none of the dev's have windows machines to test a
windows build on, I tried installing it and couldn't get it done; Antimony
is built for linux and OS-X and has an experimental windows build (haven't
tried it yet); BRL-CAD is probably a great piece of software for an
experienced developer but has a very steep learning curve since it is meant
for managing very large, multi-purpose designs (e.g., having a full
operational schematic of the parts for a tank, and being able to both
create a nice 3D rendering of it as well as CAD files of each individual
part for giving a manufacturer a dimensional specification for an order).
Antimony http://www.mattkeeter.com/projects/antimony/3/ has the most
forward thinking GUI interface that naturally keeps track of the branching
of successive operations on an object (intersections, subtractions, locking
the relation of the dimension of a second part based on a first part,
etc.). If I had a linux OS installed or could get one to dual boot just for
using that piece of software, I would. I believe OpenSCAD's popularity
within the 3D printing community comes from the accessibility of the
documentation, ease of install without errors on every platform, and the
quick-render ability to iterate your design before doing a full render.
ImplicitCAD showed similar promise in being easy to use, but was never
developed to the level that it had the quick render / GUI apparatus to
check your design with each change you make - you'd have to run a render
from the command line and then open the generated image file which is a
rather clunky process, but since it naturally runs multi-threaded from the
ground up with implicit surfaces (B-REP), the render time is much faster
(seconds vs. minutes to hours in OpenSCAD) for relatively simple stuff like
these meshes.
If there were some developers willing to really put in the time, that
type of render engine could probably be integrated into OpenSCAD, but it
would take a lot of effort and you can't complain too much when someone
gives you software for free! I think OpenSCAD's primary usefulness is for
either generating extremely simple models, or modifying existing ones that
are imported. One example is a wire-mesh klein bottle I found on
thingiverse http://www.thingiverse.com/thing:525567 - it doesn't have
an open hole where the pipe intersects the side of the bottle, so I
imported it into OpenSCAD and did a boolean operation to cut a hole, and
added a ring to create a clean support structure for the intersection of
the pipe and the bottle. The result turned out perfect when I printed it.
While I'd like to do more complicated things with OpenSCAD, it is not
well-suited to do the more organic designs like voronoi meshes. I made a
basic wire-frame library, but since OpenSCAD doesn't like to deal with
for() loops of greater than 10,000 iterations without some great pain,
you're really better off generating mesh point sets using an external
scripting library like SolidPython if you're insistent on using OpenSCAD
for the render itself. I've done a few experiments with SolidPython, and it
is pretty good at generating the polyehdron facet sets that OpenSCAD
understands, and OpenSCAD definitely renders them much faster since it
doesn't have to do any of the successive boolean operations itself.
On Sat, Mar 25, 2017 at 11:35 AM, doug moen doug@moens.org wrote:
OpenSCAD is an awesome tool, but I don't think its design is the best
for doing George Hart style fractals, lattices, etc.
Consider Parkinbot's lattice, a union of spheres and cylinders.
OpenSCAD converts these spheres and cylinders into mesh approximations as
early as possible, and then uses a very expensive mesh-based union operator
(currently from CGAL) to perform the union. The performance and memory
consumption degrades non-linearly as $fn gets higher. That will still be
true if OpenSCAD switches to Carve.
A better approach, I think, it to represent spheres and cylinders
exactly, using a very cheap representation (origin, radius, height), and
delay the construction of the mesh until the final stage of rendering,
using high level information from the CSG tree to pick rendering strategies.
OpenSCAD is also single threaded. I think the best performance will
result from doing the rendering on the GPU, because then you can take
advantage of massive parallelism.
I'm interested in exploring these ideas within an open source project.
On 25 March 2017 at 07:14, arnholm@arnholm.org wrote:
On 2017-03-25 00:54, doug moen wrote:
Well, I think that even 23 seconds is a long time for such a trivial
construction. It really ought to be a fraction of a second.
Of course one wants everything at no cost, but that is not going to
happen. It is better to evaluate what the main factors are and what
realistically can be achieved. The number of facets is obviously one major
factor, but it isn't the only answer.
My little example showed it is possible to improve ~an order of
magnitude just by using another boolean engine. There are also other paths
to pursue, such as multi-threaded processing, which I will try at some
stage. The numbers I gave were just snapshots of current working
implementations for comparison, both single threaded.
Another thing I tried was observing memory use. I factored the
dimensions up by 2 and watched memory use. For this relatively small model,
OpenSCAD/CGAL required more than 6GB of ram (64bit), which seems hard to
justify. That alone is a major performance issue. My Carve-based engine was
never higher than 400MB ram for the same problem, so you are looking at an
order of magnitude difference there.
Carsten Arnholm
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
I didn't get too far into Blender, because of the learning curve. Blender
supports Bezier curves and NURBS (aka B-Rep), either of which could be used
to represent cubes with rounded corners. However, you are correct, Blender
also supports F-Rep. At least, it has metaballs, which are F-Rep objects,
but I don't know how deep the F-Rep support goes.
On 25 March 2017 at 17:50, David Coneff <david.coneff@gmail.com> wrote:
> You're right, I mixed up some of the details between F-REP and B-REP.
> F-REP definitely seems like the way to go, I'm not certain but I think
> Blender is a hybrid F-REP/B-REP system - even simple things like cubes with
> filleted corners that would slow down OpenSCAD's engine enormously for
> manipulation in the GUI run very smoothly in Blender. It even has a
> terminal for running python scripts! Only thing is, it also has an
> extremely steep learning curve due to its very multi-purpose nature
> (animation, model production, etc.) despite the much slicker interface and
> active development community compared to BRL-CAD. I'm probably still going
> to invest some time in learning that software as well since it is the
> fastest path to more organic designs and creating computationally generated
> designs with python scripts, but for the moment I can get more done in a
> day with OpenSCAD than Blender since I spend so much time just fighting the
> GUI and various quirks of Blender. Any advanced tool is bound to have those
> problems with a learning curve though.
>
> If OpenSCAD is to have F-REP as a hybrid system, there will inevitably be
> some breaks in the backward compatibility, and IMO that's not something to
> be avoided. The use of circle($fn=6) to get a hexagon is at best a hacky
> use of the available tool for what the program was at its inception in
> order to get the job done. It is better to proceed with being able to use
> exact representations and provide alternative functions for regular
> polyhedra. OpenSCAD's simplicity of scripting + an easy preview + free to
> download is what makes it important to the majority of designers I think.
> If development moved in the direction of utilizing the GPU core that nearly
> everyone has these days, the performance would be amazing. I have a pretty
> decent gaming rig that can handle the excesses of OpenSCAD's RAM usage, but
> the single-threaded nature of it really holds it back. If I were a more
> knowledgeable programmer I'd volunteer to get into the guts of it, but I
> only have a rudimentary understanding of how to use git so far and am still
> learning quite a bit. Ultimately though I need to spend time on creating 3D
> designs, not the programs that create them, since that's where income is
> likely to come from for me and I have a few ideas I'm only a couple steps
> from being able to create using OpenSCAD as it is.
>
> On Sat, Mar 25, 2017 at 3:09 PM, doug moen <doug@moens.org> wrote:
>
>> Hi David.
>>
>> B-Rep means boundary representation: a shape is represented by its
>> boundary. OpenSCAD's mesh/polyhedron representation is a kind of B-Rep.
>> NURBS are another kind of boundary representation. CSG means that you
>> represent a shape as a tree of primitive shapes and operations on those
>> shapes (like boolean operations and affine transformations). OpenSCAD
>> evaluates a program to construct a CSG, which is then converted to a mesh
>> (B-Rep) using CGAL et al.
>>
>> I've looked at BRL-CAD, but I encountered the same learning curve
>> problem, and haven't tried to use it. It seems to use CSG and two kinds of
>> B-Rep (NURBS and meshes) to represent shapes. I don't see any support for
>> F-Rep.
>>
>> F-Rep is functional representation. There is no explicit representation
>> of a shape's boundary. Instead, there is a distance function that maps
>> every point [x,y,z] in 3-space onto a signed distance value, which
>> indicates the distance of the point from the boundary of the object, and
>> the sign indicates whether the point is inside or outside of the object.
>> Antimony and ImplicitCAD use F-Rep. Although they can export STL files,
>> they can't directly manipulate B-Rep representations the same way OpenSCAD
>> can.
>>
>> I've read the source code for ImplicitCAD and Antimony, and I'm currently
>> trying to build an F-Rep geometry kernel that runs on a GPU, to see if it
>> will have the performance characteristics I want. F-Rep has very cheap
>> boolean operations, and avoids the cost of performing boolean operations on
>> polyhedral approximations of curved surfaces. Also, F-Rep is easy to
>> parallelize on a GPU. So right now it looks like a good way to achieve my
>> goals. Eventually, though, I'd like to extend this to an F-Rep/B-Rep hybrid
>> system, to make it more general purpose.
>>
>> It would be difficult to integrate my work back into OpenSCAD. One
>> problem is that my approach represents shapes as functions, and requires a
>> functional language with first class function values (ie, closures), and
>> it's very difficult to retrofit this feature into OpenSCAD without breaking
>> backward compatibility. Another problem is due to the fact that I don't
>> convert curved surfaces into polygons before applying boolean operations
>> and other transformations. They remain as mathematically exact curved
>> surfaces. In OpenSCAD, users rely on the fact that circle, sphere and
>> cylinder return polygons and polyhedra, not curved shapes. Eg,
>> circle(r,$fn=6) is a regular hexagon. My system has circle and
>> regular_polygon as separate primitives. So that would be another backward
>> compatibility problem.
>>
>> On 25 March 2017 at 16:00, David Coneff <david.coneff@gmail.com> wrote:
>>
>>> Doug,
>>>
>>> What you're referring to is B-REP (boundary representation), and
>>> OpenSCAD would need to be rebuilt from the ground up to do that
>>> unfortunately. ImplicitCAD, Antimony
>>> <http://www.mattkeeter.com/projects/antimony/3/>, and BRL-CAD are
>>> examples of open-source software that does that. I looked into using them
>>> instead, but ran into roadblocks pretty immediately - ImplicitCAD is built
>>> mainly for linux, and none of the dev's have windows machines to test a
>>> windows build on, I tried installing it and couldn't get it done; Antimony
>>> is built for linux and OS-X and has an experimental windows build (haven't
>>> tried it yet); BRL-CAD is probably a great piece of software for an
>>> experienced developer but has a very steep learning curve since it is meant
>>> for managing very large, multi-purpose designs (e.g., having a full
>>> operational schematic of the parts for a tank, and being able to both
>>> create a nice 3D rendering of it as well as CAD files of each individual
>>> part for giving a manufacturer a dimensional specification for an order).
>>>
>>> Antimony <http://www.mattkeeter.com/projects/antimony/3/> has the most
>>> forward thinking GUI interface that naturally keeps track of the branching
>>> of successive operations on an object (intersections, subtractions, locking
>>> the relation of the dimension of a second part based on a first part,
>>> etc.). If I had a linux OS installed or could get one to dual boot just for
>>> using that piece of software, I would. I believe OpenSCAD's popularity
>>> within the 3D printing community comes from the accessibility of the
>>> documentation, ease of install without errors on every platform, and the
>>> quick-render ability to iterate your design before doing a full render.
>>> ImplicitCAD showed similar promise in being easy to use, but was never
>>> developed to the level that it had the quick render / GUI apparatus to
>>> check your design with each change you make - you'd have to run a render
>>> from the command line and then open the generated image file which is a
>>> rather clunky process, but since it naturally runs multi-threaded from the
>>> ground up with implicit surfaces (B-REP), the render time is much faster
>>> (seconds vs. minutes to hours in OpenSCAD) for relatively simple stuff like
>>> these meshes.
>>>
>>> If there were some developers willing to really put in the time, that
>>> type of render engine could probably be integrated into OpenSCAD, but it
>>> would take a lot of effort and you can't complain too much when someone
>>> gives you software for free! I think OpenSCAD's primary usefulness is for
>>> either generating extremely simple models, or modifying existing ones that
>>> are imported. One example is a wire-mesh klein bottle I found on
>>> thingiverse <http://www.thingiverse.com/thing:525567> - it doesn't have
>>> an open hole where the pipe intersects the side of the bottle, so I
>>> imported it into OpenSCAD and did a boolean operation to cut a hole, and
>>> added a ring to create a clean support structure for the intersection of
>>> the pipe and the bottle. The result turned out perfect when I printed it.
>>>
>>> While I'd like to do more complicated things with OpenSCAD, it is not
>>> well-suited to do the more organic designs like voronoi meshes. I made a
>>> basic wire-frame library, but since OpenSCAD doesn't like to deal with
>>> for() loops of greater than 10,000 iterations without some great pain,
>>> you're really better off generating mesh point sets using an external
>>> scripting library like SolidPython if you're insistent on using OpenSCAD
>>> for the render itself. I've done a few experiments with SolidPython, and it
>>> is pretty good at generating the polyehdron facet sets that OpenSCAD
>>> understands, and OpenSCAD definitely renders them much faster since it
>>> doesn't have to do any of the successive boolean operations itself.
>>>
>>> On Sat, Mar 25, 2017 at 11:35 AM, doug moen <doug@moens.org> wrote:
>>>
>>>> OpenSCAD is an awesome tool, but I don't think its design is the best
>>>> for doing George Hart style fractals, lattices, etc.
>>>>
>>>> Consider Parkinbot's lattice, a union of spheres and cylinders.
>>>> OpenSCAD converts these spheres and cylinders into mesh approximations as
>>>> early as possible, and then uses a very expensive mesh-based union operator
>>>> (currently from CGAL) to perform the union. The performance and memory
>>>> consumption degrades non-linearly as $fn gets higher. That will still be
>>>> true if OpenSCAD switches to Carve.
>>>>
>>>> A better approach, I think, it to represent spheres and cylinders
>>>> exactly, using a very cheap representation (origin, radius, height), and
>>>> delay the construction of the mesh until the final stage of rendering,
>>>> using high level information from the CSG tree to pick rendering strategies.
>>>>
>>>> OpenSCAD is also single threaded. I think the best performance will
>>>> result from doing the rendering on the GPU, because then you can take
>>>> advantage of massive parallelism.
>>>>
>>>> I'm interested in exploring these ideas within an open source project.
>>>>
>>>> On 25 March 2017 at 07:14, <arnholm@arnholm.org> wrote:
>>>>
>>>>> On 2017-03-25 00:54, doug moen wrote:
>>>>>
>>>>>> Well, I think that even 23 seconds is a long time for such a trivial
>>>>>> construction. It really ought to be a fraction of a second.
>>>>>>
>>>>>
>>>>> Of course one wants everything at no cost, but that is not going to
>>>>> happen. It is better to evaluate what the main factors are and what
>>>>> realistically can be achieved. The number of facets is obviously one major
>>>>> factor, but it isn't the only answer.
>>>>>
>>>>> My little example showed it is possible to improve ~an order of
>>>>> magnitude just by using another boolean engine. There are also other paths
>>>>> to pursue, such as multi-threaded processing, which I will try at some
>>>>> stage. The numbers I gave were just snapshots of current working
>>>>> implementations for comparison, both single threaded.
>>>>>
>>>>> Another thing I tried was observing memory use. I factored the
>>>>> dimensions up by 2 and watched memory use. For this relatively small model,
>>>>> OpenSCAD/CGAL required more than 6GB of ram (64bit), which seems hard to
>>>>> justify. That alone is a major performance issue. My Carve-based engine was
>>>>> never higher than 400MB ram for the same problem, so you are looking at an
>>>>> order of magnitude difference there.
>>>>>
>>>>>
>>>>> Carsten Arnholm
>>>>>
>>>>> _______________________________________________
>>>>> 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
>
>
RP
Ronaldo Persiano
Sat, Mar 25, 2017 10:55 PM
I agree that F-rep is a good way to go. I have implemented a F-rep
evaluation system a few months ago written in OpenSCAD language and have
found how easy is to define not only the boolean operators as other
geometric operators like twist and even solid sweep. But I have faced its
drawbacks too. The main one is the absolute necessity of a feature
detection algorithm (I have not implemented none) which is not easy. Even
Hyperfun which has a worldwide development team has no feature detection
yet. Without feature detection all solid edges seems roughly blended even
if you refine the evaluation grid a lot.
Another issue is the apparent lack of a robust convex hull and minkowsky
algorithms for F-rep. And there is another issue I found trying to model
the intersection of a sphere and a paraboloid: the primitive function
scale. If a primitive function f() is multiplied by a constant the
corresponding solid is not changed as its is the set of points p such
f(p)>=0. But when the primitive is intercepted with another one (the min of
two functions) the relative scale of the two functions matters and the
intersection polygonalization may show very noticeable artifacts. I
observed this issue in my system and were able to reproduce it in Hyperfun.
Anyway, despite those issues I am a big enthusiast of F-rep.
2017-03-25 18:09 GMT-03:00 doug moen doug@moens.org:
Hi David.
B-Rep means boundary representation: a shape is represented by its
boundary. OpenSCAD's mesh/polyhedron representation is a kind of B-Rep.
NURBS are another kind of boundary representation. CSG means that you
represent a shape as a tree of primitive shapes and operations on those
shapes (like boolean operations and affine transformations). OpenSCAD
evaluates a program to construct a CSG, which is then converted to a mesh
(B-Rep) using CGAL et al.
I've looked at BRL-CAD, but I encountered the same learning curve problem,
and haven't tried to use it. It seems to use CSG and two kinds of B-Rep
(NURBS and meshes) to represent shapes. I don't see any support for F-Rep.
F-Rep is functional representation. There is no explicit representation of
a shape's boundary. Instead, there is a distance function that maps every
point [x,y,z] in 3-space onto a signed distance value, which indicates the
distance of the point from the boundary of the object, and the sign
indicates whether the point is inside or outside of the object. Antimony
and ImplicitCAD use F-Rep. Although they can export STL files, they can't
directly manipulate B-Rep representations the same way OpenSCAD can.
I've read the source code for ImplicitCAD and Antimony, and I'm currently
trying to build an F-Rep geometry kernel that runs on a GPU, to see if it
will have the performance characteristics I want. F-Rep has very cheap
boolean operations, and avoids the cost of performing boolean operations on
polyhedral approximations of curved surfaces. Also, F-Rep is easy to
parallelize on a GPU. So right now it looks like a good way to achieve my
goals. Eventually, though, I'd like to extend this to an F-Rep/B-Rep hybrid
system, to make it more general purpose.
It would be difficult to integrate my work back into OpenSCAD. One problem
is that my approach represents shapes as functions, and requires a
functional language with first class function values (ie, closures), and
it's very difficult to retrofit this feature into OpenSCAD without breaking
backward compatibility. Another problem is due to the fact that I don't
convert curved surfaces into polygons before applying boolean operations
and other transformations. They remain as mathematically exact curved
surfaces. In OpenSCAD, users rely on the fact that circle, sphere and
cylinder return polygons and polyhedra, not curved shapes. Eg,
circle(r,$fn=6) is a regular hexagon. My system has circle and
regular_polygon as separate primitives. So that would be another backward
compatibility problem.
I agree that F-rep is a good way to go. I have implemented a F-rep
evaluation system a few months ago written in OpenSCAD language and have
found how easy is to define not only the boolean operators as other
geometric operators like twist and even solid sweep. But I have faced its
drawbacks too. The main one is the absolute necessity of a feature
detection algorithm (I have not implemented none) which is not easy. Even
Hyperfun which has a worldwide development team has no feature detection
yet. Without feature detection all solid edges seems roughly blended even
if you refine the evaluation grid a lot.
Another issue is the apparent lack of a robust convex hull and minkowsky
algorithms for F-rep. And there is another issue I found trying to model
the intersection of a sphere and a paraboloid: the primitive function
scale. If a primitive function f() is multiplied by a constant the
corresponding solid is not changed as its is the set of points p such
f(p)>=0. But when the primitive is intercepted with another one (the min of
two functions) the relative scale of the two functions matters and the
intersection polygonalization may show very noticeable artifacts. I
observed this issue in my system and were able to reproduce it in Hyperfun.
Anyway, despite those issues I am a big enthusiast of F-rep.
2017-03-25 18:09 GMT-03:00 doug moen <doug@moens.org>:
> Hi David.
>
> B-Rep means boundary representation: a shape is represented by its
> boundary. OpenSCAD's mesh/polyhedron representation is a kind of B-Rep.
> NURBS are another kind of boundary representation. CSG means that you
> represent a shape as a tree of primitive shapes and operations on those
> shapes (like boolean operations and affine transformations). OpenSCAD
> evaluates a program to construct a CSG, which is then converted to a mesh
> (B-Rep) using CGAL et al.
>
> I've looked at BRL-CAD, but I encountered the same learning curve problem,
> and haven't tried to use it. It seems to use CSG and two kinds of B-Rep
> (NURBS and meshes) to represent shapes. I don't see any support for F-Rep.
>
> F-Rep is functional representation. There is no explicit representation of
> a shape's boundary. Instead, there is a distance function that maps every
> point [x,y,z] in 3-space onto a signed distance value, which indicates the
> distance of the point from the boundary of the object, and the sign
> indicates whether the point is inside or outside of the object. Antimony
> and ImplicitCAD use F-Rep. Although they can export STL files, they can't
> directly manipulate B-Rep representations the same way OpenSCAD can.
>
> I've read the source code for ImplicitCAD and Antimony, and I'm currently
> trying to build an F-Rep geometry kernel that runs on a GPU, to see if it
> will have the performance characteristics I want. F-Rep has very cheap
> boolean operations, and avoids the cost of performing boolean operations on
> polyhedral approximations of curved surfaces. Also, F-Rep is easy to
> parallelize on a GPU. So right now it looks like a good way to achieve my
> goals. Eventually, though, I'd like to extend this to an F-Rep/B-Rep hybrid
> system, to make it more general purpose.
>
> It would be difficult to integrate my work back into OpenSCAD. One problem
> is that my approach represents shapes as functions, and requires a
> functional language with first class function values (ie, closures), and
> it's very difficult to retrofit this feature into OpenSCAD without breaking
> backward compatibility. Another problem is due to the fact that I don't
> convert curved surfaces into polygons before applying boolean operations
> and other transformations. They remain as mathematically exact curved
> surfaces. In OpenSCAD, users rely on the fact that circle, sphere and
> cylinder return polygons and polyhedra, not curved shapes. Eg,
> circle(r,$fn=6) is a regular hexagon. My system has circle and
> regular_polygon as separate primitives. So that would be another backward
> compatibility problem.
>
>
>
P
Parkinbot
Sat, Mar 25, 2017 11:11 PM
Sorry, I somehow replied to the wrong post. My answer was addressed at the 2D
approach of Ronaldo. But Dough perfectly explained my arguments. Thanks.
jon_bondy wrote
I am not sure what "That is exactly the point" means, Parkinbot. I
reviewed the thread, and was still unclear. A number of points were
made in the thread. Exactly what is it that your example, below,
demonstrates, please.
Sorry, I somehow replied to the wrong post. My answer was addressed at the 2D
approach of Ronaldo. But Dough perfectly explained my arguments. Thanks.
jon_bondy wrote
> I am not sure what "That is exactly the point" means, Parkinbot. I
> reviewed the thread, and was still unclear. A number of points were
> made in the thread. Exactly what is it that your example, below,
> demonstrates, please.
--
View this message in context: http://forum.openscad.org/Lattice-structure-tp21001p21038.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
N
noil
Sun, Mar 26, 2017 12:03 PM
I don't think, that is the main problem.
Even for the amount of faces CGAL does render it often takes way longer,
than it should.
Is it possible, that it renders on the CPU?
nophead wrote
Sorry typed the opposite of what I meant.
I don't think it would be too hard to speed up CGAL by many orders of
magnitude, but that may be naive. It obviously doesn't make any attempt to
skip the facets that need no modification in a union, which is often all
of
them.
I don't think, that is the main problem.
Even for the amount of faces CGAL does render it often takes way longer,
than it should.
Is it possible, that it renders on the CPU?
nophead wrote
> Sorry typed the opposite of what I meant.
>
>
> I don't think it would be too hard to speed up CGAL by many orders of
> magnitude, but that may be naive. It obviously doesn't make any attempt to
> skip the facets that need no modification in a union, which is often all
> of
> them.
--
View this message in context: http://forum.openscad.org/Lattice-structure-tp21001p21039.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
NH
nop head
Sun, Mar 26, 2017 12:46 PM
No I don't think CGAL does any actual rendering of pixels. It just
calculates the geometry using the CPU. After that OpenSCAD can render the
results to screen very quickly using OpenCG and your graphics card. When
you pan around with the mouse after F6 it is faster than after F5.
On 26 March 2017 at 13:03, noil noil@gmx.net wrote:
I don't think, that is the main problem.
Even for the amount of faces CGAL does render it often takes way longer,
than it should.
Is it possible, that it renders on the CPU?
nophead wrote
Sorry typed the opposite of what I meant.
I don't think it would be too hard to speed up CGAL by many orders of
magnitude, but that may be naive. It obviously doesn't make any attempt
skip the facets that need no modification in a union, which is often all
of
them.
No I don't think CGAL does any actual rendering of pixels. It just
calculates the geometry using the CPU. After that OpenSCAD can render the
results to screen very quickly using OpenCG and your graphics card. When
you pan around with the mouse after F6 it is faster than after F5.
On 26 March 2017 at 13:03, noil <noil@gmx.net> wrote:
> I don't think, that is the main problem.
> Even for the amount of faces CGAL does render it often takes way longer,
> than it should.
> Is it possible, that it renders on the CPU?
>
>
> nophead wrote
> > Sorry typed the opposite of what I meant.
> >
> >
> > I don't think it would be too hard to speed up CGAL by many orders of
> > magnitude, but that may be naive. It obviously doesn't make any attempt
> to
> > skip the facets that need no modification in a union, which is often all
> > of
> > them.
>
>
>
>
>
> --
> View this message in context: http://forum.openscad.org/Lattice-structure-
> tp21001p21039.html
> Sent from the OpenSCAD mailing list archive at Nabble.com.
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
