[OpenSCAD] Discuss manifoldness, co-incident faces edges etc
nop.head at gmail.com
Wed Nov 13 03:56:38 EST 2019
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 at 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
> 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 at 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 at lists.openscad.org
> OpenSCAD mailing list
> Discuss at lists.openscad.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Discuss