Document vision for this project

[hannobraun]

It would be great for contributors and other interested parties to learn a bit more about the vision I have for this project. I've had lots of thoughts on that over the years, many of which have changed as I gained experience with the various prototypes, but haven't written that up in one place yet.

I'd like to collect notes in this issue over time. Once those notes are comprehensive, I'll flesh them out a bit and add that to the README, or possibly a new document.

So here my notes so far. Please note that a lot of that might be quite far off, or might change as things develop:

• UI
  • Models defined as code: This is already the case, just making clear that this is not just a temporary step, but core part of the vision. I wrote an article about the advantages of Code-CAD, in case someone's interested in more context.
  • Comprehensive GUI for inspecting models: Other Code-CAD software I've dealt with is pretty basic. You only see the finished model, which can make it hard to change things about the model (you end up changing and commenting out code to see an early sketch, for example). See Display model structure #13.
  • Hybrid UI for modifying models: Code-CAD is great, but a GUI is just better suited for some tasks. Creating sketches is one example. The code will be the source of truth, and editing it by hand will always be an option. But I'd like to provide GUI tools for specific editing tasks. Ideally, these GUI tools would modify the source code directly, but maybe having them modify specialized files that are then referenced in the source code is more practical. We'll see.
• CAD kernel
  • I've experimented with function representation (also known as F-Rep, signed distance functions, signed distance fields, explicit functions) before, and have come to the conclusion that it isn't a good approach for this project (context). Right now, I'm experimenting with more traditional approaches based on boundary representation (B-Rep). There's still a lot to implement (and thick books to read), so it's possible this isn't the last word.
  • Constructive Solid Geometry: CSG is convenient for many models, so I'd like to support it. It seems reasonable to assume that it will be an initial target, to provide a full set of basic modeling capability.
  • Referencing existing geometry: CSG by itself is too limited. I think the ability to reference existing geometry, for example by drawing a sketch on an existing face to create a new feature there, is essential for many models.
  • Constraint-based modeling: I think supporting constraints in sketches is pretty much essential. It would be nice to also be able to constrain 3D geometry.
• Platform support:
  • Desktop: I use Linux, but I'm happy to support any desktop platform where this is reasonably possible. This is going to depend on contributors doing the testing and maintenance for platforms I don't have access to (at this point, I only have access to Linux).
  • Web: I would absolutely like to support browsers as a platform. My own use case is to embed CAD models into websites, in a way that allows viewing, configuring, and exporting them. If anyone is willing to put in the work to support the full feature set (so including editing) on the web, I'm happy to support that.
  • Mobile: I don't have any plans to work on support for mobile platforms (except indirectly, via support for the web), but I'm happy to support such work.
• Software Architecture
  • Modularity: My focus is to create an application I can use to create CAD models, and I probably won't put much work into making all of the code modular and reusable. If anyone has a use case that requires splitting the code into smaller, reusable libraries, I'm happy to accommodate that though.
  • WebAssembly: For web support, it's probably necessary to switch to WebAssembly for the plugin mechanism that is used to load models. WebAssembly also provides sandboxing, which is good for security. See Improve plugin system #7.
  • Language support: Using WASM for the plugin system allows us to support other modeling languages. I have no plans to work on that, but would be happy to accommodate such work.
  • Custom modeling language: One thing I'm thinking about is to support a custom modeling language. It could be purpose-built for expressing CAD geometry, and be integrated with any GUI modeling features. I think this would require too much work to be practical any time soon though. Also see Kari, which I've created for an earlier iteration of Fornjot.

Please let me know, if anything here is unclear, of if there's an area you think I should cover.

[hannobraun]

I forgot mentioning anything about exporting to external file formats. Thoughts:

• My current main use case is 3D printing, which is why 3MF export is already implemented.
• STL and other triangle mesh formats can be implemented easily within the current structure. That just requires someone willing to put in the work.
• I'm interested in supporting CNC machining. From what I hear, that might require export to STEP format (if anyone wants to correct me and/or provide a fuller picture, that would be very welcome). I'm going in the direction of boundary representation anyway, so STEP should be a good fit, long-term (although that is mostly a guess; I know very little about STEP). Short-term (at least), the CAD kernel is still evolving and I expect it to change heavily over the next months, so working on STEP support would probably be more of a hindrance then anything else.
• Technical drawings is something I would absolutely like to support. Right now, I'm unclear how exactly that should work. And like STEP, it's probably best to wait until work around the CAD kernel has settled a bit. Also see Feature: Support for GD&T #2.

[hannobraun]

I've created a Feature Wishlist which supersedes this issue. Closing.