How to separate a geometry having distinct objects ?
I don't have either a solution to the task of finding the connected
component of a model. Even if all mesh data needed to reproduce the model
with a polyhedron call was available, the process of finding the components
with the language would be rather inefficient because there is no effective
way to mark vertices during a tour through the mesh.
Jordan Brown openscad@jordan.maileater.net wrote:
It is only when the geometry work is done that it starts to be possible to
determine things like bounding boxes,
like how many solids result from a particular boolean operation, and so on
- and that's too late for the OpenSCAD program to take any action,
because it's already done.
As a side comment without arguing against that, with some ingenuity its is
possible to generate fully parametric models like the one bellow:
[image: fob.PNG]
The design would be simple to be done from the bounding box data of the
inscription and so we are tempted to give up before realizing that the data
is not essential, the bounding box itself is enough.
// inscription data
text = "Any text here";
size = 10;
// fob data
margins = [7, 4];
border = 2;
thickness = 2;
depth = 1;
fob(margins, border, thickness)
union() {
text(text,size=size,valign="center");
translate([-size7/16,0])
rotate(18)
circle(size5/16,$fn=5);
}
module fob(margins, border, thickness) {
module simple_fob(dimens) {
minkowski() {
translate([0,0,.01])
cube([dimens[0], dimens[1],.02], center=true);
bbox()
linear_extrude(dimens[2], convexity=10)
children();
}
}
difference() {
simple_fob([margins[0]+border,margins[1]+border, thickness])
children();
difference() {
translate([0,0,thickness-depth])
simple_fob([margins[0],margins[1], thickness])
children();
linear_extrude(thickness, convexity=10)
children();
}
}
}
The code relies on an operator (a module that handles children() ), bbox(),
to generate the bounding box geometry that is a simple cube. That operator
may be coded in OpenSCAD as it can be seen in the now overlooked OpenSCAD
Manual section, Tips and Tricks
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Tips_and_Tricks#Computing_a_bounding_box.
Although the code makes use of minkowski(), an operator usually considered
slow, its operation involves only cubic shapes and it is fast. In my
machine, the render (F6) of this model takes a few seconds.
The bbox() operator may be also helpful for defining a clipping box fitted
to a design as discussed here elsewhere.
I find this response Jordan really informative/intriguing, really well written, and I really want to know more about how this division and sequence of processing occurs in OpenSCAD. You have flagged the top level reasons for why OpenSCAD can't "post process" objects, but I still don't understand the process how it works. Is a fuller explanation of your response available somewhere? Is there an OpenSCAD page that illuminates this?
Forgive my ignorance, but given the frequency of questions relating to these "limitations" on this forum I suspect I am not alone, but I think a lot of frustration with OpenSCAD could be quickly defused with a more in depth explanation along these lines that people like me could be referred to?
How can all the processing be completed, then the geometry completed after that?
Cheers, RobW
On 26 March 2021 11:46:55 am AEDT, Jordan Brown openscad@jordan.maileater.net wrote:
It is certainly possible to imagine a 3D design tool, even a
programming
language like OpenSCAD, that can do things like cut up an object and
then manipulate the separate solids that result.
OpenSCAD can't do that without a major overhaul, because it doesn't do
any of the geometry processing until after the program has finished
running.
The immediate output from an OpenSCAD program is not geometry, not a
list of triangles, et cetera. It is a tree representation of shapes,
transformations, and the operations to be done on those shapes. Look
at
Design / Display CSG Tree to see. If you write "intersection() {
sphere(); cube(); }", you'll see that that's pretty much what the CSG
tree shows. All of the expressions have been evaluated, all of the
loops unrolled, all of the conditionals considered, but none of the
geometry work has been done. At that point in the processing, OpenSCAD
doesn't know anything interesting about the geometry.
It is only when the geometry work is done that it starts to be possible
to determine things like bounding boxes, like how many solids result
from a particular boolean operation, and so on - and that's too late
for
the OpenSCAD program to take any action, because it's already done.
Could OpenSCAD have been designed differently, so that it did the
geometry as it was processing the program, as Cascade Studio apparently
does? Sure. But it wasn't, and that's a pretty fundamental design
decision and a big job to change.
BTW, this isn't something that's a problem with the OpenSCAD language
per se. Another environment could easily make the same design
decision. Carsten's AngelCAD has the same architecture - in fact, it
does the geometry work in a totally separate program. I don't know
about Doug's Curv - Doug?
On 3/26/2021 4:27 AM, Rob Ward wrote:
How can all the processing be completed, then the geometry completed
after that?
The simplest explanation is to set up a model, F5 it, and then look at
Design / View CSG Tree.
(Side note: It would be nice if, once you have the CSG Tree Dump window
up, it was updated on subsequent runs.)
Consider this program:
difference() {
cube(20, center=true);
for (x = [-5:10:5], z=[-5:10:5]) {
if (x > 0 || z > 0) {
translate([x, 0, z])
rotate([90,0,0])
cylinder(h=21, d=5, center=true);
}
}
}
which generates this object:
The output from the processing of the OpenSCAD language is this, from
Design / Display CSG Tree:
difference() {
cube(size = [20, 20, 20], center = true);
group() {
group() {
multmatrix([[1, 0, 0, -5], [0, 1, 0, 0], [0, 0, 1, 5], [0, 0, 0, 1]]) {
multmatrix([[1, 0, 0, 0], [0, 0, -1, 0], [0, 1, 0, 0], [0, 0, 0, 1]]) {
cylinder($fn = 0, $fa = 12, $fs = 2, h = 21, r1 = 2.5, r2 = 2.5, center = true);
}
}
}
group() {
multmatrix([[1, 0, 0, 5], [0, 1, 0, 0], [0, 0, 1, -5], [0, 0, 0, 1]]) {
multmatrix([[1, 0, 0, 0], [0, 0, -1, 0], [0, 1, 0, 0], [0, 0, 0, 1]]) {
cylinder($fn = 0, $fa = 12, $fs = 2, h = 21, r1 = 2.5, r2 = 2.5, center = true);
}
}
}
group() {
multmatrix([[1, 0, 0, 5], [0, 1, 0, 0], [0, 0, 1, 5], [0, 0, 0, 1]]) {
multmatrix([[1, 0, 0, 0], [0, 0, -1, 0], [0, 1, 0, 0], [0, 0, 0, 1]]) {
cylinder($fn = 0, $fa = 12, $fs = 2, h = 21, r1 = 2.5, r2 = 2.5, center = true);
}
}
}
}
}
Note how all of the "program" stuff is gone. There are no variables,
there are no loops, there is no "if". There's just shapes (a cube and
three cylinders), transformations (the matrix multiplications), and
boolean operations (the difference).
Note: I assume that this is a textual representation of an
in-memory data structure, rather than text that's actually generated
in the middle of the pipeline. But I don't know.
This is the data that comes out of executing the program, that then goes
into the geometry engines.
For Carsten's AngelCAD environment it's more distinct - an AngelCAD
execution generates an XML file with basically the same data as above,
and then a separate program interprets and displays it.
Does that sort of make sense?
That is exactly what I did.
On Fri, Mar 26, 2021 at 3:25 PM Jordan Brown openscad@jordan.maileater.net
wrote:
It is certainly possible to imagine a 3D design tool, even a programming
language like OpenSCAD, that can do things like cut up an object and then
manipulate the separate solids that result.
OpenSCAD can't do that without a major overhaul, because it doesn't do any
of the geometry processing until after the program has finished running.
The immediate output from an OpenSCAD program is not geometry, not a list
of triangles, et cetera. It is a tree representation of shapes,
transformations, and the operations to be done on those shapes. Look at
Design / Display CSG Tree to see. If you write "intersection() { sphere();
cube(); }", you'll see that that's pretty much what the CSG tree shows.
All of the expressions have been evaluated, all of the loops unrolled, all
of the conditionals considered, but none of the geometry work has been
done. At that point in the processing, OpenSCAD doesn't know anything
interesting about the geometry.
It is only when the geometry work is done that it starts to be possible to
determine things like bounding boxes, like how many solids result from a
particular boolean operation, and so on - and that's too late for the
OpenSCAD program to take any action, because it's already done.
Could OpenSCAD have been designed differently, so that it did the geometry
as it was processing the program, as Cascade Studio apparently does?
Sure. But it wasn't, and that's a pretty fundamental design decision and a
big job to change.
BTW, this isn't something that's a problem with the OpenSCAD language per
se. Another environment could easily make the same design decision.
Carsten's AngelCAD has the same architecture - in fact, it does the
geometry work in a totally separate program. I don't know about Doug's
Curv - Doug?
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
--
Damien Towning
I wanted to respond to this with look at the OpenSCAD code. It does
generate geometry. You are just looking at the interface. Look at the code.
Understand what it does. Two primary paths. One generates geometry. The
other implements Gold Feather. People are trying to explain to you how
things work and what they have learned.
On Fri, Mar 26, 2021 at 3:25 PM Jordan Brown openscad@jordan.maileater.net
wrote:
It is certainly possible to imagine a 3D design tool, even a programming
language like OpenSCAD, that can do things like cut up an object and then
manipulate the separate solids that result.
OpenSCAD can't do that without a major overhaul, because it doesn't do any
of the geometry processing until after the program has finished running.
The immediate output from an OpenSCAD program is not geometry, not a list
of triangles, et cetera. It is a tree representation of shapes,
transformations, and the operations to be done on those shapes. Look at
Design / Display CSG Tree to see. If you write "intersection() { sphere();
cube(); }", you'll see that that's pretty much what the CSG tree shows.
All of the expressions have been evaluated, all of the loops unrolled, all
of the conditionals considered, but none of the geometry work has been
done. At that point in the processing, OpenSCAD doesn't know anything
interesting about the geometry.
It is only when the geometry work is done that it starts to be possible to
determine things like bounding boxes, like how many solids result from a
particular boolean operation, and so on - and that's too late for the
OpenSCAD program to take any action, because it's already done.
Could OpenSCAD have been designed differently, so that it did the geometry
as it was processing the program, as Cascade Studio apparently does?
Sure. But it wasn't, and that's a pretty fundamental design decision and a
big job to change.
BTW, this isn't something that's a problem with the OpenSCAD language per
se. Another environment could easily make the same design decision.
Carsten's AngelCAD has the same architecture - in fact, it does the
geometry work in a totally separate program. I don't know about Doug's
Curv - Doug?
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
--
Damien Towning
OpenSCAD is constrained by what its core libraries like CGAL can do in real
time in the mesh generating pipe line. Having got around that with stencil
buffering tricks in the Gold Feather is basically genius. Assuming you had
a clue and went ahead and implemented that part of the pipe line in the
browser you could indeed do selections and other actions. But this wont
have solved the real geometry pipeline. At which point you will arrive
where I am. Which is fixing that. CGAL wants to make geometry that is
perfect and water tight. This is a very good thing. That means it needs to
use real numbers in the shape of stuff like MFPR. I've traded some of that
accuracy for speed by going with Open Cascade. Anything is always going to
be a trade off.
On Sat, Mar 27, 2021 at 7:29 PM Damien Towning connolly.damien@gmail.com
wrote:
I wanted to respond to this with look at the OpenSCAD code. It does
generate geometry. You are just looking at the interface. Look at the code.
Understand what it does. Two primary paths. One generates geometry. The
other implements Gold Feather. People are trying to explain to you how
things work and what they have learned.
On Fri, Mar 26, 2021 at 3:25 PM Jordan Brown <
openscad@jordan.maileater.net> wrote:
It is certainly possible to imagine a 3D design tool, even a programming
language like OpenSCAD, that can do things like cut up an object and then
manipulate the separate solids that result.
OpenSCAD can't do that without a major overhaul, because it doesn't do
any of the geometry processing until after the program has finished running.
The immediate output from an OpenSCAD program is not geometry, not a list
of triangles, et cetera. It is a tree representation of shapes,
transformations, and the operations to be done on those shapes. Look at
Design / Display CSG Tree to see. If you write "intersection() { sphere();
cube(); }", you'll see that that's pretty much what the CSG tree shows.
All of the expressions have been evaluated, all of the loops unrolled, all
of the conditionals considered, but none of the geometry work has been
done. At that point in the processing, OpenSCAD doesn't know anything
interesting about the geometry.
It is only when the geometry work is done that it starts to be possible
to determine things like bounding boxes, like how many solids result from a
particular boolean operation, and so on - and that's too late for the
OpenSCAD program to take any action, because it's already done.
Could OpenSCAD have been designed differently, so that it did the
geometry as it was processing the program, as Cascade Studio apparently
does? Sure. But it wasn't, and that's a pretty fundamental design
decision and a big job to change.
BTW, this isn't something that's a problem with the OpenSCAD language per
se. Another environment could easily make the same design decision.
Carsten's AngelCAD has the same architecture - in fact, it does the
geometry work in a totally separate program. I don't know about Doug's
Curv - Doug?
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
--
Damien Towning
--
Damien Towning
Further as stated previously somewhere I have basically convinced myself a
'reverse' gold feather exists. That is to go from the stencil buffer back
to geometry. I've sort of got this working in limited combinations of
stencil buffer examples.
On Sat, Mar 27, 2021 at 7:40 PM Damien Towning connolly.damien@gmail.com
wrote:
OpenSCAD is constrained by what its core libraries like CGAL can do in
real time in the mesh generating pipe line. Having got around that with
stencil buffering tricks in the Gold Feather is basically genius. Assuming
you had a clue and went ahead and implemented that part of the pipe line in
the browser you could indeed do selections and other actions. But this wont
have solved the real geometry pipeline. At which point you will arrive
where I am. Which is fixing that. CGAL wants to make geometry that is
perfect and water tight. This is a very good thing. That means it needs to
use real numbers in the shape of stuff like MFPR. I've traded some of that
accuracy for speed by going with Open Cascade. Anything is always going to
be a trade off.
On Sat, Mar 27, 2021 at 7:29 PM Damien Towning connolly.damien@gmail.com
wrote:
I wanted to respond to this with look at the OpenSCAD code. It does
generate geometry. You are just looking at the interface. Look at the code.
Understand what it does. Two primary paths. One generates geometry. The
other implements Gold Feather. People are trying to explain to you how
things work and what they have learned.
On Fri, Mar 26, 2021 at 3:25 PM Jordan Brown <
openscad@jordan.maileater.net> wrote:
It is certainly possible to imagine a 3D design tool, even a programming
language like OpenSCAD, that can do things like cut up an object and then
manipulate the separate solids that result.
OpenSCAD can't do that without a major overhaul, because it doesn't do
any of the geometry processing until after the program has finished running.
The immediate output from an OpenSCAD program is not geometry, not a
list of triangles, et cetera. It is a tree representation of shapes,
transformations, and the operations to be done on those shapes. Look at
Design / Display CSG Tree to see. If you write "intersection() { sphere();
cube(); }", you'll see that that's pretty much what the CSG tree shows.
All of the expressions have been evaluated, all of the loops unrolled, all
of the conditionals considered, but none of the geometry work has been
done. At that point in the processing, OpenSCAD doesn't know anything
interesting about the geometry.
It is only when the geometry work is done that it starts to be possible
to determine things like bounding boxes, like how many solids result from a
particular boolean operation, and so on - and that's too late for the
OpenSCAD program to take any action, because it's already done.
Could OpenSCAD have been designed differently, so that it did the
geometry as it was processing the program, as Cascade Studio apparently
does? Sure. But it wasn't, and that's a pretty fundamental design
decision and a big job to change.
BTW, this isn't something that's a problem with the OpenSCAD language
per se. Another environment could easily make the same design decision.
Carsten's AngelCAD has the same architecture - in fact, it does the
geometry work in a totally separate program. I don't know about Doug's
Curv - Doug?
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
--
Damien Towning
--
Damien Towning
--
Damien Towning
I lifted this from GitHub.
OpenSCAD uses CGAL's CSG operations on Nef polyhedrons, not the brep
functionality. CGAL's way of doing CSG is extremely slow, but comes with
pretty good guarantees to produce manifold objects, making it well suited
for 3D printing. I'm not familiar enough with CGAL or breps to tell whether
it would be possible to rewrite (parts of) OpenSCAD to use other techniques
for calculating the resulting surfaces. There has been a bit of talk about
OpenCascade, but nobody has yet come up with a convincing proof of concept.
OpenJsCad is a good approach to deal with CSG in a different way, but in
the end all such approaches I've seen suffer from numerical instabilities
once objects get too complex.
FWIW, the CGAL support in OpenSCAD is pretty much isolated to a single
visitor class transforming a CSG tree into polygons, so it's not
unsurpassable to experiment with alternatives.
On Sat, Mar 27, 2021 at 7:43 PM Damien Towning connolly.damien@gmail.com
wrote:
Further as stated previously somewhere I have basically convinced myself a
'reverse' gold feather exists. That is to go from the stencil buffer back
to geometry. I've sort of got this working in limited combinations of
stencil buffer examples.
On Sat, Mar 27, 2021 at 7:40 PM Damien Towning connolly.damien@gmail.com
wrote:
OpenSCAD is constrained by what its core libraries like CGAL can do in
real time in the mesh generating pipe line. Having got around that with
stencil buffering tricks in the Gold Feather is basically genius. Assuming
you had a clue and went ahead and implemented that part of the pipe line in
the browser you could indeed do selections and other actions. But this wont
have solved the real geometry pipeline. At which point you will arrive
where I am. Which is fixing that. CGAL wants to make geometry that is
perfect and water tight. This is a very good thing. That means it needs to
use real numbers in the shape of stuff like MFPR. I've traded some of that
accuracy for speed by going with Open Cascade. Anything is always going to
be a trade off.
On Sat, Mar 27, 2021 at 7:29 PM Damien Towning connolly.damien@gmail.com
wrote:
I wanted to respond to this with look at the OpenSCAD code. It does
generate geometry. You are just looking at the interface. Look at the code.
Understand what it does. Two primary paths. One generates geometry. The
other implements Gold Feather. People are trying to explain to you how
things work and what they have learned.
On Fri, Mar 26, 2021 at 3:25 PM Jordan Brown <
openscad@jordan.maileater.net> wrote:
It is certainly possible to imagine a 3D design tool, even a
programming language like OpenSCAD, that can do things like cut up an
object and then manipulate the separate solids that result.
OpenSCAD can't do that without a major overhaul, because it doesn't do
any of the geometry processing until after the program has finished running.
The immediate output from an OpenSCAD program is not geometry, not a
list of triangles, et cetera. It is a tree representation of shapes,
transformations, and the operations to be done on those shapes. Look at
Design / Display CSG Tree to see. If you write "intersection() { sphere();
cube(); }", you'll see that that's pretty much what the CSG tree shows.
All of the expressions have been evaluated, all of the loops unrolled, all
of the conditionals considered, but none of the geometry work has been
done. At that point in the processing, OpenSCAD doesn't know anything
interesting about the geometry.
It is only when the geometry work is done that it starts to be possible
to determine things like bounding boxes, like how many solids result from a
particular boolean operation, and so on - and that's too late for the
OpenSCAD program to take any action, because it's already done.
Could OpenSCAD have been designed differently, so that it did the
geometry as it was processing the program, as Cascade Studio apparently
does? Sure. But it wasn't, and that's a pretty fundamental design
decision and a big job to change.
BTW, this isn't something that's a problem with the OpenSCAD language
per se. Another environment could easily make the same design decision.
Carsten's AngelCAD has the same architecture - in fact, it does the
geometry work in a totally separate program. I don't know about Doug's
Curv - Doug?
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
--
Damien Towning
--
Damien Towning
--
Damien Towning
--
Damien Towning
Sorry if I sounded grumpy. I've done it. I've written a 'bare-bones'
implementation using Open Cascade. It works in parallel. It optimises the
OpenSCAD. It does these things. I had it up for a year or so. Took it down
again because building house. Also had complete rethink. I guess it is up
to each of us to all go relearn the same lessons.
On Sat, Mar 27, 2021 at 8:08 PM Damien Towning connolly.damien@gmail.com
wrote:
I lifted this from GitHub.
OpenSCAD uses CGAL's CSG operations on Nef polyhedrons, not the brep
functionality. CGAL's way of doing CSG is extremely slow, but comes with
pretty good guarantees to produce manifold objects, making it well suited
for 3D printing. I'm not familiar enough with CGAL or breps to tell whether
it would be possible to rewrite (parts of) OpenSCAD to use other techniques
for calculating the resulting surfaces. There has been a bit of talk about
OpenCascade, but nobody has yet come up with a convincing proof of concept.
OpenJsCad is a good approach to deal with CSG in a different way, but in
the end all such approaches I've seen suffer from numerical instabilities
once objects get too complex.
FWIW, the CGAL support in OpenSCAD is pretty much isolated to a single
visitor class transforming a CSG tree into polygons, so it's not
unsurpassable to experiment with alternatives.
On Sat, Mar 27, 2021 at 7:43 PM Damien Towning connolly.damien@gmail.com
wrote:
Further as stated previously somewhere I have basically convinced myself
a 'reverse' gold feather exists. That is to go from the stencil buffer back
to geometry. I've sort of got this working in limited combinations of
stencil buffer examples.
On Sat, Mar 27, 2021 at 7:40 PM Damien Towning connolly.damien@gmail.com
wrote:
OpenSCAD is constrained by what its core libraries like CGAL can do in
real time in the mesh generating pipe line. Having got around that with
stencil buffering tricks in the Gold Feather is basically genius. Assuming
you had a clue and went ahead and implemented that part of the pipe line in
the browser you could indeed do selections and other actions. But this wont
have solved the real geometry pipeline. At which point you will arrive
where I am. Which is fixing that. CGAL wants to make geometry that is
perfect and water tight. This is a very good thing. That means it needs to
use real numbers in the shape of stuff like MFPR. I've traded some of that
accuracy for speed by going with Open Cascade. Anything is always going to
be a trade off.
On Sat, Mar 27, 2021 at 7:29 PM Damien Towning <
connolly.damien@gmail.com> wrote:
I wanted to respond to this with look at the OpenSCAD code. It does
generate geometry. You are just looking at the interface. Look at the code.
Understand what it does. Two primary paths. One generates geometry. The
other implements Gold Feather. People are trying to explain to you how
things work and what they have learned.
On Fri, Mar 26, 2021 at 3:25 PM Jordan Brown <
openscad@jordan.maileater.net> wrote:
It is certainly possible to imagine a 3D design tool, even a
programming language like OpenSCAD, that can do things like cut up an
object and then manipulate the separate solids that result.
OpenSCAD can't do that without a major overhaul, because it doesn't do
any of the geometry processing until after the program has finished running.
The immediate output from an OpenSCAD program is not geometry, not a
list of triangles, et cetera. It is a tree representation of shapes,
transformations, and the operations to be done on those shapes. Look at
Design / Display CSG Tree to see. If you write "intersection() { sphere();
cube(); }", you'll see that that's pretty much what the CSG tree shows.
All of the expressions have been evaluated, all of the loops unrolled, all
of the conditionals considered, but none of the geometry work has been
done. At that point in the processing, OpenSCAD doesn't know anything
interesting about the geometry.
It is only when the geometry work is done that it starts to be
possible to determine things like bounding boxes, like how many solids
result from a particular boolean operation, and so on - and that's too late
for the OpenSCAD program to take any action, because it's already done.
Could OpenSCAD have been designed differently, so that it did the
geometry as it was processing the program, as Cascade Studio apparently
does? Sure. But it wasn't, and that's a pretty fundamental design
decision and a big job to change.
BTW, this isn't something that's a problem with the OpenSCAD language
per se. Another environment could easily make the same design decision.
Carsten's AngelCAD has the same architecture - in fact, it does the
geometry work in a totally separate program. I don't know about Doug's
Curv - Doug?
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
--
Damien Towning
--
Damien Towning
--
Damien Towning
--
Damien Towning
--
Damien Towning
On 2021-03-27 10:10, Damien Towning wrote:
Sorry if I sounded grumpy. I've done it. I've written a 'bare-bones'
implementation using Open Cascade. It works in parallel. It optimises
the OpenSCAD. It does these things. I had it up for a year or so. Took
it down again because building house. Also had complete rethink. I
guess it is up to each of us to all go relearn the same lessons.
Do you have a good reference to a C++ API for Open Cascade to do CSG
modelling? By that I mean the 3d primitives like cube, cylinder etc. and
the booleans union, difference, intersection. Maybe even your bare-bones
implementation using Open Cascade?
Many years ago, in the mid 1990s, for a short while I was looking at
what was then called CAS.CADE, I even visited Matra Datavision outside
Paris on a couple of occasions as we tried to use CAS.CADE (a very
expensive product then) in our company. The effort failed for several
reasons, one was their insistence of using something called CDL (Cascade
Definition Language), but we wanted a C++ API. We suggested to Matra
they made a C++ API, an idea they didn't like at that point. Now, many
years later Open Cascade is open source... We ended up using ACIS from
Spatial Technology back then.
I believe the core of Open Cascade is very solid indeed, most probably
the API and documentation has improved a lot since I last visited it.
When I started looking at Constructive Solid Geometry a few years ago I
saw Cascade and Carve as to possible routes to achieve that. Carve is
used in https://github.com/arnholm/xcsg , the boolean computation engine
of AngelCAD because I found some good examples for how to do it. An
interesting thought would be to implement xcsg using Open Cascade, but
for that to happen I guess some sample Open Cascade would be needed.
Carsten Arnholm