The license is GPL compatible, I checked that on gnu.org. On Thursday, 26 November 2015, Tim Hawkins <tim.thawkins@gmail.com> wrote: > Also you need to decide if the license is acceptable, it uses the Mozia > Public License, which is a mashup of the BSD License and the GPL V2 > License. > > On Fri, Nov 27, 2015, 12:29 doug moen <doug@moens.org > <javascript:_e(%7B%7D,'cvml','doug@moens.org');>> wrote: > >> It looks interesting. >> >> It does have CSG operations. While reading about voxel based systems, I >> found a claim that CSG is slow on voxel systems, compared to mesh systems, >> and I found a forum post complaining about the speed of CSG operations in >> OpenVDB. So this might not solve our speed problems with CGAL. >> >> I didn't find any operations for convex hull or minkowski sum. It's not >> obvious how you implement these without converting to a mesh first, which I >> bet is slow. >> >> It is described as a visual effects library, and the home page demos >> effects like clouds, fog, dust clouds, particle based fluid simulations. If >> this is the focus, then I'm not sure it will be efficient for our use >> cases. We could try it and do some performance measurements. >> >> I wonder what kind of 3D modelling operations are enabled by a voxel >> engine, stuff that's difficult with our current mesh engine? >> >> On 26 November 2015 at 22:16, Tim Hawkins <tim.thawkins@gmail.com >> <javascript:_e(%7B%7D,'cvml','tim.thawkins@gmail.com');>> wrote: >> >>> http://www.openvdb.org >>> >>> This may not be what you are looking for but its worth considering. >>> >>> It is a voxel based csg tree system with mesh import and export. You >>> create shapes as voxel grids and then it can perform csg operations on >>> them, it uses a sparse storage mechanism so its effectivly only storing the >>> surface voxels amd thier relationships. >>> >>> On Fri, Nov 27, 2015, 07:40 doug moen <doug@moens.org >>> <javascript:_e(%7B%7D,'cvml','doug@moens.org');>> wrote: >>> >>>> Yes, but the "Eigen data constructs" (I don't understand this yet) use >>>> floating point representation, and the conversion from CGAL to native >>>> representation can result in an invalid mesh. This is mentioned in the >>>> tutorial. Therefore, I don't see how we can use this: it's not robust. >>>> >>>> What I think we want is a robust CSG geometry engine that works with >>>> floating point meshes. This is extremely difficult to program correctly, >>>> because you have to repair damage to the mesh caused by transformations, >>>> deal with floating point instability, and so on, and there are a lot of >>>> tricky edge cases. I'd be looking for a well-exercised engine with about 20 >>>> years worth of development and maintenance, and definitely not a >>>> single-person project with only a year or two of work done. >>>> >>>> On 26 November 2015 at 17:43, Andrew Plumb <andrew@plumb.org >>>> <javascript:_e(%7B%7D,'cvml','andrew@plumb.org');>> wrote: >>>> >>>>> Ah, so it does: >>>>> >>>>> >>>>> https://github.com/libigl/libigl/blob/master/tutorial/609_Boolean/main.cpp >>>>> >>>>> >>>>> https://github.com/libigl/libigl/blob/master/include/igl/copyleft/boolean/mesh_boolean.cpp >>>>> >>>>> On the plus side, looks like the meshes going into the operations and >>>>> coming out are Eigen data constructs, so it may be easier to parallelize >>>>> the operations and faster non-CSG mesh transforms (translate, rotate, etc.). >>>>> >>>>> Something to play with… >>>>> >>>>> Andrew. >>>>> >>>>> On Nov 26, 2015, at 3:51 PM, doug moen <doug@moens.org >>>>> <javascript:_e(%7B%7D,'cvml','doug@moens.org');>> wrote: >>>>> >>>>> This appears to use CGAL and Cork to implement boolean operations. >>>>> https://github.com/gilbo/cork >>>>> >>>>> They mention that Cork is available as an alternative: it is faster, >>>>> but not always robust. >>>>> >>>>> On 26 November 2015 at 15:38, clothbot <andrew@plumb.org >>>>> <javascript:_e(%7B%7D,'cvml','andrew@plumb.org');>> wrote: >>>>> >>>>>> Hey Everyone, >>>>>> >>>>>> Has anyone looked into using libigl as a (partial) CGAL replacement >>>>>> for 3D >>>>>> boolean op's and mesh manipulations? >>>>>> >>>>>> http://libigl.github.io/libigl/ >>>>>> >>>>>> https://github.com/libigl/libigl >>>>>> >>>>>> http://www.alecjacobson.com/weblog/?tag=libigl >>>>>> >>>>>> Looks to be quite powerful! >>>>>> >>>>>> Andrew. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> View this message in context: >>>>>> http://forum.openscad.org/libigl-anyone-poked-at-it-for-CGAL-partial-replacement-tp14769.html >>>>>> Sent from the OpenSCAD mailing list archive at Nabble.com >>>>>> <http://nabble.com>. >>>>>> >>>>>> _______________________________________________ >>>>>> OpenSCAD mailing list >>>>>> Discuss@lists.openscad.org >>>>>> <javascript:_e(%7B%7D,'cvml','Discuss@lists.openscad.org');> >>>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> OpenSCAD mailing list >>>>> Discuss@lists.openscad.org >>>>> <javascript:_e(%7B%7D,'cvml','Discuss@lists.openscad.org');> >>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>> >>>>> >>>>> -- >>>>> >>>>> "The future is already here. It's just not very evenly distributed" >>>>> -- William Gibson >>>>> >>>>> Me: http://clothbot.com/wiki/ >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OpenSCAD mailing list >>>>> Discuss@lists.openscad.org >>>>> <javascript:_e(%7B%7D,'cvml','Discuss@lists.openscad.org');> >>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>> >>>>> >>>> _______________________________________________ >>>> OpenSCAD mailing list >>>> Discuss@lists.openscad.org >>>> <javascript:_e(%7B%7D,'cvml','Discuss@lists.openscad.org');> >>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>> >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org >>> <javascript:_e(%7B%7D,'cvml','Discuss@lists.openscad.org');> >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >>> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> <javascript:_e(%7B%7D,'cvml','Discuss@lists.openscad.org');> >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> >

Thinking out-loud more than anything else, I'm curious of what OpenVDB might bring to the table in the way of multi-material (discrete and mixed), variable-density and/or texture and colour support. The stuff that the AMF file format hints at supporting but toolset support doesn't quite exist for yet. As it relates to OpenSCAD, I suspect it may be a case of us still needing CGAL, but compartmentalizing/threading its use. Taking a voxel-mesh-cgal-mesh-voxel path may be cleaner w.r.t. not breaking on the final mesh-STL export stage because it's voxel-STL. Gotta pick our battles. :-) doug.moen wrote > It looks interesting. > > It does have CSG operations. While reading about voxel based systems, I > found a claim that CSG is slow on voxel systems, compared to mesh systems, > and I found a forum post complaining about the speed of CSG operations in > OpenVDB. So this might not solve our speed problems with CGAL. > > I didn't find any operations for convex hull or minkowski sum. It's not > obvious how you implement these without converting to a mesh first, which > I > bet is slow. > > It is described as a visual effects library, and the home page demos > effects like clouds, fog, dust clouds, particle based fluid simulations. > If > this is the focus, then I'm not sure it will be efficient for our use > cases. We could try it and do some performance measurements. > > I wonder what kind of 3D modelling operations are enabled by a voxel > engine, stuff that's difficult with our current mesh engine? -- View this message in context: http://forum.openscad.org/libigl-anyone-poked-at-it-for-CGAL-partial-replacement-tp14769p14793.html Sent from the OpenSCAD mailing list archive at Nabble.com.

If you want to read about a voxel based solid modelling language written in JavaScript, check out ShapeJS. http://shapejs.shapeways.com/getting-started It is built on top of very powerful primitive operations. You can specify an arbitrary 3d shape by a function that maps each coordinate in the voxel grid to a signed distance. The CSG operations are available for composing objects. You can specify an arbitrary non affine transformation using a function, as proposed by Trygon. But I bet they don't support convex hull. You need to identify the vertexes in order to compute this, and that's not easily done with a voxel representation. It seems to me that we would need to design a hybrid system supporting a mixture of mesh and voxel representations if we wanted to extend openscad with voxel support, while retaining full backward compatibility. On Thursday, 26 November 2015, Tim Hawkins <tim.thawkins@gmail.com> wrote: > It does claim to be multithreaded, which i can belive as voxel operations > are easy to partition, i dont claim to have any expertice in this, my > graphics abilities are limited to 2d, i used to write postscript > rasterisation engines, which render down to a trapezoid list which is easy > to slice and hand out to different threads for operations like colour > correction and halftoning. > > Given it does work on a different set of principles there will be > operations that are missing or sub optimimal, like wise there will be > aspects that are faster and open up new capabilities, its just a case of > determining what the tradeoffs are. > > On Fri, Nov 27, 2015, 12:29 doug moen <doug@moens.org > <javascript:_e(%7B%7D,'cvml','doug@moens.org');>> wrote: > >> It looks interesting. >> >> It does have CSG operations. While reading about voxel based systems, I >> found a claim that CSG is slow on voxel systems, compared to mesh systems, >> and I found a forum post complaining about the speed of CSG operations in >> OpenVDB. So this might not solve our speed problems with CGAL. >> >> I didn't find any operations for convex hull or minkowski sum. It's not >> obvious how you implement these without converting to a mesh first, which I >> bet is slow. >> >> It is described as a visual effects library, and the home page demos >> effects like clouds, fog, dust clouds, particle based fluid simulations. If >> this is the focus, then I'm not sure it will be efficient for our use >> cases. We could try it and do some performance measurements. >> >> I wonder what kind of 3D modelling operations are enabled by a voxel >> engine, stuff that's difficult with our current mesh engine? >> >> On 26 November 2015 at 22:16, Tim Hawkins <tim.thawkins@gmail.com >> <javascript:_e(%7B%7D,'cvml','tim.thawkins@gmail.com');>> wrote: >> >>> http://www.openvdb.org >>> >>> This may not be what you are looking for but its worth considering. >>> >>> It is a voxel based csg tree system with mesh import and export. You >>> create shapes as voxel grids and then it can perform csg operations on >>> them, it uses a sparse storage mechanism so its effectivly only storing the >>> surface voxels amd thier relationships. >>> >>> On Fri, Nov 27, 2015, 07:40 doug moen <doug@moens.org >>> <javascript:_e(%7B%7D,'cvml','doug@moens.org');>> wrote: >>> >>>> Yes, but the "Eigen data constructs" (I don't understand this yet) use >>>> floating point representation, and the conversion from CGAL to native >>>> representation can result in an invalid mesh. This is mentioned in the >>>> tutorial. Therefore, I don't see how we can use this: it's not robust. >>>> >>>> What I think we want is a robust CSG geometry engine that works with >>>> floating point meshes. This is extremely difficult to program correctly, >>>> because you have to repair damage to the mesh caused by transformations, >>>> deal with floating point instability, and so on, and there are a lot of >>>> tricky edge cases. I'd be looking for a well-exercised engine with about 20 >>>> years worth of development and maintenance, and definitely not a >>>> single-person project with only a year or two of work done. >>>> >>>> On 26 November 2015 at 17:43, Andrew Plumb <andrew@plumb.org >>>> <javascript:_e(%7B%7D,'cvml','andrew@plumb.org');>> wrote: >>>> >>>>> Ah, so it does: >>>>> >>>>> >>>>> https://github.com/libigl/libigl/blob/master/tutorial/609_Boolean/main.cpp >>>>> >>>>> >>>>> https://github.com/libigl/libigl/blob/master/include/igl/copyleft/boolean/mesh_boolean.cpp >>>>> >>>>> On the plus side, looks like the meshes going into the operations and >>>>> coming out are Eigen data constructs, so it may be easier to parallelize >>>>> the operations and faster non-CSG mesh transforms (translate, rotate, etc.). >>>>> >>>>> Something to play with… >>>>> >>>>> Andrew. >>>>> >>>>> On Nov 26, 2015, at 3:51 PM, doug moen <doug@moens.org >>>>> <javascript:_e(%7B%7D,'cvml','doug@moens.org');>> wrote: >>>>> >>>>> This appears to use CGAL and Cork to implement boolean operations. >>>>> https://github.com/gilbo/cork >>>>> >>>>> They mention that Cork is available as an alternative: it is faster, >>>>> but not always robust. >>>>> >>>>> On 26 November 2015 at 15:38, clothbot <andrew@plumb.org >>>>> <javascript:_e(%7B%7D,'cvml','andrew@plumb.org');>> wrote: >>>>> >>>>>> Hey Everyone, >>>>>> >>>>>> Has anyone looked into using libigl as a (partial) CGAL replacement >>>>>> for 3D >>>>>> boolean op's and mesh manipulations? >>>>>> >>>>>> http://libigl.github.io/libigl/ >>>>>> >>>>>> https://github.com/libigl/libigl >>>>>> >>>>>> http://www.alecjacobson.com/weblog/?tag=libigl >>>>>> >>>>>> Looks to be quite powerful! >>>>>> >>>>>> Andrew. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> View this message in context: >>>>>> http://forum.openscad.org/libigl-anyone-poked-at-it-for-CGAL-partial-replacement-tp14769.html >>>>>> Sent from the OpenSCAD mailing list archive at Nabble.com >>>>>> <http://nabble.com>. >>>>>> >>>>>> _______________________________________________ >>>>>> OpenSCAD mailing list >>>>>> Discuss@lists.openscad.org >>>>>> <javascript:_e(%7B%7D,'cvml','Discuss@lists.openscad.org');> >>>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> OpenSCAD mailing list >>>>> Discuss@lists.openscad.org >>>>> <javascript:_e(%7B%7D,'cvml','Discuss@lists.openscad.org');> >>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>> >>>>> >>>>> -- >>>>> >>>>> "The future is already here. It's just not very evenly distributed" >>>>> -- William Gibson >>>>> >>>>> Me: http://clothbot.com/wiki/ >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OpenSCAD mailing list >>>>> Discuss@lists.openscad.org >>>>> <javascript:_e(%7B%7D,'cvml','Discuss@lists.openscad.org');> >>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>> >>>>> >>>> _______________________________________________ >>>> OpenSCAD mailing list >>>> Discuss@lists.openscad.org >>>> <javascript:_e(%7B%7D,'cvml','Discuss@lists.openscad.org');> >>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>> >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org >>> <javascript:_e(%7B%7D,'cvml','Discuss@lists.openscad.org');> >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >>> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> <javascript:_e(%7B%7D,'cvml','Discuss@lists.openscad.org');> >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> >

Openvdb and ShapeJS specify primitive geometric objects using a "signed distance function", which maps an (x,y,z) coordinate to an integer, which is negative inside the object, positive outside, and zero at the surface. This is the same as the " implicit function" representation used by ImplicitCAD. https://christopherolah.wordpress.com/2011/11/06/manipulation-of-implicit-functions-with-an-eye-on-cad/ On Friday, 27 November 2015, doug moen <doug@moens.org> wrote: > If you want to read about a voxel based solid modelling language written > in JavaScript, check out ShapeJS. > > http://shapejs.shapeways.com/getting-started > > It is built on top of very powerful primitive operations. > > You can specify an arbitrary 3d shape by a function that maps each > coordinate in the voxel grid to a signed distance. The CSG operations are > available for composing objects. You can specify an arbitrary non affine > transformation using a function, as proposed by Trygon. > > But I bet they don't support convex hull. You need to identify the > vertexes in order to compute this, and that's not easily done with a voxel > representation. > > It seems to me that we would need to design a hybrid system supporting a > mixture of mesh and voxel representations if we wanted to extend openscad > with voxel support, while retaining full backward compatibility. > > > On Thursday, 26 November 2015, Tim Hawkins <tim.thawkins@gmail.com > <javascript:_e(%7B%7D,'cvml','tim.thawkins@gmail.com');>> wrote: > >> It does claim to be multithreaded, which i can belive as voxel operations >> are easy to partition, i dont claim to have any expertice in this, my >> graphics abilities are limited to 2d, i used to write postscript >> rasterisation engines, which render down to a trapezoid list which is easy >> to slice and hand out to different threads for operations like colour >> correction and halftoning. >> >> Given it does work on a different set of principles there will be >> operations that are missing or sub optimimal, like wise there will be >> aspects that are faster and open up new capabilities, its just a case of >> determining what the tradeoffs are. >> >> On Fri, Nov 27, 2015, 12:29 doug moen <doug@moens.org> wrote: >> >>> It looks interesting. >>> >>> It does have CSG operations. While reading about voxel based systems, I >>> found a claim that CSG is slow on voxel systems, compared to mesh systems, >>> and I found a forum post complaining about the speed of CSG operations in >>> OpenVDB. So this might not solve our speed problems with CGAL. >>> >>> I didn't find any operations for convex hull or minkowski sum. It's not >>> obvious how you implement these without converting to a mesh first, which I >>> bet is slow. >>> >>> It is described as a visual effects library, and the home page demos >>> effects like clouds, fog, dust clouds, particle based fluid simulations. If >>> this is the focus, then I'm not sure it will be efficient for our use >>> cases. We could try it and do some performance measurements. >>> >>> I wonder what kind of 3D modelling operations are enabled by a voxel >>> engine, stuff that's difficult with our current mesh engine? >>> >>> On 26 November 2015 at 22:16, Tim Hawkins <tim.thawkins@gmail.com> >>> wrote: >>> >>>> http://www.openvdb.org >>>> >>>> This may not be what you are looking for but its worth considering. >>>> >>>> It is a voxel based csg tree system with mesh import and export. You >>>> create shapes as voxel grids and then it can perform csg operations on >>>> them, it uses a sparse storage mechanism so its effectivly only storing the >>>> surface voxels amd thier relationships. >>>> >>>> On Fri, Nov 27, 2015, 07:40 doug moen <doug@moens.org> wrote: >>>> >>>>> Yes, but the "Eigen data constructs" (I don't understand this yet) use >>>>> floating point representation, and the conversion from CGAL to native >>>>> representation can result in an invalid mesh. This is mentioned in the >>>>> tutorial. Therefore, I don't see how we can use this: it's not robust. >>>>> >>>>> What I think we want is a robust CSG geometry engine that works with >>>>> floating point meshes. This is extremely difficult to program correctly, >>>>> because you have to repair damage to the mesh caused by transformations, >>>>> deal with floating point instability, and so on, and there are a lot of >>>>> tricky edge cases. I'd be looking for a well-exercised engine with about 20 >>>>> years worth of development and maintenance, and definitely not a >>>>> single-person project with only a year or two of work done. >>>>> >>>>> On 26 November 2015 at 17:43, Andrew Plumb <andrew@plumb.org> wrote: >>>>> >>>>>> Ah, so it does: >>>>>> >>>>>> >>>>>> https://github.com/libigl/libigl/blob/master/tutorial/609_Boolean/main.cpp >>>>>> >>>>>> >>>>>> https://github.com/libigl/libigl/blob/master/include/igl/copyleft/boolean/mesh_boolean.cpp >>>>>> >>>>>> On the plus side, looks like the meshes going into the operations and >>>>>> coming out are Eigen data constructs, so it may be easier to parallelize >>>>>> the operations and faster non-CSG mesh transforms (translate, rotate, etc.). >>>>>> >>>>>> Something to play with… >>>>>> >>>>>> Andrew. >>>>>> >>>>>> On Nov 26, 2015, at 3:51 PM, doug moen <doug@moens.org> wrote: >>>>>> >>>>>> This appears to use CGAL and Cork to implement boolean operations. >>>>>> https://github.com/gilbo/cork >>>>>> >>>>>> They mention that Cork is available as an alternative: it is faster, >>>>>> but not always robust. >>>>>> >>>>>> On 26 November 2015 at 15:38, clothbot <andrew@plumb.org> wrote: >>>>>> >>>>>>> Hey Everyone, >>>>>>> >>>>>>> Has anyone looked into using libigl as a (partial) CGAL replacement >>>>>>> for 3D >>>>>>> boolean op's and mesh manipulations? >>>>>>> >>>>>>> http://libigl.github.io/libigl/ >>>>>>> >>>>>>> https://github.com/libigl/libigl >>>>>>> >>>>>>> http://www.alecjacobson.com/weblog/?tag=libigl >>>>>>> >>>>>>> Looks to be quite powerful! >>>>>>> >>>>>>> Andrew. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> View this message in context: >>>>>>> http://forum.openscad.org/libigl-anyone-poked-at-it-for-CGAL-partial-replacement-tp14769.html >>>>>>> Sent from the OpenSCAD mailing list archive at Nabble.com >>>>>>> <http://nabble.com>. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> "The future is already here. It's just not very evenly distributed" >>>>>> -- William Gibson >>>>>> >>>>>> Me: http://clothbot.com/wiki/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>> >>

The implicit function representation for geometric objects is awesome. First, it is an exact, analytic representation for things like spheres. The object eventually has to be converted to an approximation, for export, but this is delayed as long as possible. Meanwhile, transformations and CSG operations on analytic objects return exact results, not approximations. If you have analytic objects, then Trygon transformations are trivial. They are just function composition. You compose the transformation function with the implicit function, to produce another implicit function. So much easier, faster and precise than applying a Trygon transformation to a mesh. CSG operations are also trivial, as described by Chris Olah's essay (previous post). Union is the 'min' function, intersection is the 'max' function. Maybe what the voxel libraries give us is an infrastructure that wraps around implicit functions, so we can convert them to and from meshes, and preview them. On 27 November 2015 at 09:49, doug moen <doug@moens.org> wrote: > Openvdb and ShapeJS specify primitive geometric objects using a "signed > distance function", which maps an (x,y,z) coordinate to an integer, which > is negative inside the object, positive outside, and zero at the surface. > > This is the same as the " implicit function" representation used by > ImplicitCAD. > > > https://christopherolah.wordpress.com/2011/11/06/manipulation-of-implicit-functions-with-an-eye-on-cad/ > > > On Friday, 27 November 2015, doug moen <doug@moens.org> wrote: > >> If you want to read about a voxel based solid modelling language written >> in JavaScript, check out ShapeJS. >> >> http://shapejs.shapeways.com/getting-started >> >> It is built on top of very powerful primitive operations. >> >> You can specify an arbitrary 3d shape by a function that maps each >> coordinate in the voxel grid to a signed distance. The CSG operations are >> available for composing objects. You can specify an arbitrary non affine >> transformation using a function, as proposed by Trygon. >> >> But I bet they don't support convex hull. You need to identify the >> vertexes in order to compute this, and that's not easily done with a voxel >> representation. >> >> It seems to me that we would need to design a hybrid system supporting a >> mixture of mesh and voxel representations if we wanted to extend openscad >> with voxel support, while retaining full backward compatibility. >> >> >> On Thursday, 26 November 2015, Tim Hawkins <tim.thawkins@gmail.com> >> wrote: >> >>> It does claim to be multithreaded, which i can belive as voxel >>> operations are easy to partition, i dont claim to have any expertice in >>> this, my graphics abilities are limited to 2d, i used to write postscript >>> rasterisation engines, which render down to a trapezoid list which is easy >>> to slice and hand out to different threads for operations like colour >>> correction and halftoning. >>> >>> Given it does work on a different set of principles there will be >>> operations that are missing or sub optimimal, like wise there will be >>> aspects that are faster and open up new capabilities, its just a case of >>> determining what the tradeoffs are. >>> >>> On Fri, Nov 27, 2015, 12:29 doug moen <doug@moens.org> wrote: >>> >>>> It looks interesting. >>>> >>>> It does have CSG operations. While reading about voxel based systems, I >>>> found a claim that CSG is slow on voxel systems, compared to mesh systems, >>>> and I found a forum post complaining about the speed of CSG operations in >>>> OpenVDB. So this might not solve our speed problems with CGAL. >>>> >>>> I didn't find any operations for convex hull or minkowski sum. It's not >>>> obvious how you implement these without converting to a mesh first, which I >>>> bet is slow. >>>> >>>> It is described as a visual effects library, and the home page demos >>>> effects like clouds, fog, dust clouds, particle based fluid simulations. If >>>> this is the focus, then I'm not sure it will be efficient for our use >>>> cases. We could try it and do some performance measurements. >>>> >>>> I wonder what kind of 3D modelling operations are enabled by a voxel >>>> engine, stuff that's difficult with our current mesh engine? >>>> >>>> On 26 November 2015 at 22:16, Tim Hawkins <tim.thawkins@gmail.com> >>>> wrote: >>>> >>>>> http://www.openvdb.org >>>>> >>>>> This may not be what you are looking for but its worth considering. >>>>> >>>>> It is a voxel based csg tree system with mesh import and export. You >>>>> create shapes as voxel grids and then it can perform csg operations on >>>>> them, it uses a sparse storage mechanism so its effectivly only storing the >>>>> surface voxels amd thier relationships. >>>>> >>>>> On Fri, Nov 27, 2015, 07:40 doug moen <doug@moens.org> wrote: >>>>> >>>>>> Yes, but the "Eigen data constructs" (I don't understand this yet) >>>>>> use floating point representation, and the conversion from CGAL to native >>>>>> representation can result in an invalid mesh. This is mentioned in the >>>>>> tutorial. Therefore, I don't see how we can use this: it's not robust. >>>>>> >>>>>> What I think we want is a robust CSG geometry engine that works with >>>>>> floating point meshes. This is extremely difficult to program correctly, >>>>>> because you have to repair damage to the mesh caused by transformations, >>>>>> deal with floating point instability, and so on, and there are a lot of >>>>>> tricky edge cases. I'd be looking for a well-exercised engine with about 20 >>>>>> years worth of development and maintenance, and definitely not a >>>>>> single-person project with only a year or two of work done. >>>>>> >>>>>> On 26 November 2015 at 17:43, Andrew Plumb <andrew@plumb.org> wrote: >>>>>> >>>>>>> Ah, so it does: >>>>>>> >>>>>>> >>>>>>> https://github.com/libigl/libigl/blob/master/tutorial/609_Boolean/main.cpp >>>>>>> >>>>>>> >>>>>>> https://github.com/libigl/libigl/blob/master/include/igl/copyleft/boolean/mesh_boolean.cpp >>>>>>> >>>>>>> On the plus side, looks like the meshes going into the operations >>>>>>> and coming out are Eigen data constructs, so it may be easier to >>>>>>> parallelize the operations and faster non-CSG mesh transforms (translate, >>>>>>> rotate, etc.). >>>>>>> >>>>>>> Something to play with… >>>>>>> >>>>>>> Andrew. >>>>>>> >>>>>>> On Nov 26, 2015, at 3:51 PM, doug moen <doug@moens.org> wrote: >>>>>>> >>>>>>> This appears to use CGAL and Cork to implement boolean operations. >>>>>>> https://github.com/gilbo/cork >>>>>>> >>>>>>> They mention that Cork is available as an alternative: it is faster, >>>>>>> but not always robust. >>>>>>> >>>>>>> On 26 November 2015 at 15:38, clothbot <andrew@plumb.org> wrote: >>>>>>> >>>>>>>> Hey Everyone, >>>>>>>> >>>>>>>> Has anyone looked into using libigl as a (partial) CGAL replacement >>>>>>>> for 3D >>>>>>>> boolean op's and mesh manipulations? >>>>>>>> >>>>>>>> http://libigl.github.io/libigl/ >>>>>>>> >>>>>>>> https://github.com/libigl/libigl >>>>>>>> >>>>>>>> http://www.alecjacobson.com/weblog/?tag=libigl >>>>>>>> >>>>>>>> Looks to be quite powerful! >>>>>>>> >>>>>>>> Andrew. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> View this message in context: >>>>>>>> http://forum.openscad.org/libigl-anyone-poked-at-it-for-CGAL-partial-replacement-tp14769.html >>>>>>>> Sent from the OpenSCAD mailing list archive at Nabble.com >>>>>>>> <http://nabble.com>. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> "The future is already here. It's just not very evenly distributed" >>>>>>> -- William Gibson >>>>>>> >>>>>>> Me: http://clothbot.com/wiki/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>> >>>

> On Nov 27, 2015, at 10:29 AM, doug moen <doug@moens.org> wrote: > > The implicit function representation for geometric objects is awesome. F-Rep is a good short form: https://en.wikipedia.org/wiki/Function_representation I’d love to have a way of supporting F-Rep in OpenSCAD, as I often see designs where F-Rep would be a significantly cleaner representation. There are a number of projects are exploring F-Reps for solid modeling. Too many to mention really, but in the Open Source domain of 3D printing-related projects: ShapeJS, ImplicitCAD, Antimony. Tessellation quality is a challenge, but Shapeways makes a good argument for staying with voxels in some cases: http://abfab3d.com/2015/02/27/voxels-versus-triangles/ As Doug mentions, a hybrid approach seems tempting. I find that extremely scary, but it’s worth exploring. -Marius

IceSL has been mentioned on the list before. Their solid modelling language supports most of what's in OpenSCAD (and they accept OpenSCAD syntax directly, as an option). But it also supports F-Rep (what they call "implicits"). It's a hybrid system that supports both functional and mesh objects. Some operations, like convex_hull, only work on meshes, not on "implicits". Preview is so fast that they update the preview pane on each keystroke. Preview is implemented using FPU programming, and they have a list of supported graphics hardware. It's closed source, unfortunately. It's one of the products of a research group at Inria, and it's a fascinating window into what can be accomplished by a small group of people, and what's technically possible. My takeaway is that a hybrid system is feasible, and preview for a hybrid system can be made very fast*. STL export of functional objects remains a problem: it's going to be expensive. But it's feasible, and there are plenty of open source projects that implement code for this. *If we want fast preview, then there is still the engineering tradeoff between expressive power and fast preview. Some graphical operations can't be previewed quickly, it would seem. We've encountered this problem in OpenSCAD, where the prohibition on querying the mesh exists to keep preview fast. IceSL has fast preview, but you can't apply convex_hull to a functional object. PLASM finesses this problem by supporting progressive preview, where you render a crude approximation and preview that, then progressively improve the preview quality over time. On 27 November 2015 at 11:31, Marius Kintel <marius@kintel.net> wrote: > > > On Nov 27, 2015, at 10:29 AM, doug moen <doug@moens.org> wrote: > > > > The implicit function representation for geometric objects is awesome. > > F-Rep is a good short form: > https://en.wikipedia.org/wiki/Function_representation > I’d love to have a way of supporting F-Rep in OpenSCAD, as I often see > designs where F-Rep would be a significantly cleaner representation. > > There are a number of projects are exploring F-Reps for solid modeling. > Too many to mention really, but in the Open Source domain of 3D > printing-related projects: ShapeJS, ImplicitCAD, Antimony. > > Tessellation quality is a challenge, but Shapeways makes a good argument > for staying with voxels in some cases: > http://abfab3d.com/2015/02/27/voxels-versus-triangles/ > > As Doug mentions, a hybrid approach seems tempting. I find that extremely > scary, but it’s worth exploring. > > -Marius > > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >

clothbot said: "I'm curious of what OpenVDB might bring to the table in the way of multi-material (discrete and mixed), variable-density and/or texture and colour support. The stuff that the AMF file format hints at supporting but toolset support doesn't quite exist for yet." If you want to apply a texture to a surface (as AMF supports), then you need to implement that using a mesh representation, not a voxel/functional representation (in my opinion). The mesh represents surfaces explicitly, whereas the surface is expensive to recover from a voxel or functional representation. All of that other stuff should be quite feasible using a voxel/functional system. ShapeWays talks about how much better their voxel system is for supporting this. They have an SVX voxel file format, and the ShapeJS language for generating SVX files. quote: "One promise of 3D printing is that complexity is free. Sadly with STL files we’ve had the disconnect that more complexity equals more triangles equals larger files. Above a certain limit you just can’t use triangles to specify the details you want in a 3D printed model. Whether that information be material allocation, density, RGB color both internal and external or a custom id that could be used for another variable, not yet available in the 3D printers on the market." On 27 November 2015 at 08:31, clothbot <andrew@plumb.org> wrote: > Thinking out-loud more than anything else, I'm curious of what OpenVDB > might > bring to the table in the way of multi-material (discrete and mixed), > variable-density and/or texture and colour support. The stuff that the AMF > file format hints at supporting but toolset support doesn't quite exist for > yet. > > As it relates to OpenSCAD, I suspect it may be a case of us still needing > CGAL, but compartmentalizing/threading its use. Taking a > voxel-mesh-cgal-mesh-voxel path may be cleaner w.r.t. not breaking on the > final mesh-STL export stage because it's voxel-STL. > > Gotta pick our battles. :-) > > > doug.moen wrote > > It looks interesting. > > > > It does have CSG operations. While reading about voxel based systems, I > > found a claim that CSG is slow on voxel systems, compared to mesh > systems, > > and I found a forum post complaining about the speed of CSG operations in > > OpenVDB. So this might not solve our speed problems with CGAL. > > > > I didn't find any operations for convex hull or minkowski sum. It's not > > obvious how you implement these without converting to a mesh first, which > > I > > bet is slow. > > > > It is described as a visual effects library, and the home page demos > > effects like clouds, fog, dust clouds, particle based fluid simulations. > > If > > this is the focus, then I'm not sure it will be efficient for our use > > cases. We could try it and do some performance measurements. > > > > I wonder what kind of 3D modelling operations are enabled by a voxel > > engine, stuff that's difficult with our current mesh engine? > > > > > > -- > View this message in context: > http://forum.openscad.org/libigl-anyone-poked-at-it-for-CGAL-partial-replacement-tp14769p14793.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 > > >

On 11/27/2015 06:36 PM, doug moen wrote: > It's closed source, unfortunately. It's one of the products of a > research group at Inria, and it's a fascinating window into what can be > accomplished by a small group of people, and what's technically possible. > Yeah, it's quite interesting stuff. Although we are only allowed to look through the closed windows and watch what they can do with more the a million of €. It makes me a bit sad the EU funds research that is not open. ciao, Torsten.