I have set up a Linux build environment for OpenSCAD, and can successfully
build out of the box.
I'm now looking at unplugging CGAL, in order to try different backend.
I see the code uses "#ifdef ENABLE_CGAL" in several places. I naively tried
commenting "CONFIG += cgal" in openscad.pro, but this gives build errors.
Inspection shows files like GeometryEvaluator.cc refer to CGAL without any
guards.
Perhaps this is a build option that used to work and has decayed, or maybe I
am doing something wrong, but I couldn't find any mention in build guides or
google searches.
Any tips?
--
View this message in context: http://forum.openscad.org/Building-OpenSCAD-without-CGAL-tp12880.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
I decided that GeometryEvaluator.cc is CGAL specific and should be in the
cgal {} group. I created a stub version to act as a placeholder for CSG API.
There are several places where CGAL dependency has an impact, notably
mainwin.cc and the OpenCSG preview. The preview requires CGAL to evaluate
some geometry OpenCSG can't handle.
After a bit of hacking, I got it to build and run, the GUI doesn't do
anything but the command line runs ok and can generate a CSG file.
There are also some miscellaneous dependencies, e.g. OFF import. I think
there is no problem using parts of CGAL where useful, and replacing the CSG
part, but the separation between openscad and CGAL is less clean than I had
hoped.
I'm not sure how preview/render modes are best done with alternative CSG
backends, it would be nice if the OpenCSG preview was self-contained.
Ideally I think the CSG engine and GUI would be independent.
For the moment I will continue with my hacked version, but longer term some
refactoring to create a cleaner interface will be needed. This could be done
independently of developing alternative prototype CSG implementations, if
anyone is interested? :)
--
View this message in context: http://forum.openscad.org/Building-OpenSCAD-without-CGAL-tp12880p12885.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On 2015-06-14 15:12, bobc wrote:
For the moment I will continue with my hacked version, but longer term some
refactoring to create a cleaner interface will be needed. This could be done
independently of developing alternative prototype CSG implementations, if
anyone is interested? :)
I have an idea to explore a CSG implementation based on OpenCascade, but
I must admit it is nothing but an idea at this stage. I have looked at
some code samples which looked interesting, but I have not gone further.
I am hoping to spend a few days this summer to figure some of the basics.
A clean interface between OpenSCAD and a CSG implementation will
certainly make it easier to offer alternatives to using CGAL.
Carsten Arnholm
I had a quick look at pyOCC - Python wrapper for OCE. The quick example I
tried worked quickly and simply, might be a useful interface for test
purposes.
However, I am going to look at Carve first, this library has been in Blender
for a while and seems to have got positive comments from users. Carve has a
GPL2 or GPL3 license, so should be OK.
I have most of the OpenSCAD gui working without CGAL, except for the preview
mode which I have been able to get working. CGAL has hooks in quite a few
functions, it will take a little while to tease out the dependencies.
I will try to make some notes as I go along, which may serve as a "How to"
guide for replacing CGAL.
I've realised that CGAL has some unique features and quirks, which may be
difficult or impractical to replicate with a different CSG engine, which may
mean a hard choice whether to support multiple backends, or drop certain
features that users currently depend on.
--
View this message in context: http://forum.openscad.org/Building-OpenSCAD-without-CGAL-tp12880p12894.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On Jun 14, 2015, at 04:21 AM, bobc bobcousins42@googlemail.com wrote:
I see the code uses "#ifdef ENABLE_CGAL" in several places.
This switch has bitrotted quite a bit, but the original idea was to be able to use it to turn off all CGAL code, but still have a workable binary.
As you figured out, the preview mode is dependent on GeometryEvaluator for the features not implemented there (like minkowski, hull etc.). This make it is a bit annoying to simply pull the CGAL implementation.
The correct solution would be to perform a green refactoring of the compile switch and any API changes. Carve has been on my radar for a while.
I found a comment related to carve robustness here: https://github.com/jamesgregson/pyPolyCSG
..so carve might need some testing.
-Marius
It's been a while, but I have been slowly working away at this. There is a
quite a lot of stuff to pick through. I've now got to the point of trying do
a union with carve. This seems to work ok for cubes, but not spheres :( I
get an assertion error in the carve lib, not really sure what it means.
There is quite a bit of stuff I have taken a best guess at, probably went
wrong somewhere. Latest effort :
https://github.com/bobc/openscad/tree/carve_csg
http://forum.openscad.org/file/n13249/screen1.png
http://forum.openscad.org/file/n13249/screen2.png
--
View this message in context: http://forum.openscad.org/Building-OpenSCAD-without-CGAL-tp12880p13249.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Good news, I sorted out previous problems with strange results. Basically I
was passing a bad mesh to carve...
Also some slightly exciting news, on this particular benchmark carve is over
10 times faster rendering than 2015.03, 4 seconds vs 48 seconds.
http://forum.openscad.org/file/n13262/screen3.png
--
View this message in context: http://forum.openscad.org/Building-OpenSCAD-without-CGAL-tp12880p13262.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On 07/22/2015 02:39 PM, bobc wrote:
Good news, I sorted out previous problems with strange results. Basically I
was passing a bad mesh to carve...
Also some slightly exciting news, on this particular benchmark carve is over
10 times faster rendering than 2015.03, 4 seconds vs 48 seconds.
thank you for doing this!
-y-
That's really good news, and I expect it will significantly speed up some
of my old code.
On 22 July 2015 at 17:39, bobc bobcousins42@googlemail.com wrote:
Good news, I sorted out previous problems with strange results. Basically I
was passing a bad mesh to carve...
Also some slightly exciting news, on this particular benchmark carve is
over
10 times faster rendering than 2015.03, 4 seconds vs 48 seconds.
http://forum.openscad.org/file/n13262/screen3.png
--
View this message in context:
http://forum.openscad.org/Building-OpenSCAD-without-CGAL-tp12880p13262.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