RFC: Support for cross section geometry

[codehero]

In Issue #310 I am working on importing cross sections directly into Cura sans 3D triangles. By cross sections, I specifically mean 2D X-Y polygons with holes arranged in Z order; each cross section annotated by its Z height and thickness. My reasons for this data representation include:

1. many shapes are natively described in this format (contours, etc)
2. more robust CSG (boolean operations on cross sections using Clipper work way better than OpenSCAD ever will)
3. STL files can be presliced into cross sections and turned into this format anyway
4. Easier for me to customize the z slicing dimensions (rather than relying on a layer_height, etc)

Reasons for Cura to incorporate this format:

1. more clear separation of the STL repairing/slicing concern from the motion planning concern 1a. On a GUI level, this means a UI for exactly specifying cross section heights and thicknesses 1b. On a coding level, this means perhaps spinning the STL slicer into its own subutility

Needless to say, if I want to see this as a feature of Cura we would have to agree on a file format. I propose a container format, with a header file and a file for each cross section.

The container format would be tar.gz. The header file would be JSON, describing metadata of the geometry (bounding box, etc). This file would come first in the tar. Subsequently, the layer files would appear in the tar in Z order. The filename would be the coordinate followed by the layer file format extension. The layer file format could be SVG or DXF; the idea is that the layer files themselves could be inspected with off the shelf software. To keep complexity down, the layer file format may be a strict subset of features available to that format (ie, only for SVG). Any use of other entities would be a format violation.

Thoughts?

[BagelOrb]

I'm still not fully convinced that supplying layer data to cura is a good idea. It means that the slicing step must be done 'by hand' by the user. Such a file cannot be printed in a different layer height than the creator of the file supplied.

I would think it's better to have arbitrary names for the slices, and in the header have a table relating each height to an svg. That way slices can be recycled easier across different layers and across different slice files.

Maybe we should have the tar.gz encoding, but think of a new extension any way. Several other file types do that well.

Note that the engine decouples the slicing height from the printing height. We would need both for resp frontend and backend.

Note that CuraEngine currently only supports the first layer to have a different layer height than the rest, but all other layers should have the same height. I have no idea how and whether we should enforce that in the file format.

Isn't there a 3mf extension which does exactly what you want? Op 7 jul. 2016 17:33 schreef "David Bender" notifications@github.com:

In Issue #310 https://github.com/Ultimaker/CuraEngine/issues/310 I am working on importing cross sections directly into Cura sans 3D triangles. By cross sections, I specifically mean 2D X-Y polygons with holes arranged in Z order; each cross section annotated by its Z height and thickness. My reasons for this data representation include:

1. many shapes are natively described in this format (contours, etc)
2. more robust CSG (boolean operations on cross sections using Clipper work way better than OpenSCAD ever will)
3. STL files can be presliced into cross sections and turned into this format anyway
4. Easier for me to customize the z slicing dimensions (rather than relying on a layer_height, etc)

Reasons for Cura to incorporate this format:

1. more clear separation of the STL repairing/slicing concern from the motion planning concern 1a. On a GUI level, this means a UI for exactly specifying cross section heights and thicknesses 1b. On a coding level, this means perhaps spinning the STL slicer into its own subutility

Needless to say, if I want to see this as a feature of Cura we would have to agree on a file format. I propose a container format, with a header file and a file for each cross section.

The container format would be tar.gz. The header file would be JSON, describing metadata of the geometry (bounding box, etc). This file would come first in the tar. Subsequently, the layer files would appear in the tar in Z order. The filename would be the coordinate followed by the layer file format extension. The layer file format could be SVG or DXF; the idea is that the layer files themselves could be inspected with off the shelf software. To keep complexity down, the layer file format may be a strict subset of features available to that format (ie, only for SVG). Any use of other entities would be a format violation.

Thoughts?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Ultimaker/CuraEngine/issues/369, or mute the thread https://github.com/notifications/unsubscribe/AIe9ER2dY1DRTdTgEeaPe0ClJaRJ-BqUks5qTRxjgaJpZM4JHNQi .

[codehero]

I'm still not fully convinced that supplying layer data to cura is a good idea. It means that the slicing step must be done 'by hand' by the user. Such a file cannot be printed in a different layer height than the creator of the file supplied.

Apologies, I wasn't trying to imply that the user was REQUIRED to slice by hand, just that they could. For example, slic3r allows different slice thicknesses at different heights. I can understand why you don't see the value; the burden of proof is on me to show it. I do appreciate your feedback on this though.

I would think it's better to have arbitrary names for the slices, and in the header have a table relating each height to an svg. That way slices can be recycled easier across different layers and across different slice files.

Completely agree; I think the arbitrary names for slices and references in the header is a very good recommendation.

Maybe we should have the tar.gz encoding, but think of a new extension any way. Several other file types do that well.

The name of the extension is no importance to me. However, using a .tgz extension would allow a user to use their file explorer's compression extensions to view file contents conveniently.

Note that the engine decouples the slicing height from the printing height. We would need both for resp frontend and backend.

I don't understand the distinction between slicing height and printing height...clarify: is slicing height the height at which the model is sampled, and printing height relates to the bottom (or top) of the deposited layer?

Note that CuraEngine currently only supports the first layer to have a different layer height than the rest, but all other layers should have the same height. I have no idea how and whether we should enforce that in the file format.

The layer height settings only seem to apply to slicing 3D models. In my experience, it seems the CuraEngine motion planning engine is perfectly happy with arbitrary slice thicknesses.

Isn't there a 3mf extension which does exactly what you want?

I briefly looked over 3mf and didn't see it. Anyway, if you guys and slic3r haven't made 3mf support a priority I'm not really sure why I would choose this option?

[BagelOrb]

Op 7 jul. 2016 19:37 schreef "David Bender" notifications@github.com:

Apologies, I wasn't trying to imply that the user was REQUIRED to slice by hand, just that they could. For example, slic3r allows different slice thicknesses at different heights. I can understand why you don't see the value; the burden of proof is on me to show it. I do appreciate your feedback on this though.

The thing is that you will create such files and share them with other users, who then have no option any more to slice at different heights. I therefore think this isn't a very good interchange format. It's a big concern, but I'm not fully decided yet.

The name of the extension is no importance to me. However, using a .tgz extension would allow a user to use their file explorer's compression extensions to view file contents conveniently.

Yes, but you wouldn't be able to do file association any more. You wouldn't want cura to always open tgz files.

I don't understand the distinction between slicing height and printing height...clarify: is slicing height the height at which the model is sampled, and printing height relates to the bottom (or top) of the deposited layer?

Indeed. A layer is sampled in the middle, but printed from the top (in fdm).

The layer height settings only seem to apply to slicing 3D models. In my experience, it seems the CuraEngine motion planning engine is perfectly happy with arbitrary slice thicknesses.

There are multiple algorithms which depend on a uniform layer height (which simply ignore that the first layer is different). To name some: top/bottom skin area calculation, infill thickness, support area calculation and probably more.

Isn't there a 3mf extension which does exactly what you want?

I briefly looked over 3mf and didn't see it. Anyway, if you guys and slic3r haven't made 3mf support a priority I'm not really sure why I would choose this option?

Because there is no reason to reinvent the wheel. If there is a format which does what you want we should use that, so that there's a higher chance for modeling programs to output that format.

[codehero]

The thing is that you will create such files and share them with other users, who then have no option any more to slice at different heights. I therefore think this isn't a very good interchange format. It's a big concern, but I'm not fully decided yet.

Users share ideas and intentions; files are just the expression. Currently the expression is a series of triangles. If 3D printers made triangles and assembled them, this would be the perfect way to do it. But pretty much all 3D printers create a series of layers. I want to design directly within the space and capabilities of a printer.

If I am a designer and aware of this I would already know my intended layer height. In OpenSCAD, I can make a script to do projection cuts and export the slices. I imagine a sketchup plugin could do the same thing with section cuts. And when I share a file with another user, I fully expect them to use the layers I determined. If they want to make a change, then they would need the source (just like a user would need .scad instead of a .stl)

Yes, but you wouldn't be able to do file association any more. You wouldn't want cura to always open tgz files.

I think the file association is a good point.

There are multiple algorithms which depend on a uniform layer height (which simply ignore that the first layer is different). To name some: top/bottom skin area calculation, infill thickness, support area calculation and probably more.

I will stick to a uniform layer height for the time being then.

Because there is no reason to reinvent the wheel. If there is a format which does what you want we should use that, so that there's a higher chance for modeling programs to output that format.

3mf is a reinvention of the wheel...it's based on triangles.

Anyway, this discussion has been very productive for me.

[Ghostkeeper]

File association could still be possible if you put a very recognisable file in the tgz. A MIME type detection algorithm could open up the gzip and see if it contains that file. For Windows you would need to devise a new extension to allow specific association.

[BagelOrb]

I agree that 3mf reinvents some parts which are unneccesary, but it introduces a lot of new functionality which is not present in the stl format for example. Do note that the slice extension seems to be exactly what you are looking for. Even if 3mf reinvented the wheel then you still shouldn't re-reinvent the wheel. ;)

[codehero]

I hate to be that guy that can't google, (I've looked all over), did you have a link for the slice extension? Thanks

[BagelOrb]

Errrr There is no such 3mf file format extension yet, but "perhaps" some such file extension will officially be released in the near future.

I'm sorry to have informed you prematurely.

[BagelOrb]

A preliminary version is available here: http://www2.3mf.io/wp-content/uploads/2016/07/3MFsliceSpec.pdf

Hope this helps.

Are you still

[lf94]

There is a lot of discussion lately around importing pre-sliced geometry into Cura for the Curv project https://github.com/curv3d/curv . We have decided that the best course of action is to get Curv to export 3MF slice data and have Cura import it.

What would Ultimaker like to see in such a contribution? I think it will require changes to slicer.cpp and the 3MF importer.

The biggest advantages that pre-slicing brings to the table for us is:

1. Higher resolution edges
2. Much lower file sizes

It would allow us to print objects such as this:

https://media.discordapp.net/attachments/886321278821216277/898535496131690557/unknown.png?width=649&height=617

(By Doug, author of Curv)

Should we just open a PR for CuraEngine and discuss further there?

Thank you!

[doug-moen]

I'm going to be part of this project as well: adding support to Curv for 3MF slice export. (Curv is an OpenSCAD inspired 3D modelling language based on signed distance fields.)

My plan is that the 3MF file will contain a low resolution mesh (needed for preview) and in addition it will contain high resolution 3MF slice data. The use case is large meshes (tens of millions of triangles) that cause slicers to choke because there are too many triangles. If the model is pre-sliced, then the slicer should handle this large amount of data with no problem. The PNG that @lf94 posted is a 19 million triangle "gyroid foam" that I would like to print.

[BagelOrb]

Coincidentally, I happen to currently be printing a gyroid foam of 2.6 million triangles through Cura without any hiccups.

[doug-moen]

@BagelOrg My gyroid foam is a test model to prove the concept. I was able to slim it down to 2.3 million triangles, where it gets kind of blocky/low quality. But if I expand it from a 10cm cube to a 20cm cube, then even at that low resolution I'm back to 18.3 million triangles.

I have another test case, which is a 100x100x100 lattice structure. The minimum number of triangles seems to be about 100 million. I've seen printed objects containing these kinds of dense lattices, but they aren't printed using triangle meshes, because the software blows up. In that particular case, the guy wrote code to directly generate printer control codes for the model he wanted to print. But that's difficult to do, not everybody can write a model specific gcode generator. So one of the goals is to make it easier to print these kinds of models.

[BagelOrb]

I've been making spatially graded gyroid lattices and my resolution was mostly bound by my design programs. I've had to perform some actions in 3D, so I had to have a mesh representation after all, so in the end my application was limited not by Cura but by design software.

[doug-moen]

Another issue is that I don't have the ability to generate a 100 million triangle mesh file with my current software and equipment. My machine just runs out of memory. Note that the intermediate data structures used for generating a triangle mesh (using marching cubes or dual contouring) consume far more memory than the raw triangle data that's generated. I have 16 GB of RAM, which should be enough for most purposes. I can generate high resolution 3MF slice files using far less memory than is required for high res triangle meshes. I only need enough memory to generate one slice at a time.

[doug-moen]

my application was limited not by Cura but by design software

Limitations of design software is actually a good argument for Cura to support 3MF slice files. It's the fact that triangle meshes are hard to generate (and sometimes impossible to generate). I've already explained that I have this problem with Curv. Here's someone else on stackexchange who is asking for this feature, on the basis that "turning the implicit surface into a good mesh is hard":

https://3dprinting.stackexchange.com/questions/10533/slicing-directly-from-non-mesh-data

[Ghostkeeper]

What would Ultimaker like to see in such a contribution?

My approach to implement such a feature would be to allow loading the 3MF files into the front-end, visualise them for the user, and send them along with the model data to CuraEngine via protobuf. CuraEngine then needs to turn the pre-sliced geometry into a separate mesh. I think that's what we'd need to bring this feature to the user.

This involves changes across several repositories:

• Savitar needs to read the geometry. It can't read that at the moment.
• I imagine that the Scene class of Savitar would need to have a new field to get the pre-sliced geometry, to communicate this to Cura.
• Cura's 3MF Reader plug-in needs to interpret that and put it in the scene somehow.
• What can the scene do with it? Display it, certainly. It can simply be rendered as a set of flat planes I'd say. However normal scene nodes can be shifted, resized and rotated. Moving pre-sliced geometry horizontally is theoretically fine, but not vertically and you certainly shouldn't resize it in the Z direction or rotate it around the X or Y axes. Maybe all of it should be forbidden for this type of mesh. Or maybe just the ones that don't influence the Z direction.
• The CuraEngineBackend plug-in needs to have it added to the .proto file and fill in that information when it starts a slice.
• CuraEngine needs to save the slice data it received from the front-end and add that as a separate mesh just after the slicing stage.

We'd also need to think about what happens if the layer height of the pre-sliced geometry doesn't match the layer height that CuraEngine knows. If it needs to mix layer heights, this feature will explode in CuraEngine. Slices in 3MF can have arbitrary Z coordinates. So you could have alternating layer heights and such. Perhaps the best approach here is to snap the height of the layer to the Z coordinate of the nearest layer that CuraEngine generated for other models, and above the highest model to use the Z coordinate of the layer. And you'll also have to deal with rafts somehow.

It's a pretty complex feature to support properly.