Support DXF / 2D Exports

[Protryon]

I use OpenSCAD extensively in my workflows for 2D and 3D geometry. For laser cutting/2D CNC, I frequently use 2D shapes as OpenSCAD modules that I can export in DXF format for vendors (unsure what actual machines use). I would have a 3D model that shows the assembly of those 2D parts extruded with some other non-2D parts as well.

As a potential improvement over OpenSCAD -- it exports everything as line segments which CNC doesn't like at all. If the vendor accepts it (which they didn't for most models), it would be a jagged edge even with high vertex counts due to poor/overprecise CNC control code. I took inspiration from a 3D printing project to make a postprocess step to fix this: https://github.com/Protryon/dxf-welder

If Fornjot could export proper curves in DXF (either as a result of the different kernel or as a result of a optional postprocess step), that would be amazing! I'm always worried about my homerolled post-process step disturbing dimensional accuracy on my <0.1mm requirements.

[hannobraun]

Thank you for opening this issue, @Protryon!

I have no experience with this use case and know very little about DXF, but this is definitely a desirable feature. The Fornjot kernel is using boundary representation, so it would definitely be possible to export curves directly, in principle. In practice, the fj-export crate (which does all the exporting) currently only has access to the exported triangle mesh, but that's just because it's what all the currently supported format (3MF and STL) need anyway.

Clarifying the use case

You describe defining 2D shapes and exporting those directly to DXF. It sounds like you use the 3D models only for your own benefit, and don't export those to any external format. This sounds like something that could reasonably be supported in the near term, provided someone is able to put the effort in. There even is a DXF library in Rust already (dxf-rs), so assuming that works well, this would mostly be an effort of re-shuffling some things within Fornjot, which sounds doable (a million little problems will be discovered on the way, of course, but that's always the same 😂).

@Protryon, I'm aware that exporting 2D drawings of a 3D model, to show it from different perspectives, is a common thing in machining. Do you know, if that is related to DXF at all? I would assume that this is a different use case and PDF is a more reasonable target for that, but as I said, I have no experience with these things, so please let me know if you know anything.

Thoughts on implementation

I currently assume that models will be able to expose multiple types of artifacts. I've written a bit about that, and a potential syntax, here: #220 (comment)

Currently, you can only export a model as a whole, which makes sense, because all models are just a monolithic 3d thing. If models can export different artifacts, the export function (currently exposed through a command-line argument on fj-app) would have to be extended to specify exactly which artifact to export from the model. This could be made convenient through inference, for example if you want to export to DXF, and the model only specifies one 2D artifact.

To make this work, the interface between fj-host and the model would need to become smarter. I've recently left some thoughts on that here: #783 (comment)

I'm of the opinion that it makes sense to make the switch to WebAssembly (#71) first before working on that, but I wouldn't reject a reasonable pull request that did this based on the current host/model system.

Help wanted

As I said above, I think it would be reasonable to add this in the near-term, but it would require someone to drive this effort. I'm personally super-busy with boolean operations (#42, #43, #44) right now (and there's more on my list after that), and don't see myself having time for this any time soon.

If someone is willing to step up, please let me know! Happy to assist with advice and feedback. I've added a task to my list, to add some more thoughts on the implementation here. Hopefully I'll get to that next week.

[Protryon]

My experiences with complex 3D+ CNC is fairly limited, but my understanding is that orthographic projects of a model are common to include for measurements & documentations. Similarly, they can be used for engineering design review. This is all outside my wheelhouse though. PDF sounds right, that would be a human consumption use case.

My use case here is laser cutting(/2D CNC) where there is a powerful laser cutting sheets of material (i.e. aluminum, steel, carbon fiber). The paths exported end up being cut paths for the laser. 2D CNC is analogous.

[hannobraun]

Thanks for clarifying, @Protryon!

[hannobraun]

Okay, as promised, here are more thoughts on how to implement this.

1. I previously said that I believe Switch model system to WASM #71 should be implemented first. I no longer believe that. See Switch model system to WASM #71 (comment) for context.
2. I also said previously that the interface between host and model would need to change, so a model can define multiple artifacts of different types. There is a concrete plan for this now, see Switch to model-driven model system #804.
3. Once the model-driven approach is in place, the next step would be to give fj-export access to the kernel data structures. The most straight-forward way to do this, might be to add the original shape (in the form of Vec<Face>¹) to ProcessedShape.² (Update: This is no longer straight-forward. ProcessedShape has been moved to fj-interop, which can't depend on fj-kernel. Not sure how to deal with this right now, but I'm sure there's a solution that makes sense.)
4. The last, and possibly most difficult, step would be to figure out how to generate a DXF from the kernel data structures (likely using dxf-rs. This might require changes to the kernel data structures, or it could be straight-forward.

That last step is a bit vague, owing to the fact that I haven't looked more deeply into DXF or dxf-rs. If any questions come up during the implementation, I'm happy to do my best and answer them.

Footnotes

1. As of this writing, Vec<Face> is the top-level entry point into the kernel data structures. I have some notion to introduce Sketch and Solid types to wrap it. If this has happened by the time someone starts working on this, Sketch would be the type needed. ↩

2. We could worry about only doing the work that's actually required, i.e. not creating the triangle mesh unless it's actually needed by fj-export or fj-viewer (for displaying graphics), but for the most part, I prefer to fix actual problems instead of anticipating potential ones. ↩

[hannobraun]

Labeling this issue as blocked on #804.

[hannobraun]

#804 has been addressed. This issue is no longer blocked.

[hannobraun]

This remains a desired feature, but I have decided to close this issue for now. I've added an entry about DXF/SVG exports to the feature wishlist instead.

There are upcoming changes to the geometry representation, and while this issue is not blocked by that, I don't think it makes much sense to work on this issue before that lands. Any DXF export feature would essentially need to be rewritten as part of the transition.

This, coupled with the fact that there doesn't seem to be much appetite to implement this (I remain busy with other stuff, and nobody has stepped up to work on it in over a year) makes me think that the feature wishlist is the more appropriate place for this, for now.