Generated 3D gets rigged and animated + automated editor QA
This day the 3D-generation workbench pushed another big step toward "self-serve end to end": configure keys, generate, rig and pick animations, all in one flow; the editor gained automated end-to-end QA and "keep-alive" groundwork so it isn't killed when you switch away; the engine completed symmetric reclaim of GPU and audio resources so long play no longer bogs down; and games moved to a cleaner unified loading model.
Making capability more autonomous, and running more reliable
This day had two mutually-echoing lines. One is about "autonomy": turning 3D generation from a tool you must watch and operate step by step into a pipeline that runs "generate → rig → animate" through in one breath, with keys and modes configurable by the user in the plugin. The other is about "reliability": setting up automated QA for the editor, laying keep-alive groundwork for embedded running, and establishing a symmetric "borrow it, return it" rule for the engine's resource management. The former expands "what can be done"; the latter ensures "whether what's made is stable and usable long-term." The more a tool wants users to hand it work to run on its own, the more it must invest in reliability — the more autonomous the capability, the higher the demand on underlying robustness. This day pushed both forward together.
3D generation takes on the whole job: keys, generate, rig, animate
The 3D-generation workbench pushed another big step toward end-to-end usable this day, with several things together forming a complete pipeline. First, generation switched to a multi-view approach — guiding generation from several angles for a steadier, more on-target model shape. Second, you can configure the keys for several generation services right in the plugin, with a "real mode" master switch deciding whether to actually call a service and produce a model or first try the flow with placeholders; handing keys and the switch to the user means everyone can use their own quota at their own pace. Third, and most key: rigging plus animation. A freshly-generated model is just a static shell; to make it move, you first fit it with a skeleton (rigging), then put concrete motions on that skeleton. Both steps can now be done in the workbench — rigging can be automatic, and motions are picked ready-made from a built-in "motion browser." Stringing these together, "generate a character from a sentence → give it a skeleton → make it move" can be done end to end in one workbench for the first time, without exporting the model and fussing back and forth in other professional tools. For creators without modeling or animation skills, this pipeline compresses what used to take several professional programs and several stages into a few clicks in one panel.
Automated editor QA + it isn't killed on switching
This day set up an automated end-to-end health check for the editor. Specifically, a set of smoke tests automatically runs several different types of sample game — pure-code ones, ones with scene packs, ones that take the fallback path in a desktop environment — confirming each loads correctly in both edit and play without regressing. The value: the platform sees many changes every day, any of which could inadvertently break an existing game; with this automated check, the machine verifies all these samples before a change merges, keeping "changing A broke B" regressions out at the door. Meanwhile, the embedded editor was hardened, with groundwork laid for "keep-alive": the editor runs inside an embedded page, and when you switch between tabs or hosts, the browser sometimes quietly reclaims the temporarily-invisible one, so on returning your running session is already dead. This day's hardening and keep-alive groundwork are precisely to keep such switching from interrupting your in-progress work. Underneath, "auto-recover after a graphics device unexpectedly drops" was built into the engine, so such low-level accidents interrupt creation less.
Symmetric resource reclaim: no more quiet GPU and audio leaks
The engine established a symmetric "borrow it, return it" rule for resource management this day, marking the closure of a whole underlying foundation layer. Symmetric means every "request a resource" operation must have a matching, explicit "release the resource" operation — GPU resources (textures, buffers and the like) got a full set of release primitives so they're cleanly reclaimed when done; audio resources got deterministic reclaim too, cleaned up exactly when they should be rather than by garbage-collection luck. Why does this matter so much? Because a game may run for a long stretch, constantly creating and discarding resources; if something is "requested" but no one is responsible for "releasing" it, these unused resources quietly pile up in video and audio memory, accumulating until the game grows laggier and finally crashes. This "quiet leak" is the most insidious, hardest-to-diagnose killer of large scenes and long sessions, because it doesn't error in normal use and only erupts after running long enough. Making resource lifecycles strictly symmetric and deterministically reclaimable institutionally eliminates this class of leak. This day also formally marked this whole foundation layer of the engine's roadmap as complete — meaning the engine's low-level resource governance reached a milestone, and more complex things can confidently be built atop it.
Games move to a cleaner unified loading model
This day also tidied the sample games' loading approach, unifying them onto a cleaner model. Previously different games each had their own way of "loading their own scene resources" — some fetched, parsed and maintained their own catalog, logic scattered and prone to diverging. This day changed them to be fed uniformly by the "host": a game no longer arranges its own loading but has the runtime environment carrying it prepare the scene resources and hand them over directly. Each game's scene-resource files were also moved to a unified location that can be auto-discovered by scanning. Such changes are entirely invisible to users, but they eliminate the duplication and divergence of "a loading logic per game," putting all games on the same loading path. The benefit is twofold: later loading-related improvements need be made in just one place to benefit all games, no per-game adaptation; and problems are easier to diagnose — with everyone on the same path, a glitch means checking only that one path. Converging scattered approaches into one unified path is exactly the precondition for the whole game library to be consistently maintained and evolved.
What this day means
This day embodied two forces advancing together as an AI creation platform matures: one making capability more "autonomous" — 3D generation going from a tool requiring step-by-step human operation into a pipeline that runs the whole "generate, rig, animate" course on its own, with users controlling their own keys and modes; the other making the system more "reliable" — setting up automated QA for the editor, keep-alive for embedded running, symmetric reclaim for engine resources, and a unified loading path for games. These two forces seem one advancing and one guarding, but they're complementary: precisely because automated QA and robust resource governance back it up can more and more steps be handed to the AI to do autonomously; and the more steps handed over, the more indispensable these underlying safeguards become. A truly reliable automated system is never "let go and ignore" but "weave the net tight before letting go." This day both wove that net tighter and confidently handed more over.