damaged STL file?

classic Classic list List threaded Threaded
39 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: damaged STL file?

doug.moen
3MF is a superior alternative to AMF.
* It is less ambiguous, due to explicit rules on how to interpret certain non-manifold models that AMF leaves undefined. Specifically, it allows self intersection and overlapping triangles. Here's one reason why this is important. The union operation is not closed with respect to manifold meshes. If you union two manifold meshes, the result may not be manifold. I feel this is actually a defect in the definition of "manifold", because I think it's intolerable if you can't union two arbitrary shapes and be guaranteed to get a meaningful result. In any case, 3MF fixes this by defining the result of the union of two manifold meshes to be a valid 3MF model in all cases. AMF does not do this.
* 3MF is an open standard, and AMF is not (you have to pay money for a copy of the AMF standard, and you can't redistribute your copy of this secret, proprietary information.)
* 3MF has an open source library on github which interprets the standard.
* Nop head asks "how do you print a non-manifold object?". Well, the 3MF standard and the associated library implementation gives some unambiguous answers to that, for the cases that I mention above.

OpenSCAD has a 3MF implementation underway: https://github.com/openscad/openscad/pull/1802.

The Cura slicer used to have an AMF implementation, but got rid of it, and they now implement 3MF instead.

I feel it is not productive or useful at this point to design yet another mesh file format.

On 26 February 2018 at 14:44, Carsten Arnholm <[hidden email]> wrote:
On 26. feb. 2018 18:35, Jordan Brown wrote:
Are there other file formats that would be better?  Getting designers like OpenSCAD and slicers to *both* implement something new would be tough, but if there are clear benefits maybe it could be done.

Yes, there are better formats (see below), but STL seems so entrenched that it is very hard to get wide enough support for anything else. Some requirements to a non-STL format I guess would be

1) Suited for polyhedron exchange between CAD applications, not just CAD to slicers.

2) Unambiguous format, with explicit topology

3) Efficient binary storage, plus equivalent ascii text version with same info. Binary/Ascii should be transparent to users.

4) It must be *very* simple.

etc.

OpenSCAD already support other 3D formats in addition to STL

OFF - http://paulbourke.net/dataformats/off/
AMF - https://en.wikipedia.org/wiki/Additive_Manufacturing_File_Format

Both of the above satisfy 1) and 2). AMF in its simplest form is quite nice, but not terribly efficient, plus in my opinion it forgets 4) so it will never become universal. OFF is a nice contender, but it does not seem to be simple enough to be popular.

STL is both wasteful and ambiguous, it is just a sea of free floating triangles. The binary format does not contain the same info as the text format, etc. Its popularity is due to history only.

It seems to me super simplicity is a key. So any alternative format should be even simpler than STL. Given that existing alternatives are not very popular, we might as well propose something new to compete, making simplicity the key feature while fixing some of the STL issues. In my mind it could be something like

* simple file header to identify ASCII/Binary
* vertex coordinates stored only once
* triangle faces only
* faces defined by references to vertices, implicit normals

In other words, just the bare minimum, equivalent to the info that goes into OpenSCAD polyhedron command. The text format would be more compact than STL and simpler to read. The binary format would also be more compact than STL since coordinates would be mentioned only once, and therefore also not have any issues with interpretation.

You could say it is far too simple. But if you want it to be widely adopted it must be extremely simple and fast. We could call it STL2 and say it is how STL should have been defined in 1985 or so :-)

I don't have any illusions it would be successful, but if it was adopted I think it would be helpful in avoiding some of the "damaged STL" issues (not all) and enable easier sharing of models between various applications.

Just my thoughts, nothing else.

Carsten Arnholm

_______________________________________________
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: damaged STL file?

Ronaldo
In reply to this post by nophead
I agree that STL is a waster format. But Arnholm four point proposal does not assure a manifold definition neither it is more restrict than STL format. In fact, any model expressed in a STL file may be expressed by an OpenSCAD command whether it is a manifold or not.

Besides, with the advent of multi-material 3D print, a more general format will be demanded representing a partition of the space in many adjacent volumes to be filled with different materials. Although each of those volumes might be a manifold, the whole model is not anymore.

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

Re: damaged STL file?

nophead
I have never seen a physical solid object that isn't manifold. Surely that is impossible, so if everything you can 3D print is manifold why do need to represent non-manifolds. They only exist mathematically, not physically.

On 26 February 2018 at 20:36, Ronaldo Persiano <[hidden email]> wrote:
I agree that STL is a waster format. But Arnholm four point proposal does not assure a manifold definition neither it is more restrict than STL format. In fact, any model expressed in a STL file may be expressed by an OpenSCAD command whether it is a manifold or not.

Besides, with the advent of multi-material 3D print, a more general format will be demanded representing a partition of the space in many adjacent volumes to be filled with different materials. Although each of those volumes might be a manifold, the whole model is not anymore.

_______________________________________________
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: damaged STL file?

Ronaldo

I have never seen a physical solid object that isn't manifold. Surely that is impossible, so if everything you can 3D print is manifold why do need to represent non-manifolds. They only exist mathematically, not physically. 
Consider two same axis cylinders joined end to end by an union operation. If they have the same diameter, the union will be a longer cylinder. But if the top cylinder should be 3D printed with a opaque filament and the bottom one with a translucent one, the longer cylinder is not a good model for printing it. We may want a two distinct volume with a common face. That is not neither the union of two cylinders nor a manifold.

​I agree with you but 3D printing is not the only goal of CAD system in general and of OpenSCAD in special. It would be legitimate to use OpenSCAD for illustration, for instance. In an illustration of a car, why must the motor hood have a thickness instead of being just the top hood surface? Another non-manifold object.



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

Re: damaged STL file?

nophead
Yes STL can't represent two manifolds touching but even if it could you can't use it for multi-materials because there is no way to associate properties. The simple solution is to use multiple STLs as I did nearly nine years ago now http://hydraraptor.blogspot.co.uk/2009/11/hacking-with-erik.html.

Yes STL is no good for illustrations or CAD interchange, it was only ever intended for 3D printing.

On 26 February 2018 at 21:27, Ronaldo Persiano <[hidden email]> wrote:

I have never seen a physical solid object that isn't manifold. Surely that is impossible, so if everything you can 3D print is manifold why do need to represent non-manifolds. They only exist mathematically, not physically. 
Consider two same axis cylinders joined end to end by an union operation. If they have the same diameter, the union will be a longer cylinder. But if the top cylinder should be 3D printed with a opaque filament and the bottom one with a translucent one, the longer cylinder is not a good model for printing it. We may want a two distinct volume with a common face. That is not neither the union of two cylinders nor a manifold.

​I agree with you but 3D printing is not the only goal of CAD system in general and of OpenSCAD in special. It would be legitimate to use OpenSCAD for illustration, for instance. In an illustration of a car, why must the motor hood have a thickness instead of being just the top hood surface? Another non-manifold object.



_______________________________________________
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: damaged STL file?

Ronaldo

Yes STL can't represent
​​
two manifolds touching but even if it could you
​​
can't use it for multi-materials because there is no way to associate properties. The simple solution is to use multiple STLs as I did nearly nine years ago now http://hydraraptor.blogspot.co.uk/2009/11/hacking-with-erik.html.

​You are right saying that STL can't be used for multi-materials because there is no way to associate properties. But it can represent 
two manifolds touching. Given the STL of a cube, add two more triangles subdividing the rectangle joining two opposed cube edges. If you want, duplicate each of these triangles with opposed normals.

My point is: we need a model more general  than manifolds to comprise things like multi-material 3D printing without hacked solutions. May be 3MF is the solution.

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

Re: damaged STL file?

cacb
In reply to this post by doug.moen
On 2018-02-26 21:29, doug moen wrote:
> 3MF is a superior alternative to AMF.

That may be so. I agree that any proprietary nature of AMF is another
argument against it.

I had a very quick glance at the 3MF specs. The PDF is 50+ pages and
talks about many non-trivial aspects unrelated to the model itself.
Although it seems well documented, it does not quite meet my simplicity
requirement (#4). It is also XML based. I really like XML, but it means
it will not be super fast, and not compact.

There are very odd requirements in 3MF that the model must be in the
positive octant of the coordinate space. This tells me the format is not
generally intended for data exchange between application (failing my
#1), but probably intended specifically for 3d printers. So it isn't
what I had in mind.

> * It is less ambiguous, due to explicit rules on how to interpret
> certain non-manifold models that AMF leaves undefined. Specifically,
> it allows self intersection and overlapping triangles.

Ok, I will be blunt and say this is likely to kill it as a useful format
for exchange. It will cause problems. Consider implementing a 3MF
importer in OpenSCAD.

> Here's one
> reason why this is important. The union operation is not closed with
> respect to manifold meshes. If you union two manifold meshes, the
> result may not be manifold.

union() {
    cube(100);
    translate([100,100,0])cube(100);
}

The above example will typically result in a model which is explicitly
not allowed in 3MF, unless you duplicate the common edge.

https://3mf.io/wp-content/uploads/2017/10/3MF_Core_Spec_v1.2_28129.pdf
page 28

> * 3MF is an open standard, and AMF is not (you have to pay money for a
> copy of the AMF standard, and you can't redistribute your copy of this
> secret, proprietary information.)

Good point.

> OpenSCAD has a 3MF implementation underway:
> https://github.com/openscad/openscad/pull/1802.

That's interesting.

> I feel it is not productive or useful at this point to design yet
> another mesh file format.

My feeling is that if 3MF is the alternative, then STL will continue to
dominate due to its inertia. I may draft an alternative if nobody else
is interested. It will be either successful or ignored, so no harm done
:-) I guess 3MF will be useful for its purpose, but in my opinion there
should be a simpler and more compact alternative, and it isn't today's
STL.


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: damaged STL file?

Gadgetmind
In reply to this post by nophead
On 26/02/18 22:59, nop head wrote:
The simple solution is to use multiple STLs

I was musing on this recently.

I wanted to print a triangular prism on its side (toblerone!) with the top flattened and a V notch then cut in this to let me stand a thin object in it.

It wouldn't need any infill other than where the flat/notch on the top was. I can design an object that's all the outside faces (with thickness) and a support designed in, but would it actually work? Would OpenSCAD cope/barf and would a slicer be happy with an object with interior voids?



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

Re: damaged STL file?

nophead
In reply to this post by cacb
> I really like XML, but it means it will not be super fast, and not compact.

IIRC 3ML has a zip wrapper to make the XML compact. It won't be supper fast though but compared to OpenSCAD rendering and slicer execution time, not to mention 3D printing time, I doubt speed will be an issue.

On 27 February 2018 at 08:08, <[hidden email]> wrote:
On 2018-02-26 21:29, doug moen wrote:
3MF is a superior alternative to AMF.

That may be so. I agree that any proprietary nature of AMF is another argument against it.

I had a very quick glance at the 3MF specs. The PDF is 50+ pages and talks about many non-trivial aspects unrelated to the model itself. Although it seems well documented, it does not quite meet my simplicity requirement (#4). It is also XML based. I really like XML, but it means it will not be super fast, and not compact.

There are very odd requirements in 3MF that the model must be in the positive octant of the coordinate space. This tells me the format is not generally intended for data exchange between application (failing my #1), but probably intended specifically for 3d printers. So it isn't what I had in mind.

* It is less ambiguous, due to explicit rules on how to interpret
certain non-manifold models that AMF leaves undefined. Specifically,
it allows self intersection and overlapping triangles.

Ok, I will be blunt and say this is likely to kill it as a useful format for exchange. It will cause problems. Consider implementing a 3MF importer in OpenSCAD.

Here's one
reason why this is important. The union operation is not closed with
respect to manifold meshes. If you union two manifold meshes, the
result may not be manifold.

union() {
   cube(100);
   translate([100,100,0])cube(100);
}

The above example will typically result in a model which is explicitly not allowed in 3MF, unless you duplicate the common edge.

https://3mf.io/wp-content/uploads/2017/10/3MF_Core_Spec_v1.2_28129.pdf
page 28

* 3MF is an open standard, and AMF is not (you have to pay money for a
copy of the AMF standard, and you can't redistribute your copy of this
secret, proprietary information.)

Good point.

OpenSCAD has a 3MF implementation underway:
https://github.com/openscad/openscad/pull/1802.

That's interesting.

I feel it is not productive or useful at this point to design yet
another mesh file format.

My feeling is that if 3MF is the alternative, then STL will continue to dominate due to its inertia. I may draft an alternative if nobody else is interested. It will be either successful or ignored, so no harm done :-) I guess 3MF will be useful for its purpose, but in my opinion there should be a simpler and more compact alternative, and it isn't today's STL.



Carsten Arnholm

_______________________________________________
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: damaged STL file?

Neon22
In reply to this post by Gadgetmind

I wrote a simple amf to openscad polyhedron format converter here:
- https://github.com/Neon22/amf-to-openscad-polyhedron

The xml is annoying but if you only need some of the format represented then this is a start...?


On 2/27/2018 9:30 PM, Gadgetmind wrote:
On 26/02/18 22:59, nop head wrote:
The simple solution is to use multiple STLs

I was musing on this recently.

I wanted to print a triangular prism on its side (toblerone!) with the top flattened and a V notch then cut in this to let me stand a thin object in it.

It wouldn't need any infill other than where the flat/notch on the top was. I can design an object that's all the outside faces (with thickness) and a support designed in, but would it actually work? Would OpenSCAD cope/barf and would a slicer be happy with an object with interior voids?




_______________________________________________
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
rew
Reply | Threaded
Open this post in threaded view
|

Re: damaged STL file?

rew
In reply to this post by Gadgetmind
On Tue, Feb 27, 2018 at 08:30:18AM +0000, Gadgetmind wrote:

> On 26/02/18 22:59, nop head wrote:
> >The simple solution is to use multiple STLs
>
> I was musing on this recently.
>
> I wanted to print a triangular prism on its side (toblerone!) with
> the top flattened and a V notch then cut in this to let me stand a
> thin object in it.
>
> It wouldn't need any infill other than where the flat/notch on the
> top was. I can design an object that's all the outside faces (with
> thickness) and a support designed in, but would it actually work?
> Would OpenSCAD cope/barf and would a slicer be happy with an object
> with interior voids?

I tried doing what you proposed in a few minutes, but hte version with
"support designed in" was too difficult for me in a few minutes. But I'm
pretty sure it would work.

The "standard" way to quickly get such supports is to make it a wall
instead.


v=0; // use v=1 to be able to see the cutout stick out.


module tob1()
{
  difference () {
    translate ([100,0,0]) rotate ([0,-90,0]) cylinder (d=20,h=100,$fn=3);
    // toblerone, on it side, where I want it.
 
    translate ([-1,-5,7]) cube ([110,10,10]);
    // flattened

    scale ([1,.1,1]) translate ([-1,0,5]) rotate ([0,90,0]) cylinder (d=10,h=102,$fn=3);
    // with a V-notch.
  }
}

module tob2()
{
  difference () {
    tob1 ();
   
#    translate ([1-2*v,-0.050,-4.5]) cube ([98+4*v,.10,5.4]) ;
  }
}

tob2();


--
** [hidden email] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

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

Re: damaged STL file?

doug.moen
In reply to this post by cacb
Carsten:

A 3MF file can contain multiple objects. Each object has a mesh and a material ID. This is how multi-extruder, multi-material 3D prints are supported. You define one object for each material or colour. There is no problem if two objects share faces. That's normal for a multi-material print.

Within an object, a mesh is defined as an array of vertices (each vertex has an integer index) and an array of triangles (each triangle has 3 vertex indices).

It is legal to have two vertices with the same (x,y,z) coordinates, but different indices.

In section 4.1, the standard says:
  "Manifold Edges: Every triangle edge in the mesh shares common vertex endpoints with the edge of exactly 1 other triangle."

But, in this sentence, the meaning of two vertices being the same is that they have the same index, not that they have the same (x,y,z) coordinates. So 3MF is not a triangle soup format like STL, and a manifold mesh in 3MF can represent a larger set of shapes than a manifold mesh in STL.

In section 4.1.3, the standard says:
  "The vertices element contains all the <vertex> elements for this object. The vertices represent the corners of each triangle in the mesh. The order of these elements defines an implicit 0-based index that is referenced by other elements, such as the <triangle> element. The producer SHOULD NOT include duplicate vertices unless coalescing duplicates would create non-manifold edges."

On 27 February 2018 at 03:08, <[hidden email]> wrote:
On 2018-02-26 21:29, doug moen wrote:
3MF is a superior alternative to AMF.

That may be so. I agree that any proprietary nature of AMF is another argument against it.

I had a very quick glance at the 3MF specs. The PDF is 50+ pages and talks about many non-trivial aspects unrelated to the model itself. Although it seems well documented, it does not quite meet my simplicity requirement (#4). It is also XML based. I really like XML, but it means it will not be super fast, and not compact.

There are very odd requirements in 3MF that the model must be in the positive octant of the coordinate space. This tells me the format is not generally intended for data exchange between application (failing my #1), but probably intended specifically for 3d printers. So it isn't what I had in mind.

* It is less ambiguous, due to explicit rules on how to interpret
certain non-manifold models that AMF leaves undefined. Specifically,
it allows self intersection and overlapping triangles.

Ok, I will be blunt and say this is likely to kill it as a useful format for exchange. It will cause problems. Consider implementing a 3MF importer in OpenSCAD.

Here's one
reason why this is important. The union operation is not closed with
respect to manifold meshes. If you union two manifold meshes, the
result may not be manifold.

union() {
   cube(100);
   translate([100,100,0])cube(100);
}

The above example will typically result in a model which is explicitly not allowed in 3MF, unless you duplicate the common edge.

https://3mf.io/wp-content/uploads/2017/10/3MF_Core_Spec_v1.2_28129.pdf
page 28

* 3MF is an open standard, and AMF is not (you have to pay money for a
copy of the AMF standard, and you can't redistribute your copy of this
secret, proprietary information.)

Good point.

OpenSCAD has a 3MF implementation underway:
https://github.com/openscad/openscad/pull/1802.

That's interesting.

I feel it is not productive or useful at this point to design yet
another mesh file format.

My feeling is that if 3MF is the alternative, then STL will continue to dominate due to its inertia. I may draft an alternative if nobody else is interested. It will be either successful or ignored, so no harm done :-) I guess 3MF will be useful for its purpose, but in my opinion there should be a simpler and more compact alternative, and it isn't today's STL.



Carsten Arnholm

_______________________________________________
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: damaged STL file?

cacb
On 27. feb. 2018 16:40, doug moen wrote:
> A 3MF file can contain multiple objects. Each object has a mesh and a
> material ID. This is how multi-extruder, multi-material 3D prints are
> supported. You define one object for each material or colour. There is
> no problem if two objects share faces. That's normal for a
> multi-material print.

Please see what I wrote. You are talking about something else.

> Within an object, a mesh is defined as an array of vertices (each vertex
> has an integer index) and an array of triangles (each triangle has 3
> vertex indices).

No need to explain to me what i wrote before... this is basic in all
formats except STL...

> It is legal to have two vertices with the same (x,y,z) coordinates, but
> different indices.

No need to explain...

> In section 4.1, the standard says:
>    "Manifold Edges: Every triangle edge in the mesh shares common vertex
> endpoints with the edge of exactly 1 other triangle."
>
> But, in this sentence, the meaning of two vertices being the same is
> that they have the same index, not that they have the same (x,y,z)
> coordinates. So 3MF is not a triangle soup format like STL,

No need to explain... I know 3MF is not a triangle soup. I am not here
to defend things I never said.

Please see what I wrote. I have not claimed anything about common
coordinates, and certainly not that it isn't allowed. Of course it is
allowed. I am talking about topology.

Each topological edge in a mesh has a unique identifier, it can be
explicitly or implicitly defined, but it is unique. In this case the
identifier may be defined implicitly using the vertex indices. What they
are saying in a roundabout way is that any edge identified in this way
must not be referenced from more that 2 triangles (i.e. 2-manifold
requirement).

I pointed out that the example I gave will in OpenSCAD generate an edge
shared by more than 2 triangles, in conflict with the 2-manifold
requirement, and OpenSCAD agrees:

"WARNING: Object may not be a valid 2-manifold and may need repair! "

This is the issue discussed, and 3MF does not allow such issues. If you
want to export that model from OpenSCAD to 3MF in a compliant way, you
have to eliminate the common edge, like I said before. Since edges
identifies are implicit, it means vertices must be duplicated for that edge.

Now, I really don't mind if you ignore it and generate a 3MF with such a
non-compliant issue, my point is ONLY that it seems to me that 3MF is
not likely to succeed in defining away common issues that happen in real
models, and the result will still be problematic data exchange. The
exchange issue is really the only thing I am concerned with.

I think this illustrates the point that it is in my opinion preferable
to have a format that does not try to police in the same way, but is
still well defined. The important thing is that what is stored is
unambiguous and easy to understand and not overly restrictive or
complex. So therefore the "STL done right" idea.

Again, I am not against 3MF at all, but there are some scenarios it does
not seem to handle well.

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: damaged STL file?

doug.moen
Okay, I understand your point now. Sorry about the aggravation.

On 27 February 2018 at 14:14, Carsten Arnholm <[hidden email]> wrote:
On 27. feb. 2018 16:40, doug moen wrote:
A 3MF file can contain multiple objects. Each object has a mesh and a material ID. This is how multi-extruder, multi-material 3D prints are supported. You define one object for each material or colour. There is no problem if two objects share faces. That's normal for a multi-material print.

Please see what I wrote. You are talking about something else.

Within an object, a mesh is defined as an array of vertices (each vertex has an integer index) and an array of triangles (each triangle has 3 vertex indices).

No need to explain to me what i wrote before... this is basic in all formats except STL...

It is legal to have two vertices with the same (x,y,z) coordinates, but different indices.

No need to explain...

In section 4.1, the standard says:
   "Manifold Edges: Every triangle edge in the mesh shares common vertex endpoints with the edge of exactly 1 other triangle."

But, in this sentence, the meaning of two vertices being the same is that they have the same index, not that they have the same (x,y,z) coordinates. So 3MF is not a triangle soup format like STL,

No need to explain... I know 3MF is not a triangle soup. I am not here to defend things I never said.

Please see what I wrote. I have not claimed anything about common coordinates, and certainly not that it isn't allowed. Of course it is allowed. I am talking about topology.

Each topological edge in a mesh has a unique identifier, it can be explicitly or implicitly defined, but it is unique. In this case the identifier may be defined implicitly using the vertex indices. What they are saying in a roundabout way is that any edge identified in this way must not be referenced from more that 2 triangles (i.e. 2-manifold requirement).

I pointed out that the example I gave will in OpenSCAD generate an edge shared by more than 2 triangles, in conflict with the 2-manifold requirement, and OpenSCAD agrees:

"WARNING: Object may not be a valid 2-manifold and may need repair! "

This is the issue discussed, and 3MF does not allow such issues. If you want to export that model from OpenSCAD to 3MF in a compliant way, you have to eliminate the common edge, like I said before. Since edges identifies are implicit, it means vertices must be duplicated for that edge.

Now, I really don't mind if you ignore it and generate a 3MF with such a non-compliant issue, my point is ONLY that it seems to me that 3MF is not likely to succeed in defining away common issues that happen in real models, and the result will still be problematic data exchange. The exchange issue is really the only thing I am concerned with.

I think this illustrates the point that it is in my opinion preferable to have a format that does not try to police in the same way, but is still well defined. The important thing is that what is stored is unambiguous and easy to understand and not overly restrictive or complex. So therefore the "STL done right" idea.

Again, I am not against 3MF at all, but there are some scenarios it does not seem to handle well.


Carsten Arnholm

_______________________________________________
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: File format to replace STL

MathLover
In reply to this post by cacb
Just for the fun of it, I'd like to suggest a different approach to a good
file format. I know that I cannot change the 3D printer and the CAD
community, but here's the idea.

What would be very handy in a file format is support for all programming
languages and the possibility to load different pieces of it as you need
them, rather than loading the entire set of data into memory before parsing
it.

From these considerations, I would suggest an SQLite database. It is widely
supported, enough tools exist to see and use the contents (somewhat
cancelling the need for an ascii version), and every programming language
can read and write them. The format may not be simple, but the wide support
sort of makes up for it.

A slicer could read the data sorted "from the ground up", while CAD programs
could use different strategies, but all systems would be able to use it.



--
Sent from: http://forum.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: File format to replace STL

cube
Isn't sqlite super heavy compared to basically anything? Would the
format use indexing and sql queries?

Anyway I don't think that it's a good idea to make a new 3D format.
IMHO the best course is to figure out a good existing one that already
has some support and start pushing it, if STL is not good enough. 3MF
looks pretty decent (although XML is a bit meh for me).

... but .... as a  thought experiment, if we decided to make a new one,
I'd go for file structure of PNG. Minimal version is _very_ easy to
read if there's no compression involved and has enough flexibility for
anything you might need now and in the future.

On Wed, 28 Feb 2018 02:27:19 -0700 (MST)
MathLover <[hidden email]> wrote:

> Just for the fun of it, I'd like to suggest a different approach to a good
> file format. I know that I cannot change the 3D printer and the CAD
> community, but here's the idea.
>
> What would be very handy in a file format is support for all programming
> languages and the possibility to load different pieces of it as you need
> them, rather than loading the entire set of data into memory before parsing
> it.
>
> From these considerations, I would suggest an SQLite database. It is widely
> supported, enough tools exist to see and use the contents (somewhat
> cancelling the need for an ascii version), and every programming language
> can read and write them. The format may not be simple, but the wide support
> sort of makes up for it.
>
> A slicer could read the data sorted "from the ground up", while CAD programs
> could use different strategies, but all systems would be able to use it.
>
>
>
> --
> Sent from: http://forum.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: File format to replace STL

cacb
In reply to this post by MathLover
On 2018-02-28 10:27, MathLover wrote:
> From these considerations, I would suggest an SQLite database.

This is a decent idea, SQLite is super lightweight. I have used it for
implementing a quasi OO-database
https://github.com/arnholm/op_lite and SQLite is very fast and
efficient. I have such files with many gigabytes without issues.

BUT, the main thing for data sharing is is not really the physical
representation on disk, but the logical structure of the data contained.
Once you have that sorted, you can define/implement various file
representations, like flat ascii, flat binary, SQLite or whatever. Once
you have that, tt is true that SQLite would provide access from multiple
languages, and be binary portable across platform and support very large
datasets.

But if you put a polygon soup into SQLite it would still be a polygon
soup.

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: File format to replace STL

RayBellis
In reply to this post by MathLover
MathLover wrote
> From these considerations, I would suggest an SQLite database.

I'm sorry, but I think that's a really lousy idea.

For the sort of data found in an object definition SQLite would provide *no*
additional advantages over any other file format.  The SQL tables would just
be wrappers around the data.

The last thing I'd want to have to do when writing a file parser is use an
API that does the equivalent of "SELECT x, y, z FROM vertices"

See also https://xkcd.com/927/
 
Ray




--
Sent from: http://forum.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: File format to replace STL

doug.moen
In reply to this post by MathLover
If the problem you are trying to solve is the ability to process meshes that are too big to fit into memory, then sqlite is the wrong solution. You need a *spatial database* that supports geometric range queries. The Wikipedia page is a nice overview.

But if you do that, clients will need to use a special library for reading and writing the database. File formats like STL and 3MF are easy enough to generate and parse that they don't require a file format specific library.

On Wednesday, 28 February 2018, MathLover <[hidden email]> wrote:
Just for the fun of it, I'd like to suggest a different approach to a good
file format. I know that I cannot change the 3D printer and the CAD
community, but here's the idea.

What would be very handy in a file format is support for all programming
languages and the possibility to load different pieces of it as you need
them, rather than loading the entire set of data into memory before parsing
it.

From these considerations, I would suggest an SQLite database. It is widely
supported, enough tools exist to see and use the contents (somewhat
cancelling the need for an ascii version), and every programming language
can read and write them. The format may not be simple, but the wide support
sort of makes up for it.

A slicer could read the data sorted "from the ground up", while CAD programs
could use different strategies, but all systems would be able to use it.



--
Sent from: http://forum.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
12