In association with the upcoming interactive project of the Blender Studio we will be doing extensive testing of the interoperability between Blender as main DCC and Godot as game engine based on glTF as the main exchange format.
Our preceding experience as a studio in this regard is limited, but can be built upon our extensive experience with building a film production pipeline around Blender. Our focus here will be setting up a pipeline that accommodates a Blender centric workflow for all of the asset and level authoring and would ideally provide a seamless experience for working with Blender and Godot together.
The idea of this post is to collect the feedback and discussion points coming out of the project and opening up the conversation to others, especially also the Godot development community.
Actual development topics on the Blender side may be involved with the project itself or may be executed as a result afterwards, depending on scope and availability.
Am I understanding correctly, that the goal is to be able to create the levels themselves in Blender? So there would to be a dedicated Godot import, which properly prepares the assets, e.g. adds colliders, scripts, makes sure that there arenāt duplicate meshes and uses instancing instead?
There are already general mechanisms for this in place. The idea is to get a good grasp of the existing workflow and shortcomings and gather the resulting feedback.
The project is really rather small in scope, so additional development for it is limited. But yes, weāre targeting a Blender centric pipeline, so the more we can set up in a modular way in Blender the better.
For the time being this will probably mean setting up our own script-based solution for the project and using the experience to set it up in a more integrated way in the future.
Baking is a necessary step in game development in many cases regardless and regarding your point Iād rather invest into improving the baking workflow (which is also planned). Weāre looking at the flexibility of material import as well, but Itās not very likely that we will prioritize this in the scope of this project.
The plan is to make just the ālevel designā, I mean geometry and shaders, or even something functional? Iām thinking about geo-nodes procedural stuff that can work inside Godotā¦
That topic is far beyond the scope of this project. Our focus is on the Blender side as a DCC generating static output for use in Godot. Itās more so about keeping the process iterative without manual steps that need to be redone.
Really nice. Iāve been doing a lot of Godot tinkering lately and the blender ā godot path works reasonably well, but could use some polish, though I guess mainly from the Godot side.
On a side note, the Godot UI looks tantalizingly blender-like, but itās actually a ātraditionalā single-window UI (like Gimp/Krita). It makes me realize how good/flexible the blender UI is where you can tailor the workspace to your liking and put everything everywhere.
I would not recommend Godot (or any other app for that matter) to use blenderās actual UI code since thatās intertwined with blender too much, but I would love for them to adopt the way the blender UI works. With all of Harleys (and otherās , of course) great work blenderās UI getting really good!
The idea reminds me to Gnu Make. But something, which generates assets from Blend files, using rules. (Maybe with a āwatchā background process, like gulp)
Generating gltf for Godot from blend file would be a rule.
Another rule could merge blend files (together with its dependencies) for remote rendering.
A pattern Iāve seen over the years is that small game studios tend to set up less pipeline infrastructure than comparably sized film studios ā even when the overall ratio of artists to engineers is the same, the ratio of artists to pipeline engineers isnāt. You canāt reliably assume that small studios (let alone hobbyists and unfunded teams) will have someone who can hammer out ad hoc tools and python scripts, which means that a decent chunk of the industry is relying on manual āsolo artistā workflows.
DCCs donāt offer many middle-ground options for things like automated I/O, asset validation, and asset versioning, as they tend to assume that once you need āstudio levelā features, all of your artists will be using studio-managed workstations with tightly managed environment variables. Meanwhile, some of the top 100 games on mobile platforms are made by 100% remote teams who donāt even have an in-house export add-on; their pipeline infrastructure begins and ends with whatās achievable through github actions.
And they arenāt working that way because they want to. Theyāre working that way because, even if thereās a reasonable set of services they could deploy, there are too many unknowns in the provisioning and maintenance process for them to eat the up-front cost.
All of which is to say: Make sure you have a good set of user personas and make sure you extend them into team personas. The average team of Godot users can be surprisingly different from what you might be used to in film.
Well glTF and godot have one issue, they are considered as scene, so to be able to use a mesh as a āpartā you will need to save as mesh on import wich is annoying.
The disadvantage of scene is that when you change them and save them you canāt modify it on blender without loosing the change you made.
Alternatively you can use obj as they are considered as an arraymesh by godot.
You might be aware that Godot supports not only import of .gltf/.glb files, but also of .blend files directly (which uses the glTF pipeline behind-the-scenes). So working on the glTF pipeline is indeed the best way forward.
To summarize, the idea with the linked proposal (from the side of Godot contributors) was to create
GODOT_* glTF extensions for storing Godot-specific data in glTF data (such as to decide whether an object should be used for collision or not).
A Blender add-on which uses glTF2ExportUserExtension to store this data into exported glTFs + UI properties to modify this data.
Extend Godot (likely as part of the engine, but could also be implemented as a module/plugin) to parse this new extension data and apply it properly on import.
While developing and maintaining āThe Officialā add-on and data format for this is obviously not feasible from Blenderās side, this approach could help the team come up with a proper pipeline for the scope of a project. For example by replacing a custom glTF extension by using glTF extras (Blender custom properties).
Iāve already found interoperability with engines (Iāve used Unity, Godot and Unreal) to be quite decent already, but itās great to dogfood this.
I really think Godot and Blender have the potential to be (even more of) a powerhouse combo for open source 3D gamedev. Usually these workflows (from any 3D software to any game engine) rely on some third party conventions (fbx, gltf) with both ends just hoping for the best.
An āofficialā, maintained workflow (in the form of a Blender add-on as shown in that Github proposal) would be a dream come true and two steps above what exists today.
Looking forward to see what insights come from this project
The idea when working with Godot is that every asset you import is its own scene and it is instanced into the scenes that comprise the gameplay worlds. They may not be very big in scope, but Godot has robust methods in place to help you organize things.
The whole point with Godot development is to not copy the standard but seek to be better than the standard. The fact there is no distinction between prefabs and scenes for instance give a flexibility that would not be present otherwise, but you canāt just go in and expect to do the same things and perform the same workflows you have done in Unity or Unreal.
A major reason why a lot of promising new engines ultimately fade is that they simply try to copy the big boys (but with a few changes to make themselves ābetterā) rather than really make an effort to bring something new to the table. Godotās different approach to game design is really why it has gotten anywhere in the first place.
As for this project, it sounds good on paper, but it really sounds it continues the trend of lowered ambition as far as what Blender will need (no animation and rigging for instance). Even Yo Frankie! tried to do more with the old and crufty BGE in Blender 2.4x).
I was hoping for a Blender and Godot project for years.
Super excited to see what will be coming out of this. Both the project and the realizations about usage and interoperability. A solid foundation in both worlds can boost both plattforms further and I am excited to see this.
Thatās the thing i donāt have any experience with unity and unreal and i donāt think wanting to update a mesh without loosing the modification of the scene is a wild thing that will break godot.
Well itās free open source and lightweight, if gamemaker was the same there would be a lot more users.
How is it lowered ambition ? Blender is not a game engine anymore (something that people in the UPBGE discord are realizing day by day) if the goal is to make a better pipeline what is wrong with that.
Itās especially infuriating when you go to the godot github and report a problem only to be told itās on blender hands.
Speaking of in blender hands, they finally added the option to read metadata in godot 4.4 but you cant attach metadata to the blender scene so when you import a blend file in godot and you want to give it custom properties you are stuck by having to make an empty that will hold properties for you.
Itās apparently due to blender having multiple scenes by default while godot only need 1 flaged.
The chat i had with one Godot user start here Import/export GLTF extras to `node->meta` and back by demolke Ā· Pull Request #86183 Ā· godotengine/godot Ā· GitHub
His answer
That root node corresponds to the Blender scene itself. Blender scenes allow multiple root nodes, which is incompatible with Godot scenes that have exactly one root node.
The āproperā fix for this is to add a feature to Blender to allow it to optionally flag scenes as having a single root node. This is implemented in Godot here, it just needs Blender to add support for it. Meaning, you should open a proposal to Blender, not a proposal to Godot.
If you have never attempted a game project as a studio itās actually pretty good to start at this scale. There is absolutely nothing wrong in testing the warters on the first project. Game Projects tend to be able to spiral out of control pretty fast if you overestimated your scope or when feature creep happens etc.