As previously announced, Fornjot is changing to a weekly release schedule. The previous Weekly Dev Log is being repurposed into this weekly release announcement. Otherwise not much is going to change, for now.
I've finally restarted my work on the union operation (#42). This has been going well so far, and I've finished a few more building blocks that are going to be needed in the finished algorithm. That work has also inspired some cleanups in
fj-operations, which you can see below.
Meanwhile @jeevcat has worked on improving the API of the
Fornjot is supported by @webtrax-oz, @lthiery, @Yatekii, @martindederer, @hobofan, @ahdinosaur, @thawkins, @bollian, @rozgo, and my other awesome sponsors. Thank you!
If you want Fornjot to be stable and sustainable long-term, please consider supporting me too.
Improvements to Fornjot and its documentation that are visible to end-users.
- Make moving the model work, even if mouse is not hovering over it (#806)
- Make group and transform operations work on all shapes (#825)
Improvements to the Fornjot ecosystem that are relevant to developers who are building on top of Fornjot components.
- Implement curve/face intersection algorithm (#802, #812, #813, #817, #826)
- Return local curves from surface/surface intersection (#811)
Solidto distinguish between 2D/3D shapes (#819, #823, #827)
- Provide more complete and convenient transform API (#822)
- Fix edge case in
Improvements that are relevant to developers working on Fornjot itself.
Issue of the Week
One of Fornjot's goals is support for the web. It should be possible to embed a configurable Fornjot model in a website, where users can look at it, change the parameters, and even export it to external file formats.
We're not quite there yet. The next step would be to make sure that Fornjot can be compiled to WebAssembly. If that's something that sounds interesting to you, check out #815 - Compile Fornjot to WebAssembly.
My main priority remains implementing the union operation (#42), but I might have encountered the next detour: creating a low-level shape manipulation API for use in test suites. This is something I could use immediately, for the next step of the union algorithm implementation.
I'm currently looking into that. If I can come up with something good, it would be a huge asset for in-kernel test code, but it also has wider applications. It could even be exposed to users, as a low-level API for defining models. If it turns into too much work, I might decide to table it though, and find some workaround for my current need in the meantime.