Finally I've made some progress on the 3D renderer replacement.

As noted in yesterday's update, finding a way to integrate a fully custom 3D renderer that wants to own its own swap chain with the JUCE GUI has not been totally obvious. Today I spent a lot of time attempting to get the JUCE GUI to render in a Windows HWND that had the WS_EX_LAYERED property, so that it could be partially transparent, with the 3D graphics rendered to an HWND beneath it. This would have had the advantage that all of the overlaid controls (the toggle buttons for camera mode, reset button, and so on) would work. However, WS_EX_LAYERED has some bad performance consequences, because Windows needs the pixel data on the CPU side to do hit tests -- it allows mouse clicks on transparent pixels to fall through to the window beneath.

So that approach turned out to be a no-go. But eventually I realized that there's a much simpler solution, which is to just draw the 3D graphics in a window that's on top of the JUCE GUI. Originally I didn't think this would work, because the 3D graphics would overwrite the GUI elements that pop up, such as the right click context menu. But I was being stupid: those pop-up menus are in actual OS pop-up windows. This is why when you record the Anukari window in OBS (and not the full desktop), you don't see the pop-up menus in the recording.

So actually everything works how I want if I just create an HWND and assign it to the 3D graphics. The pop-up menus appear on top, because they are native OS windows. Now, the one drawback is that the JUCE GUI elements that hover over the 3D graphics will have to be redone in terms of the 3D renderer, but that's not a huge issue, it will be easy to do. I've already figured out the weird HWND setup to get mouse clicks and keyboard events to pass through to the JUCE GUI. So basically on Windows I see a clear path to this all working. I have a glTF model displaying using Google Filament.

I am pretty sure that this same approach will work fine for MacOS as well, but obviously that's the next thing I have to test before I start rewriting the renderer using this approach. Fingers crossed...