Split Fornjot into self-contained components

[hannobraun]

I want Fornjot to one day be the foundation of a thriving ecosystem of related software. To achieve that, it must be composed of self-contained components that can be reused in different contexts.

Right now, Fornjot consists of two components: A host application that loads models, and a library that models use to define geometry. Most of what is relevant lives in the monolithic host application, but I've had modularity in mind from early on. Splitting out the most important components, like the kernel and graphics modules, should be possible with little work, as their interfaces to the rest of the system are pretty clearly defined.

Other components will require some more work to untangle (main.rs is a bit of a mess right now).

While I see this as absolutely critical long-term, I do not intend to work on it any time soon, unless there is real demand. Having more and smaller crates will introduce friction to the development process, and I'd like to avoid that until there is actual need. If you have such a need, please speak up!

[hannobraun]

I started working on this yesterday, but forgot to mention it or to assign myself.

[hannobraun]

I extracted quite a few new crates last week. I think next up would be fj-mesh, which would need to be a separate crate, as it could define the data type that the kernel, export, and graphics code all understand, and use to communicate. I say "could define", as it doesn't currently quite work like that. The kernel kind of throws away what it knows about vertex identity, returns non-indexed triangles, which are then rebuilt into an indexed triangle mesh. This is overly complicated.

I'd like to take a stab at cleaning this up, but that will require changes to the triangulation code. And I don't want to make changes to the triangulation code before cleaning that up first, and more importantly, putting it under a test suite. That work is tracked in #105, so I'm putting this issue on hold for a bit, while I go and address that.

[hannobraun]

I had a thought: fj-debug should become fj-interop, which should also include the mesh (what I intended to extract separately into fj-mesh).

The purpose of both fj-debug and fj-mesh would have been to define a clear interface between the kernel and other components that process its results, but don't need to use the kernel directly (like graphics, export, maybe others). Since that is a single purpose, it makes sense to have a single crate for that. In addition, there might be other such small interop pieces in the futures, and I don't think it would make sense to define more small crates for each of those.

[hannobraun]

#105 (and some related issues) have been addressed. I'm back to working on this issue.

[hannobraun]

I've done a bunch of work since yesterday, further cleaning up crates that have already been extracted (most of that centered on fj-interop.

At this point, I think we're in pretty good shape. There are two more areas of functionality I'd like to extract from fj-app before calling this done:

1. fj-export: Exporting models to external files (currently only 3MF).
2. fj-viewer: Input, camera control, and graphics.

Once those are extracted, I'll could declare victory and call this issue done. I might look into splitting up fj-viewer further, into separate components for input, camera, and graphics, but I'm not sure that's worth the time investment right now.

[hannobraun]

I've extracted the two crates that I mentioned in my comment yesterday (#472, #474), and I consider this issue done now. While, as mentioned yesterday, some further work could be done, I don't think it's worth the investment right now.

I've added an entry about that to the feature wishlist. If anyone needs more crates to be extracted from other crates, feel free to comment here or in the wishlist.