I'm getting closer to being able to release the next version of the pre-alpha installer. Today I finished up some basic stuff that the new renderer needs to go live.

One thing I frequently do when building out something new is instead of adding proper error handling, I'll just add assertions everywhere that an error can happen. This is obviously a no-go for production code, but it helps get the core functionality up and running much more quickly. This is especially useful when I'm not sure whether what I'm building will work, or I'm not sure about the architecture I've chosen. The assertions help make sure everything is working correctly, and then once I'm happy with the core code I can go through and replace them all with real error handling. I can be sure I removed all the assertions because I have a pre-submit that rejects them.

In this case, I had to do a little bit of wiring to get errors out of the 3D rendering thread into the main GUI thread to display to the user in a thread-safe way. That's all done now.

I also took the time today to redo the camera rotation & pan controls based on a suggestion from joey. Rotation is now done by an unmodified right-click drag, and pan is shift + right-click drag. You no longer need the middle mouse button, which is nice on touchpads where you can't do it like MacOS (but it's there if you want on desktop, or touchpads that do 3-finger tap).

I am still not super happy with the camera controls, but today I had an idea for how to make them even easier. Blender has a nice little widget in the corner of the window that shows the camera orientation, and you can left-click drag it to rotate the camera. I don't really use this, as I prefer the hotkeys/mouse, but it's much more discoverable/approachable, and possibly easier for some people on touchpads. Plus it will work with touchscreens. I'll extend Blender's idea a bit to add panning as well. But this will probably wait for a while.

Next up is fixing some issues with window resizing on MacOS. I think that I'm not correctly handling the fact that Retina displays have 2 physical pixels per 1 logical pixel.

Today I spent some time figuring out why the new Filament renderer took a little longer to load than I wanted. It turns out that virtually all the loading time came from the fact that I was using the JIT shader system, which makes sense because it had to compile a shader for every different combination of material properties that I used. This is great for rendering efficiency, as the shaders only include the minimum code needed to support the given features, but it imposes a startup delay that cannot be avoided because Filament does not offer async compilation.

Anyway the solution for now is to use the "ubershader" model, which is a little bit less efficient on the rendering side, and loads almost instantaneously. I can't measure a performance difference for the shaders, probably because Anukari's scene is so simple. So this will suffice for now. Later I can always build my own materials that are both minimal and precompiled, to get the best of both worlds.

After getting the 3D renderer loading more quickly, I worked on getting the GUI elements that float above the 3D renderer to work. Initially I was planning to implement these in Filament, which would be ultra-fast. But I thought it about it some more, and realized there were issues, like font rendering, that I didn't want to have to deal with. So instead, I ended up implementing the floating GUI via native OS child windows that are displayed above the renderer.

This works great, and is efficient. The only drawback is that at least on Windows these OS windows can't have transparency, so I will have to redo the circular GUI buttons as square buttons. Which... will probably look better anyway. These buttons were always going to be replaced, so it is not a big loss.

All of this work means that I'm much closer now to releasing a new pre-alpha build of Anukari. Barring anything unforeseen, I think I can do that within a week. This is exciting, since this will be the first build that uses Metal for all the GPU work on MacOS (both audio and graphics), which I am hoping helps with the performance issues that some people are seeing.

I'm trying to wrap up work on the new 3D renderer, I really am, but... it added so many new possibilities that I have gotten distracted by adding cool rendering stuff.

Today I added something I've wanted for a long time, which is having a bunch of animations based on parameters and physics stuff. For example:

• Bodies get bigger and smaller based on mass
• Bodies get duller or shinier based on damping
• Springs get thicker based on stiffness
• Springs get redder based on tension
• Links light up based on the signals they pass through

There's more than can be done here, but these were the basic things that were easy to do. Here's a demo:

I also got some non-cosmetic work done today, mostly around making the new renderer more stable. If I have one chief complaint about Google Filament, it's that it is a complete train wreck with regards to how objects that you create using the APIs get cleaned up. Some objects you have to manually delete. Some you have to pass to Engine::destroy(). Some have object-specific destroy functions you have to call. Some objects you have to allocate yourself, and of these, some you delete and some Filament will delete. And pretty much none of these semantics are documented. It's a total design disaster. Anyway, making sure everything gets cleaned up correctly has been a chore, but I think I'm there (for now).

I think tomorrow I will go back to just trying to get the renderer infrastructure finished, so things like handling vsync correctly, fixing some issues with the 3D window resizing, and getting the 3D assets to load faster. After that I will fix the 2D GUI overlay on the 3D graphics, and hopefully cut a new pre-alpha release pretty quickly.