Discuss manifoldness, co-incident faces edges etc

classic Classic list List threaded Threaded
97 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Discuss manifoldness, co-incident faces edges etc

MichaelAtOz
Administrator
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/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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.
Reply | Threaded
Open this post in threaded view
|

Re: User Poll: What do you want to see from OpenSCAD development?

JordanBrown
I think we'll need to agree to disagree here.

I think it's inconvenient and awkward, and it's difficult to explain why shared edges are a problem and how to diagnose and correct them.  I know that it's a problem for me.

It doesn't bother you.  OK.

Supposing, hypothetically, that we had somebody who was able to spend the time to make this case not be an error, is there any reason why they *should not* do that work?  Is there any way that that flexibility would impair your ability to do what you want to do?


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: User Poll: What do you want to see from OpenSCAD development?

nophead
It would mean I could accidentally design non-printable object instead of being told it was non-manifold. Also it would waste developer time changing OpenSCAD to be able to represents non real objects.

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?

On Tue, 12 Nov 2019 at 23:10, Jordan Brown <[hidden email]> wrote:
I think we'll need to agree to disagree here.

I think it's inconvenient and awkward, and it's difficult to explain why shared edges are a problem and how to diagnose and correct them.  I know that it's a problem for me.

It doesn't bother you.  OK.

Supposing, hypothetically, that we had somebody who was able to spend the time to make this case not be an error, is there any reason why they *should not* do that work?  Is there any way that that flexibility would impair your ability to do what you want to do?


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: User Poll: What do you want to see from OpenSCAD development?

JordanBrown
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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Discuss manifoldness, co-incident faces edges etc

MichaelAtOz
Administrator
In reply to this post by MichaelAtOz
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/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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.
Reply | Threaded
Open this post in threaded view
|

Re: Discuss manifoldness, co-incident faces edges etc

MichaelAtOz
Administrator
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/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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.
Reply | Threaded
Open this post in threaded view
|

Re: Discuss manifoldness, co-incident faces edges etc

MichaelAtOz
Administrator
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/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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.
Reply | Threaded
Open this post in threaded view
|

Re: Discuss manifoldness, co-incident faces edges etc

MichaelAtOz
Administrator
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/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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.
Reply | Threaded
Open this post in threaded view
|

Re: Discuss manifoldness, co-incident faces edges etc

doug.moen
In reply to this post by MichaelAtOz

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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Discuss manifoldness, co-incident faces edges etc

nophead
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 <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Discuss manifoldness, co-incident faces edges etc

acwest
In reply to this post by doug.moen
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, <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Discuss manifoldness, co-incident faces edges etc

nophead
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 <[hidden email]> 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, <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Discuss manifoldness, co-incident faces edges etc

cacb
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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Discuss manifoldness, co-incident faces edges etc

doug.moen
In reply to this post by nophead
On Wed, Nov 13, 2019, at 3:34 AM, nop head wrote:
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? 

I'm not asking for OpenSCAD to support non-manifold shapes, I'm asking for OpenSCAD to more fully support the 3MF file format. The practical use is the ability to download an arbitrary 3MF file from the internet, transform it in some way, export back to 3MF, and then print the results. As long as the 3MF file contains a valid mesh, as defined by the 3MF standard, I expect this to work.

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... 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.

No, this is a straw man argument. I'm asking for better 3MF support. If I send a valid 3MF file to a slicer, then I expect it to print the model without any problem. The 3MF standard provides unambiguous instructions on how to slice a valid 3MF mesh.

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.

This is why you should embrace the 3MF standard. It contains rules defining what is and is not a valid mesh. There is open source code for rapidly validating a 3MF mesh. Given a valid mesh, there are rules that define exactly how the mesh should be sliced. This means that model files can be portable between slicers. This also means that we can test a slicer or 3D modelling tool for conformance to the 3MF standard, and report a bug if it misinterprets a valid model. Unambiguous rules, validation, and model portability are a big selling point of 3MF.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Discuss manifoldness, co-incident faces edges etc

nophead
>I'm not asking for OpenSCAD to support non-manifold shapes, I'm asking for OpenSCAD to more fully support the 3MF file format.  

Isn't that a self contradictory statement? If 3MF supports non-manifold shapes then OpenSCAD will need to support them in order to read them. OpenSCAD only supports manifolds for the exact same reason STL files only support them. Its mesh representation is a polygon soup.

On Wed, 13 Nov 2019 at 11:40, Doug Moen <[hidden email]> wrote:
On Wed, Nov 13, 2019, at 3:34 AM, nop head wrote:
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? 

I'm not asking for OpenSCAD to support non-manifold shapes, I'm asking for OpenSCAD to more fully support the 3MF file format. The practical use is the ability to download an arbitrary 3MF file from the internet, transform it in some way, export back to 3MF, and then print the results. As long as the 3MF file contains a valid mesh, as defined by the 3MF standard, I expect this to work.

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... 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.

No, this is a straw man argument. I'm asking for better 3MF support. If I send a valid 3MF file to a slicer, then I expect it to print the model without any problem. The 3MF standard provides unambiguous instructions on how to slice a valid 3MF mesh.

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.

This is why you should embrace the 3MF standard. It contains rules defining what is and is not a valid mesh. There is open source code for rapidly validating a 3MF mesh. Given a valid mesh, there are rules that define exactly how the mesh should be sliced. This means that model files can be portable between slicers. This also means that we can test a slicer or 3D modelling tool for conformance to the 3MF standard, and report a bug if it misinterprets a valid model. Unambiguous rules, validation, and model portability are a big selling point of 3MF.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Discuss manifoldness, co-incident faces edges etc

acwest
STL certainly supports non-manifold shapes, it has pretty much no validity checking at all... The problem is they don't tend to be very meaningful 😊

On Wed, 13 Nov 2019, 07:23 nop head, <[hidden email]> wrote:
>I'm not asking for OpenSCAD to support non-manifold shapes, I'm asking for OpenSCAD to more fully support the 3MF file format.  

Isn't that a self contradictory statement? If 3MF supports non-manifold shapes then OpenSCAD will need to support them in order to read them. OpenSCAD only supports manifolds for the exact same reason STL files only support them. Its mesh representation is a polygon soup.

On Wed, 13 Nov 2019 at 11:40, Doug Moen <[hidden email]> wrote:
On Wed, Nov 13, 2019, at 3:34 AM, nop head wrote:
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? 

I'm not asking for OpenSCAD to support non-manifold shapes, I'm asking for OpenSCAD to more fully support the 3MF file format. The practical use is the ability to download an arbitrary 3MF file from the internet, transform it in some way, export back to 3MF, and then print the results. As long as the 3MF file contains a valid mesh, as defined by the 3MF standard, I expect this to work.

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... 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.

No, this is a straw man argument. I'm asking for better 3MF support. If I send a valid 3MF file to a slicer, then I expect it to print the model without any problem. The 3MF standard provides unambiguous instructions on how to slice a valid 3MF mesh.

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.

This is why you should embrace the 3MF standard. It contains rules defining what is and is not a valid mesh. There is open source code for rapidly validating a 3MF mesh. Given a valid mesh, there are rules that define exactly how the mesh should be sliced. This means that model files can be portable between slicers. This also means that we can test a slicer or 3D modelling tool for conformance to the 3MF standard, and report a bug if it misinterprets a valid model. Unambiguous rules, validation, and model portability are a big selling point of 3MF.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Discuss manifoldness, co-incident faces edges etc

nophead
Well you could say it supports them write only. It only works as a non-lossy representation when the contents are manifold. The reason it has lasted so long as a format for 3D printing is that is all that is needed. It's a shame the standard didn't contain that rule.

On Wed, 13 Nov 2019 at 12:41, A. Craig West <[hidden email]> wrote:
STL certainly supports non-manifold shapes, it has pretty much no validity checking at all... The problem is they don't tend to be very meaningful 😊

On Wed, 13 Nov 2019, 07:23 nop head, <[hidden email]> wrote:
>I'm not asking for OpenSCAD to support non-manifold shapes, I'm asking for OpenSCAD to more fully support the 3MF file format.  

Isn't that a self contradictory statement? If 3MF supports non-manifold shapes then OpenSCAD will need to support them in order to read them. OpenSCAD only supports manifolds for the exact same reason STL files only support them. Its mesh representation is a polygon soup.

On Wed, 13 Nov 2019 at 11:40, Doug Moen <[hidden email]> wrote:
On Wed, Nov 13, 2019, at 3:34 AM, nop head wrote:
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? 

I'm not asking for OpenSCAD to support non-manifold shapes, I'm asking for OpenSCAD to more fully support the 3MF file format. The practical use is the ability to download an arbitrary 3MF file from the internet, transform it in some way, export back to 3MF, and then print the results. As long as the 3MF file contains a valid mesh, as defined by the 3MF standard, I expect this to work.

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... 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.

No, this is a straw man argument. I'm asking for better 3MF support. If I send a valid 3MF file to a slicer, then I expect it to print the model without any problem. The 3MF standard provides unambiguous instructions on how to slice a valid 3MF mesh.

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.

This is why you should embrace the 3MF standard. It contains rules defining what is and is not a valid mesh. There is open source code for rapidly validating a 3MF mesh. Given a valid mesh, there are rules that define exactly how the mesh should be sliced. This means that model files can be portable between slicers. This also means that we can test a slicer or 3D modelling tool for conformance to the 3MF standard, and report a bug if it misinterprets a valid model. Unambiguous rules, validation, and model portability are a big selling point of 3MF.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Discuss manifoldness, co-incident faces edges etc

Max Bond
I think it would be helpful to enumerate the use cases for which nonmanifold geometry is desired/required, so we can look at that list and ask; is this what OpenSCAD is for? What do these things have in common? Would they all be served well by 3MF etc?

I think one of OpenSCAD's strengths is that it has chosen a narrow objective & focused on fulfilling that need well. It doesn't propose to be a Fusion or FreeCAD replacement; it's a parametric, CSG design tool, with some GUI sugar to assist in that.

I don't totally understand what it is people want this for, but I think it's important to ask; is this the mission of OpenSCAD? Or is this something for another project?

Best,
Max

On Wed, Nov 13, 2019, 7:00 AM nop head <[hidden email]> wrote:
Well you could say it supports them write only. It only works as a non-lossy representation when the contents are manifold. The reason it has lasted so long as a format for 3D printing is that is all that is needed. It's a shame the standard didn't contain that rule.

On Wed, 13 Nov 2019 at 12:41, A. Craig West <[hidden email]> wrote:
STL certainly supports non-manifold shapes, it has pretty much no validity checking at all... The problem is they don't tend to be very meaningful 😊

On Wed, 13 Nov 2019, 07:23 nop head, <[hidden email]> wrote:
>I'm not asking for OpenSCAD to support non-manifold shapes, I'm asking for OpenSCAD to more fully support the 3MF file format.  

Isn't that a self contradictory statement? If 3MF supports non-manifold shapes then OpenSCAD will need to support them in order to read them. OpenSCAD only supports manifolds for the exact same reason STL files only support them. Its mesh representation is a polygon soup.

On Wed, 13 Nov 2019 at 11:40, Doug Moen <[hidden email]> wrote:
On Wed, Nov 13, 2019, at 3:34 AM, nop head wrote:
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? 

I'm not asking for OpenSCAD to support non-manifold shapes, I'm asking for OpenSCAD to more fully support the 3MF file format. The practical use is the ability to download an arbitrary 3MF file from the internet, transform it in some way, export back to 3MF, and then print the results. As long as the 3MF file contains a valid mesh, as defined by the 3MF standard, I expect this to work.

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... 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.

No, this is a straw man argument. I'm asking for better 3MF support. If I send a valid 3MF file to a slicer, then I expect it to print the model without any problem. The 3MF standard provides unambiguous instructions on how to slice a valid 3MF mesh.

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.

This is why you should embrace the 3MF standard. It contains rules defining what is and is not a valid mesh. There is open source code for rapidly validating a 3MF mesh. Given a valid mesh, there are rules that define exactly how the mesh should be sliced. This means that model files can be portable between slicers. This also means that we can test a slicer or 3D modelling tool for conformance to the 3MF standard, and report a bug if it misinterprets a valid model. Unambiguous rules, validation, and model portability are a big selling point of 3MF.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Discuss manifoldness, co-incident faces edges etc

thehans
In reply to this post by acwest
On Wed, Nov 13, 2019 at 2:50 AM A. Craig West <[hidden email]> wrote:
> I have spent more years writing industrial CAD and CAM software than the majority of people on this list have been alive, I suspect.

I suspect you underestimate the age of people on this list, but either
way Pull Requests are welcome if you have any concrete solutions to
the problems involved.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Discuss manifoldness, co-incident faces edges etc

Ronaldo
In reply to this post by nophead
 nop head <[hidden email]> wrote:
>I'm not asking for OpenSCAD to support non-manifold shapes, I'm asking for OpenSCAD to more fully support the 3MF file format.  

Isn't that a self contradictory statement? If 3MF supports non-manifold shapes then OpenSCAD will need to support them in order to read them. OpenSCAD only supports manifolds for the exact same reason STL files only support them. Its mesh representation is a polygon soup.

It is not. I see contradiction in your arguments favoring STL file format against 3MF when this last format is able to enforce the 2-manifold condition. It is insane to me that a CAD program has to discard all topological information present in its internal structures to write a STL file to be consumed by other programs that will have to guess the topology from an unstructured pool of triangles in order to do their job. If something is representable by a 3MF file but not admissible by the reader it can just reject the file as OpenSCAD does with malformed (meaning non 2-manifold) STL files. Reading and writing a well structured file format should be not only easier but safer.

The reason it has lasted so long as a format for 3D printing is that is all that is needed. It's a shame the standard didn't contain that rule.  

It has lasted so long because it was the first (1987) and unique file format available at the beginning of rapid prototyping and not by its merits. Other formats, like  3MF (2015), AMF (2011), are much more recent. It is a shame that STL is still in use.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
12345