Maya Extension Plugin
Where it started
Started as a personal project for connecting a commonly used DCC (Maya) to the ECS driven architecture of a template for the custom engines we use as a base in my studies.
This project quickly evolved into circumventing the need for a complex and feature heavy in-engine editor, as it allowed for maya to essentially have any custom engine stemming from the template to use it as an editor
Engine Template
Where it stands
In the most recent iteration of this plugin, it utilizes a reflection system in the custom engine (which I explain more about here) to assign certain components and pass them on to a custom ".components".
The Maya side of the plugin then can load any instance of those file types to use for assigning gameplay functionality to objects in the scene/object.
Since all the gameplay logic in an ECS based engine is in the systems, and the components are just shells that hold the specific instance data that the logic is applied on. Any components placed in Maya will directly translate to gameplay features once the engine runs the scene.
Plugin Showcase in Maya (Complex component test)
The real treasure was the code we made along the way
What you see above in the demonstration is the Maya side of the plugin, in that Demo I showcase most if not all the possible types of information that the plugin is able to get from the engine. Thus it was meant as a test case not for any specific use, so I will add below a simple demo I made with a use case in mind.
The idea was to simulate a case where the user would want to populate the scene with treasure chests that can have different items inside. In the engine I wrote a very simple system that checks proximity to any entities with a 'Treasure' component and if the user presses a key it will open the chest and print all of its contents, if there are none it will print "Nothing". Pressing on the key again will close the treasure chest.
Treasure chest demo
Under the hood
Unfortunately this code is part of a team project for the university and as such is private, so I will use this section to show some pseudocode and explain a few aspects of the Maya side of the plugin, a sort of 'behind the scenes'
JSON-Driven Component Mapping
The engine exports a JSON file describing every component type and its member fields — each with a name and a type tag (string, vec3, float, message, etc.).
On launch the plugin deserializes this file into a dictionary and passes it straight to the UI system. This means any new component added on the engine side's reflection system is automatically available in Maya.
Type-Mapped Attribute Widgets
When a node is selected the plugin reads its custom attributes and spawns the right Qt widget for each type — a checkbox for bools, a spin box for numbers, a text field for strings, and a special "pick object" button for message (reference) attributes.
Each widget writes back to the Maya attribute on change, through a callback, that gets cleaned up on deregistration of the plugin to make sure there are no leaks.
Attribute Construction: Dynamic Compound Attributes
When the user assigns a component to a Maya node, the plugin reads that component's field list from the loaded JSON map and builds a matching Maya compound attribute on the fly.
Each field type gets special treatment:
# Vec3 - expands into three float children (x, y, z).
# Message fields - creates both a connection attribute and a hidden string attribute to back-store the linked
node's name.
# Simple types like bool or float - map directly.
The result is a fully inspectable attribute hierarchy on the node that mirrors the engine's component struct exactly.