Captain's Log: Stardate 78201

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...

Captain's Log: Stardate 78061

Today I worked to finish some of the website cleanups that I want to finish before going back to the product code.

The biggest thing I did was create some tooling to create the database indexes and schema from TypeScript code, instead of through the MongoDB Atlas GUI. I want this so that it can be in version control, and also so that I can trivially apply the schema to a fresh database when bringing it up. This was simple to do and now the database is looking good.

While working on this, though, I discovered a heinous bug in the next.js server actions handling, which is that if any middleware returns a HTTP error or throws or whatever, the result from the server action function call will be "undefined", instead of an error being thrown. This is really horrible because depending on how your server action works, "undefined" might look a lot like null meaning "there was not an error." The next.js folks don't seem super-motivated to fix this, so I just changed all my actions to return a positive "success" message which solves the issue (because undefined can't ever be mistaken for a positive success like it can for a null).

Captain's Log: Stardate 78053.5

The Anukari website is now functionally complete, at least for the bare bones features that will be needed to start doing some early pre-alpha testing. There are still a number of details that I'd like to work out before stopping work on it and getting back to the VST code itself, but not a lot.

The APIs that the VST code will use to authorize the full version of the software are complete. The authorization is extremely simple: the VST sends a machine fingerprint along with the license key, and the API server checks that the license key is real, has remaining machine slots, and then signs the machine fingerprint and sends it back. I'm not doing anything to make this all hard to crack, but am simply adding a "lock on the front door." It will be a sign of success when someone kicks it in (cracks the software).

The web GUI for the user to manage their license keys (which mostly amounts to deleting machine IDs that they're no longer using, to free up quota for new machine IDs) works. I have an admin dashboard to create license keys in batches.

After I finish cleaning up the web stuff, the next thing I'll do is work on the c++ code to add the GUI that actually lets the user enter a license key, and makes the API requests to get the signed authorization. After that... I can start a pre-alpha basically anytime I want. 😉