M
MichaelAtOz
Wed, Nov 13, 2019 12:52 AM
Post any further stuff on this topic here please.
Admin - email* me if you need anything, or if I've done something stupid...
- click on my MichaelAtOz label, there is a link to email me.
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Sent from: http://forum.openscad.org/
Post any further stuff on this topic here please.
-----
Admin - email* me if you need anything, or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
--
Sent from: http://forum.openscad.org/
M
MichaelAtOz
Wed, Nov 13, 2019 1:02 AM
On 11/12/2019 3:15 PM, nop head wrote:
It would mean I could accidentally design non-printable object instead
of being told it was non-manifold.
Why should OpenSCAD concern itself with printability? If it does,
shouldn't it also reject ludicrously large objects or ludicrously small
ones? Shouldn't it insist that all values be multiples of the print
resolution?
Maybe it's algorithmically impossible to disambiguate triangle-soup
representations that have shared edges. (I don't know one way or
another.) If so, that should prevent exports of such objects to
triangle-soup file formats, but shouldn't prevent it for file formats
where there's no problem.
If your slicer can't handle such an object... then that's on the slicer.
OpenSCAD can't represents objects with more than 3 dimensions, with
dimensions of zero or infinity or imaginary numbers. All of these are
mathematically possible by why spend time extending OpenSCAD to
generate them when they are not physically possible?
See, what we're disagreeing on is whether the objects being discussed
are physically impossible, within the approximations implicit in 3D
printing, and in the real world at the microscopic and atomic levels.
I contend that for all practical purposes they are possible, and that
they are certainly no more impossible than objects separated by epsilon
or overlapping by epsilon.
I don't remember: were you one of the people who was arguing that
malformed polyhedra (disconnected faces, et cetera) should be allowed?
OpenSCAD mailing list
I managed to move these few posts, unfortunately Nabble moves replies too,
so it is impractical to move other on-topic posts from earlier in the
original thread
http://forum.openscad.org/User-Poll-What-do-you-want-to-see-from-OpenSCAD-development-td27802i40.html
.
However I counsel that parties may not agree, sometimes further resistance
is futile...
Admin - email* me if you need anything, or if I've done something stupid...
- click on my MichaelAtOz label, there is a link to email me.
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Sent from: http://forum.openscad.org/
JordanBrown wrote
> On 11/12/2019 3:15 PM, nop head wrote:
>> It would mean I could accidentally design non-printable object instead
>> of being told it was non-manifold.
>
> Why should OpenSCAD concern itself with printability? If it does,
> shouldn't it also reject ludicrously large objects or ludicrously small
> ones? Shouldn't it insist that all values be multiples of the print
> resolution?
>
> Maybe it's algorithmically impossible to disambiguate triangle-soup
> representations that have shared edges. (I don't know one way or
> another.) If so, that should prevent exports of such objects to
> triangle-soup file formats, but shouldn't prevent it for file formats
> where there's no problem.
>
> If your slicer can't handle such an object... then that's on the slicer.
>
>> OpenSCAD can't represents objects with more than 3 dimensions, with
>> dimensions of zero or infinity or imaginary numbers. All of these are
>> mathematically possible by why spend time extending OpenSCAD to
>> generate them when they are not physically possible?
>
> See, what we're disagreeing on is whether the objects being discussed
> are physically impossible, *within the approximations implicit in 3D
> printing, and in the real world at the microscopic and atomic levels*.
>
> I contend that for all practical purposes they are possible, and that
> they are certainly no more impossible than objects separated by epsilon
> or overlapping by epsilon.
>
> I don't remember: were you one of the people who was arguing that
> malformed polyhedra (disconnected faces, et cetera) should be allowed?
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@.openscad
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
I managed to move these few posts, unfortunately Nabble moves replies too,
so it is impractical to move other on-topic posts from earlier in the
original thread
<http://forum.openscad.org/User-Poll-What-do-you-want-to-see-from-OpenSCAD-development-td27802i40.html>
.
However I counsel that parties may not agree, sometimes further resistance
is futile...
-----
Admin - email* me if you need anything, or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
--
Sent from: http://forum.openscad.org/
M
MichaelAtOz
Wed, Nov 13, 2019 1:11 AM
My contribution.
Firstly, REPRAP style FDM/FFF 3D-printing is only one target for OpenSCAD
designs.
While there may be some cause to include something that makes printing
easier, it should not impact on other uses. So this side of the argument
says don't glue co-incident faces together.
Whether some such could be included with a control mechanism, such that it
only happens when specifically asked for is another option.
TBC...
Admin - email* me if you need anything, or if I've done something stupid...
- click on my MichaelAtOz label, there is a link to email me.
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Sent from: http://forum.openscad.org/
My contribution.
Firstly, REPRAP style FDM/FFF 3D-printing is only one target for OpenSCAD
designs.
While there may be some cause to include something that makes printing
easier, it should not impact on other uses. So this side of the argument
says don't glue co-incident faces together.
Whether some such could be included with a control mechanism, such that it
only happens when specifically asked for is another option.
TBC...
-----
Admin - email* me if you need anything, or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
--
Sent from: http://forum.openscad.org/
M
MichaelAtOz
Wed, Nov 13, 2019 1:32 AM
When two co-incident faces are parallel to a primary axis it is likely that
the geometry algorithms could conclude that they are indeed the same.
Once something is rotated (or curved), floating point inaccuracies makes
that unlikely, unless you then inject Fudge in the algorithm. There is
already a degree of Fudge in OpenSCAD, grids, usually that doesn't cause
issues, and sometimes makes things easier, but they have bitten me in the
arse at times.
What if you want to make two parts, but really close together, like a
one-print pair of pliers, but Fudge thinks the two parts are one?
I don't support injecting other Fudginess.
Thus, it falls to the programmer to indicate their desire for Fudge, some
people say epsilon, I like smidgeon.
Admin - email* me if you need anything, or if I've done something stupid...
- click on my MichaelAtOz label, there is a link to email me.
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
--
Sent from: http://forum.openscad.org/
When two co-incident faces are parallel to a primary axis it is likely that
the geometry algorithms could conclude that they are indeed the same.
Once something is rotated (or curved), floating point inaccuracies makes
that unlikely, unless you then inject Fudge in the algorithm. There is
already a degree of Fudge in OpenSCAD, grids, usually that doesn't cause
issues, and sometimes makes things easier, but they have bitten me in the
arse at times.
What if you want to make two parts, but really close together, like a
one-print pair of pliers, but Fudge thinks the two parts are one?
I don't support injecting other Fudginess.
Thus, it falls to the programmer to indicate their desire for Fudge, some
people say epsilon, I like smidgeon.
-----
Admin - email* me if you need anything, or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
--
Sent from: http://forum.openscad.org/
M
MichaelAtOz
Wed, Nov 13, 2019 2:25 AM
However, when I was learning, manifoldness, and self-intersections, was a
hinderance, so having something to make life easier for beginner or casual
users could be worthwhile.
That then goes back to some means to tell OpenSCAD that you'd like it to
help out.
So when do we need help?
Classic non-manifold:
a. share a point
cube(10);
translate([-10,-10,-10]) cube(10);
b. share an edge
cube(10);
translate([-10,-10,0]) cube(10);
c. share a face - at an angle - not always a problem
rotate([PI,PI,PI]) {
translate([ 0,-10, 0]) cube(10);
translate([ 10,-10, 0]) cube(10);
}
Then there are probably many others.
Can we help with these?
Can they be readily identified in more complex geometry?
Would there be easily categorised resolution strategies/algorithms?
Admin - email* me if you need anything, or if I've done something stupid...
- click on my MichaelAtOz label, there is a link to email me.
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
--
Sent from: http://forum.openscad.org/
However, when I was learning, manifoldness, and self-intersections, was a
hinderance, so having something to make life easier for beginner or casual
users could be worthwhile.
That then goes back to some means to tell OpenSCAD that you'd like it to
help out.
So when do we need help?
Classic non-manifold:
a. share a point
cube(10);
translate([-10,-10,-10]) cube(10);
b. share an edge
cube(10);
translate([-10,-10,0]) cube(10);
c. share a face - at an angle - not always a problem
rotate([PI,PI,PI]) {
translate([ 0,-10, 0]) cube(10);
translate([ 10,-10, 0]) cube(10);
}
Then there are probably many others.
Can we help with these?
Can they be readily identified in more complex geometry?
Would there be easily categorised resolution strategies/algorithms?
-----
Admin - email* me if you need anything, or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
--
Sent from: http://forum.openscad.org/
DM
Doug Moen
Wed, Nov 13, 2019 3:17 AM
It would mean I could accidentally design non-printable object instead
of being told it was non-manifold.
This has nothing to do with my original request.
What I want is better support for the 3MF file format.
The 3MF file format provides a legal, supported way to encode a model containing two cubes that touch along an edge, but OpenSCAD doesn't support this feature, in the way that 3MF files are currently written. So I'd like the 3MF export code to be fixed, so that when I export such a model, it is written as a valid 3MF file.
I don't think that better 3MF export will interfere with nop head's ability to use OpenSCAD.
The other thing I'd like is better 3MF import, with the assurance that if a valid 3MF model is imported, then the topology of the model is preserved, so that when the model is presented to CGAL for boolean operations, I don't get errors. Right now, during 3MF import, the model is converted to a PolySet, which is polygon soup. The topology information is discarded, and that's needed to convert the model to a Nef Polyhedron that CGAL can perform boolean operations on without reporting an error.
I don't think that better 3MF import will interfere with nop head's ability to use OpenSCAD.
nop head wrote:
> It would mean I could accidentally design non-printable object instead
> of being told it was non-manifold.
This has nothing to do with my original request.
What I want is better support for the 3MF file format.
The 3MF file format provides a legal, supported way to encode a model containing two cubes that touch along an edge, but OpenSCAD doesn't support this feature, in the way that 3MF files are currently written. So I'd like the 3MF export code to be fixed, so that when I export such a model, it is written as a valid 3MF file.
I don't think that better 3MF export will interfere with nop head's ability to use OpenSCAD.
The other thing I'd like is better 3MF import, with the assurance that if a *valid* 3MF model is imported, then the topology of the model is preserved, so that when the model is presented to CGAL for boolean operations, I don't get errors. Right now, during 3MF import, the model is converted to a PolySet, which is polygon soup. The topology information is discarded, and that's needed to convert the model to a Nef Polyhedron that CGAL can perform boolean operations on without reporting an error.
I don't think that better 3MF import will interfere with nop head's ability to use OpenSCAD.
NH
nop head
Wed, Nov 13, 2019 8:34 AM
Yes OpenSCAD uses a Polygon soup as one of its internal representations, so
it can't handle non-manifold shapes just the same as STL. I don't wee why
that is a problem. What practical use are non-manifold shapes?
If you send two cubes with a shared edge to a slicer what do you expect it
to produce? Since it can't generate gcode for an object with a shared edge
it probably will either make two separate cubes, each with the own outline
or perhaps two joined cubes with a single outline. Why send a design that
can never be printed ever with any technology ever, even in the distance
future because it doesn't make sense at a physical level. Why not be forced
to send a model that explicitly indicates whether it should be two shapes
or one? Then there are no surprises.
I once helped out at a MiniMakerfair printing some giveaway objects. I was
given an STL file and just sliced for my machine and filament and started
printing. I thought the design was very weak but I had printed dozens
before I realised it contained self intersections and when sliced with a
different sliced it made a totally different object.. Whatever CAD tools
was used didn't automatically union objects and allowed a non-manifold
design to be sent to an STL file.
On Wed, 13 Nov 2019 at 03:18, Doug Moen doug@moens.org wrote:
It would mean I could accidentally design non-printable object instead
of being told it was non-manifold.
This has nothing to do with my original request.
What I want is better support for the 3MF file format.
The 3MF file format provides a legal, supported way to encode a model
containing two cubes that touch along an edge, but OpenSCAD doesn't support
this feature, in the way that 3MF files are currently written. So I'd like
the 3MF export code to be fixed, so that when I export such a model, it is
written as a valid 3MF file.
I don't think that better 3MF export will interfere with nop head's
ability to use OpenSCAD.
The other thing I'd like is better 3MF import, with the assurance that if
a valid 3MF model is imported, then the topology of the model is
preserved, so that when the model is presented to CGAL for boolean
operations, I don't get errors. Right now, during 3MF import, the model is
converted to a PolySet, which is polygon soup. The topology information is
discarded, and that's needed to convert the model to a Nef Polyhedron that
CGAL can perform boolean operations on without reporting an error.
I don't think that better 3MF import will interfere with nop head's
ability to use OpenSCAD.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Yes OpenSCAD uses a Polygon soup as one of its internal representations, so
it can't handle non-manifold shapes just the same as STL. I don't wee why
that is a problem. What practical use are non-manifold shapes?
If you send two cubes with a shared edge to a slicer what do you expect it
to produce? Since it can't generate gcode for an object with a shared edge
it probably will either make two separate cubes, each with the own outline
or perhaps two joined cubes with a single outline. Why send a design that
can never be printed ever with any technology ever, even in the distance
future because it doesn't make sense at a physical level. Why not be forced
to send a model that explicitly indicates whether it should be two shapes
or one? Then there are no surprises.
I once helped out at a MiniMakerfair printing some giveaway objects. I was
given an STL file and just sliced for my machine and filament and started
printing. I thought the design was very weak but I had printed dozens
before I realised it contained self intersections and when sliced with a
different sliced it made a totally different object.. Whatever CAD tools
was used didn't automatically union objects and allowed a non-manifold
design to be sent to an STL file.
On Wed, 13 Nov 2019 at 03:18, Doug Moen <doug@moens.org> wrote:
>
> nop head wrote:
> > It would mean I could accidentally design non-printable object instead
> > of being told it was non-manifold.
>
> This has nothing to do with my original request.
>
> What I want is better support for the 3MF file format.
>
> The 3MF file format provides a legal, supported way to encode a model
> containing two cubes that touch along an edge, but OpenSCAD doesn't support
> this feature, in the way that 3MF files are currently written. So I'd like
> the 3MF export code to be fixed, so that when I export such a model, it is
> written as a valid 3MF file.
>
> I don't think that better 3MF export will interfere with nop head's
> ability to use OpenSCAD.
>
> The other thing I'd like is better 3MF import, with the assurance that if
> a *valid* 3MF model is imported, then the topology of the model is
> preserved, so that when the model is presented to CGAL for boolean
> operations, I don't get errors. Right now, during 3MF import, the model is
> converted to a PolySet, which is polygon soup. The topology information is
> discarded, and that's needed to convert the model to a Nef Polyhedron that
> CGAL can perform boolean operations on without reporting an error.
>
> I don't think that better 3MF import will interfere with nop head's
> ability to use OpenSCAD.
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
AC
A. Craig West
Wed, Nov 13, 2019 8:49 AM
Although I primarily use OpenSCAD for creating 3D printable files, I
consider it a programmatic model generator. There are a great many use
cases for the software where the desired output is essentially an abstract
model. One example in my own experience is where I have a design which is a
cooling duct for a 3d printer. I use openSCAD both to generate the STL for
the duct, but also to generate a model representing the airspace inside the
duct, which I import into another program to model the actual airflow
through it at various fan speeds.
Other use cases are to generate mathematical models for illustrative
purposes. In both of these cases, arbitrarily restricting the output to
'realisable' objects restricts my ability to produce the output I need.
This restriction appears to be rooted in the implicit assumption that the
final output will always be to an STL file, but as was pointed out, other
formats have well defined behaviour for many of the edge cases that are
explicitly blocked in openSCAD.
Colour is another attribute which is arbitrarily discarded when a model is
rendered, apparently because STL doesn't support it.
Related issues come into play when you wish to use openSCAD to produce
output for a laser cutter. In that case, due to the current work flow used
by the majority of people doing laser cutting, you need to output 2d
representations of the laser path. It's all well and good to model the
actual shape you wish to produce, but if what you need is tool paths, then
that doesn't actually do you much good... Laser cutting is an area where
what you need is more CAM oriented than CAD. Whenever you are producing an
actual physical output, eventually you need software that produces a more
abstract tool path, and the actual physical tool determines what will be
output. The job of a slicer, for example, is to predict what the actual
extruder will produce, and try to turn the 'realisable' model into tool
paths that will create that shape, but there is a very definite use case
for allowing the actual designer to just create the path and see what
happens...
I have spent more years writing industrial CAD and CAM software than the
majority of people on this list have been alive, I suspect. There are
always use cases that were not anticipated by the writer of the software.
It is best to not enforce restrictions based on one use case on every user
On Tue, 12 Nov 2019, 22:18 Doug Moen, doug@moens.org wrote:
It would mean I could accidentally design non-printable object instead
of being told it was non-manifold.
This has nothing to do with my original request.
What I want is better support for the 3MF file format.
The 3MF file format provides a legal, supported way to encode a model
containing two cubes that touch along an edge, but OpenSCAD doesn't support
this feature, in the way that 3MF files are currently written. So I'd like
the 3MF export code to be fixed, so that when I export such a model, it is
written as a valid 3MF file.
I don't think that better 3MF export will interfere with nop head's
ability to use OpenSCAD.
The other thing I'd like is better 3MF import, with the assurance that if
a valid 3MF model is imported, then the topology of the model is
preserved, so that when the model is presented to CGAL for boolean
operations, I don't get errors. Right now, during 3MF import, the model is
converted to a PolySet, which is polygon soup. The topology information is
discarded, and that's needed to convert the model to a Nef Polyhedron that
CGAL can perform boolean operations on without reporting an error.
I don't think that better 3MF import will interfere with nop head's
ability to use OpenSCAD.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Although I primarily use OpenSCAD for creating 3D printable files, I
consider it a programmatic model generator. There are a great many use
cases for the software where the desired output is essentially an abstract
model. One example in my own experience is where I have a design which is a
cooling duct for a 3d printer. I use openSCAD both to generate the STL for
the duct, but also to generate a model representing the airspace inside the
duct, which I import into another program to model the actual airflow
through it at various fan speeds.
Other use cases are to generate mathematical models for illustrative
purposes. In both of these cases, arbitrarily restricting the output to
'realisable' objects restricts my ability to produce the output I need.
This restriction appears to be rooted in the implicit assumption that the
final output will always be to an STL file, but as was pointed out, other
formats have well defined behaviour for many of the edge cases that are
explicitly blocked in openSCAD.
Colour is another attribute which is arbitrarily discarded when a model is
rendered, apparently because STL doesn't support it.
Related issues come into play when you wish to use openSCAD to produce
output for a laser cutter. In that case, due to the current work flow used
by the majority of people doing laser cutting, you need to output 2d
representations of the laser path. It's all well and good to model the
actual shape you wish to produce, but if what you need is tool paths, then
that doesn't actually do you much good... Laser cutting is an area where
what you need is more CAM oriented than CAD. Whenever you are producing an
actual physical output, eventually you need software that produces a more
abstract tool path, and the actual physical tool determines what will be
output. The job of a slicer, for example, is to predict what the actual
extruder will produce, and try to turn the 'realisable' model into tool
paths that will create that shape, but there is a very definite use case
for allowing the actual designer to just create the path and see what
happens...
I have spent more years writing industrial CAD and CAM software than the
majority of people on this list have been alive, I suspect. There are
always use cases that were not anticipated by the writer of the software.
It is best to not enforce restrictions based on one use case on every user
On Tue, 12 Nov 2019, 22:18 Doug Moen, <doug@moens.org> wrote:
>
> nop head wrote:
> > It would mean I could accidentally design non-printable object instead
> > of being told it was non-manifold.
>
> This has nothing to do with my original request.
>
> What I want is better support for the 3MF file format.
>
> The 3MF file format provides a legal, supported way to encode a model
> containing two cubes that touch along an edge, but OpenSCAD doesn't support
> this feature, in the way that 3MF files are currently written. So I'd like
> the 3MF export code to be fixed, so that when I export such a model, it is
> written as a valid 3MF file.
>
> I don't think that better 3MF export will interfere with nop head's
> ability to use OpenSCAD.
>
> The other thing I'd like is better 3MF import, with the assurance that if
> a *valid* 3MF model is imported, then the topology of the model is
> preserved, so that when the model is presented to CGAL for boolean
> operations, I don't get errors. Right now, during 3MF import, the model is
> converted to a PolySet, which is polygon soup. The topology information is
> discarded, and that's needed to convert the model to a Nef Polyhedron that
> CGAL can perform boolean operations on without reporting an error.
>
> I don't think that better 3MF import will interfere with nop head's
> ability to use OpenSCAD.
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
NH
nop head
Wed, Nov 13, 2019 8:56 AM
OpenSCAD isn't artificially enforcing a restriction. It is implemented in a
way that doesn't allow non-manifold geometry. It would be a substantial
change to make it work, only to unleash more designs on Thingiverse, etc
that are ambiguous.
On Wed, 13 Nov 2019 at 08:50, A. Craig West acraigwest@gmail.com wrote:
Although I primarily use OpenSCAD for creating 3D printable files, I
consider it a programmatic model generator. There are a great many use
cases for the software where the desired output is essentially an abstract
model. One example in my own experience is where I have a design which is a
cooling duct for a 3d printer. I use openSCAD both to generate the STL for
the duct, but also to generate a model representing the airspace inside the
duct, which I import into another program to model the actual airflow
through it at various fan speeds.
Other use cases are to generate mathematical models for illustrative
purposes. In both of these cases, arbitrarily restricting the output to
'realisable' objects restricts my ability to produce the output I need.
This restriction appears to be rooted in the implicit assumption that the
final output will always be to an STL file, but as was pointed out, other
formats have well defined behaviour for many of the edge cases that are
explicitly blocked in openSCAD.
Colour is another attribute which is arbitrarily discarded when a model is
rendered, apparently because STL doesn't support it.
Related issues come into play when you wish to use openSCAD to produce
output for a laser cutter. In that case, due to the current work flow used
by the majority of people doing laser cutting, you need to output 2d
representations of the laser path. It's all well and good to model the
actual shape you wish to produce, but if what you need is tool paths, then
that doesn't actually do you much good... Laser cutting is an area where
what you need is more CAM oriented than CAD. Whenever you are producing an
actual physical output, eventually you need software that produces a more
abstract tool path, and the actual physical tool determines what will be
output. The job of a slicer, for example, is to predict what the actual
extruder will produce, and try to turn the 'realisable' model into tool
paths that will create that shape, but there is a very definite use case
for allowing the actual designer to just create the path and see what
happens...
I have spent more years writing industrial CAD and CAM software than the
majority of people on this list have been alive, I suspect. There are
always use cases that were not anticipated by the writer of the software.
It is best to not enforce restrictions based on one use case on every user
On Tue, 12 Nov 2019, 22:18 Doug Moen, doug@moens.org wrote:
It would mean I could accidentally design non-printable object instead
of being told it was non-manifold.
This has nothing to do with my original request.
What I want is better support for the 3MF file format.
The 3MF file format provides a legal, supported way to encode a model
containing two cubes that touch along an edge, but OpenSCAD doesn't support
this feature, in the way that 3MF files are currently written. So I'd like
the 3MF export code to be fixed, so that when I export such a model, it is
written as a valid 3MF file.
I don't think that better 3MF export will interfere with nop head's
ability to use OpenSCAD.
The other thing I'd like is better 3MF import, with the assurance that if
a valid 3MF model is imported, then the topology of the model is
preserved, so that when the model is presented to CGAL for boolean
operations, I don't get errors. Right now, during 3MF import, the model is
converted to a PolySet, which is polygon soup. The topology information is
discarded, and that's needed to convert the model to a Nef Polyhedron that
CGAL can perform boolean operations on without reporting an error.
I don't think that better 3MF import will interfere with nop head's
ability to use OpenSCAD.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD isn't artificially enforcing a restriction. It is implemented in a
way that doesn't allow non-manifold geometry. It would be a substantial
change to make it work, only to unleash more designs on Thingiverse, etc
that are ambiguous.
On Wed, 13 Nov 2019 at 08:50, A. Craig West <acraigwest@gmail.com> wrote:
> Although I primarily use OpenSCAD for creating 3D printable files, I
> consider it a programmatic model generator. There are a great many use
> cases for the software where the desired output is essentially an abstract
> model. One example in my own experience is where I have a design which is a
> cooling duct for a 3d printer. I use openSCAD both to generate the STL for
> the duct, but also to generate a model representing the airspace inside the
> duct, which I import into another program to model the actual airflow
> through it at various fan speeds.
> Other use cases are to generate mathematical models for illustrative
> purposes. In both of these cases, arbitrarily restricting the output to
> 'realisable' objects restricts my ability to produce the output I need.
> This restriction appears to be rooted in the implicit assumption that the
> final output will always be to an STL file, but as was pointed out, other
> formats have well defined behaviour for many of the edge cases that are
> explicitly blocked in openSCAD.
> Colour is another attribute which is arbitrarily discarded when a model is
> rendered, apparently because STL doesn't support it.
> Related issues come into play when you wish to use openSCAD to produce
> output for a laser cutter. In that case, due to the current work flow used
> by the majority of people doing laser cutting, you need to output 2d
> representations of the laser path. It's all well and good to model the
> actual shape you wish to produce, but if what you need is tool paths, then
> that doesn't actually do you much good... Laser cutting is an area where
> what you need is more CAM oriented than CAD. Whenever you are producing an
> actual physical output, eventually you need software that produces a more
> abstract tool path, and the actual physical tool determines what will be
> output. The job of a slicer, for example, is to predict what the actual
> extruder will produce, and try to turn the 'realisable' model into tool
> paths that will create that shape, but there is a very definite use case
> for allowing the actual designer to just create the path and see what
> happens...
> I have spent more years writing industrial CAD and CAM software than the
> majority of people on this list have been alive, I suspect. There are
> always use cases that were not anticipated by the writer of the software.
> It is best to not enforce restrictions based on one use case on every user
>
> On Tue, 12 Nov 2019, 22:18 Doug Moen, <doug@moens.org> wrote:
>
>>
>> nop head wrote:
>> > It would mean I could accidentally design non-printable object instead
>> > of being told it was non-manifold.
>>
>> This has nothing to do with my original request.
>>
>> What I want is better support for the 3MF file format.
>>
>> The 3MF file format provides a legal, supported way to encode a model
>> containing two cubes that touch along an edge, but OpenSCAD doesn't support
>> this feature, in the way that 3MF files are currently written. So I'd like
>> the 3MF export code to be fixed, so that when I export such a model, it is
>> written as a valid 3MF file.
>>
>> I don't think that better 3MF export will interfere with nop head's
>> ability to use OpenSCAD.
>>
>> The other thing I'd like is better 3MF import, with the assurance that if
>> a *valid* 3MF model is imported, then the topology of the model is
>> preserved, so that when the model is presented to CGAL for boolean
>> operations, I don't get errors. Right now, during 3MF import, the model is
>> converted to a PolySet, which is polygon soup. The topology information is
>> discarded, and that's needed to convert the model to a Nef Polyhedron that
>> CGAL can perform boolean operations on without reporting an error.
>>
>> I don't think that better 3MF import will interfere with nop head's
>> ability to use OpenSCAD.
>>
>> _______________________________________________
>> 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
>
A
arnholm@arnholm.org
Wed, Nov 13, 2019 9:58 AM
On 2019-11-13 09:56, nop head wrote:
OpenSCAD isn't artificially enforcing a restriction. It is implemented
in a way that doesn't allow non-manifold geometry.
Some use cases require non-manifold topology.
This type of software is not just for 3d printing even if that was the
origin.
Carsten Arnholm
On 2019-11-13 09:56, nop head wrote:
> OpenSCAD isn't artificially enforcing a restriction. It is implemented
> in a way that doesn't allow non-manifold geometry.
Some use cases *require* non-manifold topology.
This type of software is not just for 3d printing even if that was the
origin.
Carsten Arnholm
