The Godot lab

Godot makes the architecture easy to put in front of a real consumer. It has its own object system, script runtime, scene lifecycle and resource conventions. An external implementation has to meet those expectations if it is going to be useful inside an ordinary project.

The lab brings GDScript, native C++ and CUDA into that setting through common image contracts. The interesting part is how much each implementation can keep private while still becoming a renderer that the scene can use.

The walkthrough shows the captured application and links to the project.

Where the engine adaptation belongs

Godot class registration, Variant conversion and engine notifications belong to the GDExtension adapter. Requiring every independent provider to include Godot headers would make that separation rather short-lived.

The GDClass terminal instead inspects exported Abstract declarations and negotiates the capabilities it understands. It checks the callable surface, prepares the registration and conversion information, and acquires an independent runtime factory. Once that work succeeds, discovery can be released. Godot uses the emitted class and retained runtime interfaces afterward.

This gives the provider a way to expose domain behavior without writing another engine bridge. It also puts conversion decisions in a visible place. When a terminal doesn't understand the declaration's value contracts, it has to decline rather than invent a plausible conversion.

Letting the script supply the implementation

GDScript is often the client of a native extension. Here it can also be the provider: the script performs image operations and supplies its own admission policy through the common adapter.

That changes the pressure on the bridge. A script object has a different lifetime from a native receiver, and the same request can have a very different cost. The script must be able to keep its objects alive and refuse excessive synchronous work without the consumer reaching around it to another implementation.

The native providers have their own reasons to specialize. C++ can use PocketFFT, while CUDA can keep intermediate images resident and avoid transfers until an observation requires them. Publishing the interface doesn't imply downloading the pixels.

Bringing the toolchain into the project

The project-source CUDA path takes another step. A project supplies CUDA source and assigns image meaning to its kernel entries. The CUDA service supplies the compiler, program, buffer and kernel facilities needed to run them.

The CUDA service can compile and execute the source without knowing what a convolution means. The image provider supplies that meaning and interprets the kernel entries. Another domain could use the same compiler without adding its own vocabulary to the CUDA service.

The scene controller discovers operations from renderer nodes and combines their offers by UUID. A project-specific effect can therefore appear as a new choice without adding an implementation-name switch to the controller. Renderers that don't offer it remain free to decline.

What the example is testing

The rendered check changes the source and overlay, adds a renderer, and discovers a project-specific operation. Other tests exercise provider refusal, callable identity, native/script boundaries and release order. Together, they put pressure on more than the appearance of the final image.

There is much more we could build on that foundation, including richer engine surfaces or a source toolchain hosted inside Godot. The lab currently gives us the provider and adaptation model to test those ideas against. It doesn't yet supply a general Puffer workspace in the engine or an implementation of every other engine's behavior.

The repository and its visual check show the concrete path from the declarations to the running scene.