To the author: this work you've published rests on some background knowledge that I'm familiar with but also a lot of background knowledge that's foreign to me. For the parts I was able to follow, I thought the mental gear-turning was enjoyable and interesting! But pursuing these intersections between algebra and computer science is often not so interesting, at least, when I research it myself. Is this something you've learned in university? I ask because I fear that without a formal learning environment, I may never pick up on the more advanced logic halfway through the article. Anyway, cheers to the good work.
Yes, I studied theoretical computer science in University, but I believe the article should be accessible to anyone with a willingness to learn some of the background material. E.g. there are many good introductory texts on the lambda calculus. For a great introduction to the fast growing hierarchy I can recommend
David Metzler's Ridiculously Huge Numbers [1] series on youtube.
I've done this with C++ in the past, but ran into substantial friction with the CMake toolchain, specifically w.r.t:
- cross-platform compilation with large dependencies (vcpkg ports)
- running multiple compiler chains in the same build step
That second point is necessary if, for example, there's some AOT asset processing work that uses a native tool, and you're building for web. Expressing that some targets should use the emscripten toolchain while others should use the native toolchain, and interleaving between them, was a mess. TBF, I haven't done that with cargo or build.rs yet and it may prove to be equally frustrating.
Other features:
- undo/redo using a stack of swappable states
- serialization to disk (native) and LocalStorage (web) with some integration tests in progress but I am not satisfied with the correctness of my implementation: I want to *guarantee* that all information is preserved round-trip, but I also want a Patek watch.
- OBJ, GLTF, GLB models are loaded as "blueprint scenes" which are distinct from the "world scene." I made this distinction at the type-level because "scenes" are groups of entities that use newtype IDs (`LightId(u64)`, `MeshId(u64)` etc.) as primary and foreign keys to refer to each other, and I wanted to make it impossible for an entity in scene A to hold an ID for an entity in scene B. Instantiating a blueprint requires creating new IDs for every object.
- W.I.P. Alpha rendering, depth sorting, overhauling the material system to support multiple shaders (tough) that may be compiled after the engine itself (even tougher, a lot of runtime dynamic state and schema validation stuff), physics, scripting - oh yeah!
- Scripting using JS on both web (runs in browser itself) and desktop (uses a packaged JS runtime `Boa`) but Boa doesn't perform well on desktop in debug mode so I'm exploring other options.
