The saga continues. I finally got a complete draft that makes sense to me. But I gotta read it again later, with fresh eyes. And if I still like it then, it needs a few more rounds of review and edits.
Writing is hard, but getting it right is quite rewarding. Maybe I'll need to write about why I don't use LLMs to write my sponsor updates next 😂
Update on the sponsor update: I abandoned my first draft. The second one seems more promising, but hasn't quite come together yet, and is already too long.
There's still a chance I'll write about something completely different instead, but I'll give it another go tomorrow.
I started writing this month's update for my Fornjot sponsors. The topic: my stance on LLMs, and why I don't use them to write code.
Not sure, if I'll go through with it. It's a big topic, and I don't know if I can do it justice without making the update way larger than I like those to be.
I guess the 3MF validation issue can wait, while I address my technical debt.
Update: I think I figured out that the arc approximation code can trigger the divide by zero in a totally valid edge case.
This is code that I imported from the latest experiment. I think it's time to rip it apart and rebuild it from the ground, with a bullet-proof test suite.
Why am I working on a CAD kernel again? Shouldn't, like, somebody who actually know this stuff be doing this? 😂
And now I'm back in the arc approximation code that already gave me lots of trouble when I wrote it in the first place, trying to re-understand it, to figure out exactly which edge cases would trigger the issue, and what the proper ways to handle those would be.
I'm running into a divide by zero issue in the math code though, and since I don't understand what's causing that, I decided to fix the problem properly by making the affected function fallible, forcing all calling code to deal with the problem properly.
I'm trying to port the spacer model (github.com/hannobraun/f...) to the new API, to confirm my hunch about the 3MF validation issue. Of all models in the repository, it should be the simplest that triggers the problem.
And if it does end up fixing the 3MF validation problem, that would be great, because it means I can probably continue to never touch or think about my crusty C bindings to lib3mf, for a few more years.
Filtering the internal triangles shouldn't be hard, but to do it properly requires more structure in the topological graph. This needs to happen anyway, to support the upcoming Fornjot-internal validation infrastructure. So whether it fixes the problem or not, it's not a detour.
But now I suspect that lib3mf is more strict in this regard. And it's probably a good idea to filter those triangles in any case, even if they were valid in 3MF files, to not confuse software that uses STL files, for example, or that uses a less robust implementation of 3MF than PrusaSlicer.
Earlier experiments filtered those internal triangles before exporting the 3MF file, but the latest code doesn't. When I saw that this didn't cause any errors in PrusaSlicer, I was like "this works? neat!" and proceeded to never really think about it again.
I think the problem is that models with holes have faces that touch each other. In the final triangle mesh, this leads to internal triangles within the model.
All that is hard to explain in this format, but there's an issue describes the idea: github.com/hannobraun/f...
I'm still procrastinating on the 3MF validation problem, opting to port the simpler cuboid model (github.com/hannobraun/f...) instead, while improving the new API along the way.
Since that worked out, I now have a strong suspicion on what's causing the validation issue with the more complex model.
This means that only 4 non-deprecated libraries are left:
- `fj-core` for the essential stuff.
- `fj-export` (depends on core) for export to external file formats.
- `fj-viewer` (depends on core) to view Fornjot models for debugging purposes.
- `fj` as a convenient entry point.
While I've been procrastinating on my 3MF validation problem, I've simplified the zoo of Fornjot libraries: `fj-interop` and `fj-math` are now part of `fj-core`.
I was really enjoying how those just worked and it seemed like I'd never have to touch it again. But I guess that's over now!
My validator is using the the official lib3mf, and upgrading that to the latest version didn't help either. Now I guess I have to dig into my crusty, ad-hoc bindings that I wrote for lib3mf (a C library) years ago.
I have an annoying problem, trying to integrate the model from the latest experiment into Fornjot's regular infrastructure: My validator insists that the exported 3MF file is invalid. Yet both PrusaSlicer and the 3MF Consortium's viewer tell me the file has no errors.
I let `hannobraun.com` lapse, back when I was young and stupid, and one of those parasites claimed it afterwards, trying to sell it back to me. They gave up after 10 years though, and now I have it back for the regular cost of a `.com`.
So not all hope is lost, I guess 😂
But before I get on that, I need to integrate the model that the latest experiment defines into the models directory (github.com/hannobraun/f...), in a way that the automated integration testing setup can deal with.
I finished integrating the code from Fornjot's latest experiment into the existing libraries, cleaning up and documenting as I went.
This is only a first pass on both counts, and I also uncovered a bug. Lots left to do (mostly writing tests, I think), before this is up to the quality I want.
This month's sponsor update just went out. Summary here: www.fornjot.app/blog/sponsor...
I'll probably need another day or so to finalize the sponsor update. In the meantime, work continues on integrating the code from the successful experiment into the existing Fornjot libraries. I moved over the first module and have started cleaning up and documenting: github.com/hannobraun/f...
If you want to receive those updates, you too can become a sponsor! I couldn't have worked on Fornjot for so many years without that support. Sign up here: github.com/sponsors/han...
Just finished the first draft of this month's sponsor update, which involves a big update about the roadmap. If all goes well, it'll go out tomorrow. If not, most likely later this week.
I'm now going to merge the experimental code back into the mainline code, where it will replace the old core geometry code. I expect that to take a while, as it will involve a fair bit of cleaning up and documenting the experimental code.
A cube-like body whose edges are curved instead of being straight. The picture looks at it from one of its upper vertices, and the three edges connecting there are all bulging outwards. A rectangular hole in the body is visible in the top face.
The latest Fornjot experiment can now represent faces that are curved along two axes. This was my goal for this experiment, and more like the current (stale) mainline code can do.
