State of Interoperability between Godot and Blender

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.

32 Likes

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?

Would it be theoreticaly possible to automatically recreate blender material nodes in Godot? For iterative workflow baking is huge pain.

1 Like

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.

3 Likes

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ā€¦

1 Like

Yeah, livelink-kid of stuff. Faster and easier turnarounds make all the difference.

2 Likes

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.

7 Likes

Yeah, it makes sense, otherwise youā€™d have to spend time developing another software.

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!

3 Likes

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.

6 Likes

based on glTF as the main exchange format

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.

5 Likes

This is the main friction point I noticed as well.

2 Likes

As a Godot contributor, this is exciting to hear!

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.

As for technical implementation, you may want to have a look at this detailed design document for inspiration: Create an official Blender add-on for Godot asset pipeline Ā· Issue #6883 Ā· godotengine/godot-proposals Ā· GitHub

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).

11 Likes

What a great initiative.

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 :slight_smile:

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).

2 Likes

All of this is fantastic news. :star_struck:

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.

1 Like

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.

10 Likes