July 30th Update - Rig Utilities updates

What’s happened?

Today was mostly spent working on the Rig Utilities. To begin, the entire source V4 codebase got nuked in favor of a new, fresher architecture that’s more focused on utility than the previous alphas. I will not be officially releasing a new pre-release version until the new codebase has caught up to the other in terms of features. There are going to be a few direction changes, and while some of the code from V3 and early, non-AI edited versions of V4 are going to be reused, the overall extension is going to be a fresh rewrite.

Architecture Changes

The architecture is being shuffled a bit, as of now, the plan is to make the SACR UI’s external plugins which make use of the features granted by the plugin. Though some versions of SACR, such as R7.4.1, require the UI for some of its settings, namely any enumerated property reverts to a string property, making it unreadable by the Driver’s on the rig. Eventually I’d like to phase out the UI for R7.4.1, though that may be a while.

The new codebase is going to focus a lot on modularity, I’ve learned a lot about Object Oriented Programming while working on the Blender Development plugin for Pycharm, including more proper object structuring and organization. While Python may not be as strict as Kotlin when it comes to OOP, using a hybrid functional/object approach with a focus on modularity will be key to maintaining a solid codebase.

Rig Manager

The rig manager is getting a minor shift in focus, the system in prior versions of V4 included both a managed download section and a presets section. This new codebase will narrow the purpose to simple version retrieval from my website, while the save presets operations will be moved to a hybrid of Blender’s own asset system and the UI.

The biggest thing I worked on today was rewriting the manifest retrieval system. What’s the manifest? Well, the “manifest” is a JSON data file who’s original purpose was to help populate the SACR download page on my website. The data includes all the necessary metadata including download urls, making it a great source of truth for downloading and managing SACR artifacts.

On the website side of things I added a small pre-commit hook which copies the internal copy of the sacr-index.json, the one used to help populate the SACR page, into the publically accessible data alongside a generated SHA256 payload. Once that was finished, I began the Python Backend to be able to retrieve this file alongside it’s new companion, with appropriate validation, repair, and deduplication checks to ensure proper data management.

Skin Changer

The skin changer for the most part is going to remain the same as it was in Alpha 3 with a significant focus on stability. For the most part, I’m happy with how that system functioned, but it does need some work to be stable. The download logic for the skins for the most part is sound, so it will mainly be a matter of building the new UI around it.

Conclusion

I took more time to focus on the codebase today, instead of blazing through with Codex like I typically do on the Blender Development project, and it shows. Using Codex as more of a teacher and reviewer instead of writing the code itself shows as the manifest downloader, as of now, is extremely stable, safe, and effective. I aim to continue this new workflow through the rest of the project, and tomorrow I hope to focus on the core UI system to download and manage the versions. Some of the work is already done, as the basic skeleton of the UIList is present, just needs everything else around it.

Here is where I leave for the night, goodnight and until next time!