It is hard to get models out of Blender into Godot (correctly and without loosing half the work).
Gamedev relevant open-source projects should come together to create a new 3D interchange format. More in the GitHub discussion.
I’ve submitted this proposal to other open source projects as well:
Ah, so it’s (mostly?) about animation? Because from my very limited unprofessional tinkering I was blown away how amazing just throwing a .blend file into Godot works (as opposed to eg in Unity)
Behind the scenes, Godot uses Blender to export your ‘.blend’ file into glTF 2.0. It doesn’t support keyframe tangents, animating anything beyond transforms and blendshapes. Among many many other issues if you look at glTF in an interchange context. I’ve written that down in way more detail here: https://gist.github.com/emperorofmars/d8abf0f4b9bd5434f9543511b243a254
In Blender, right now, you can’t export animations that target anything other than transforms. (I am aware of the two hacks to allow you to also export blendshape animations). Blender 4.4 will get a new animation system, which fixes that part. But you still can’t export your animations properly, it will force bake them.
Way more than animations go into 3d assets, it’s just the most broken part right now. An extension system would be rather nice, or a material system that doesn’t hard define a small set of properties^^
Ah, didn’t know it converted to gltf, interesting. Yeah, bit it looks like we could really use a file format that is designed to translate between 3d program s and game engines …
Can 3D substitution* animation be exported from Blender? This isn’t easy to search, though what I could find seems like importing animations in general needs more clicks than expected. Even better would be a workflow with greasepencil and geometry nodes (though searching w/Godot leads to a paid tool), especially if that can also be used for vertex colors.
I have my doubts here as the first thing I tried (a custom shader with a 2nd vertex color map hooked up to glow) didn’t work. Though I’m not sure if that was an issue with gltf, Blender, Godot, how I exported it, or something else.
*= Switching visibility to another model rather than using deformation or texturing. If this does not export easily, I guess it’d be easy enough to manually do with Godot’s animation player so long as there aren’t too many frames/animations/states.
There have been so many attempts of that over the years…
From the proposal:
USD is not ‘just a 3d format’. Its scope is far bigger and more comparable to an entire game-engine project rather than a single asset. It can make use of FBX files, and it could make use of this proposed format in the same way. USD does not replace FBX, or any other file format like that, and it’s very complex.
I don’t want to bash on USD, but its use is mostly in the VFX world, which vastly differs from game-dev.
Also, last month, I tried to get a model from Blender 4.2 to Unity 2022 in USD. It omitted the main armature. I quadruple checked all settings^^
That Godot plugin you linked uses Blender to import USD files to convert them to glTF 2.0, which then will actually get imported in Godot.
Collada has been deprecated in Blender.
What you said is patently wrong.
As someone who works with USD daily digging through the bowels of the code and working with the format at a root level, it is 100% something that gaming should (and is) adopting. The Godot team would be frankly stupid not to put full native USD support as a high priority. The ability to store rigs, transform animation, and easily encapsulated asset variations alone makes the format godly. It is also very clean in how it manages asset linking and scenegraphs which makes traversal a breeze to encode. Also, it makes an DCC agnostic format which allows game developers to engage with freelance artists and not care what they use. Houdini, Blender, Maya, C4D, and any future DCC are going to be able to export to it. Hell, Houdini (my preferred DCC) has an entire context dedicated exclusively to working with, rendering, and exporting USD format.
Its scope is far bigger and more comparable to an entire game-engine project rather than a single asset.
I would have thought that applied to ANY universal 3D format. For everything you might want to work, to work, the feature-set that must be implemented is truly mind-boggling.
I can’t imagine a format only supporting a subset of what USD does, ever becoming universal.
I feel like the problem is Blender and Godot have different needs when it come to models. Godot is real time and blender is slow but far more capable in what it produces. It would be extremely difficult to make a new format that can handle both use cases. I think what we really need is a “best modeling practices guide” for godot/gamedev. My biggest issue when I never know what will work and what doesn’t. I don’t think we need a new format just more documentation and guides for modeling in blender for gamedev.
You can’t create 3d models in Godot. (To be pedantic you can, but it’s not made for that)
Blender can perfectly produce models intended for real time rendering. It also has the Eevee renderer^^ Whether a 3d file stores 10k or 10M vertices doesn’t matter. It’s on you, the asset creator, to know the requirements of your project/customer/employer. Blender, or any other tool, should not impose any artificial restriction on that.
The model made in Blender should arrive in Godot without having lost any data that both tools do support perfectly. The thing that holds the model while it goes from one to the other, either looses half the work, or Blender itself refuses to put in big parts of your work, because they weren’t able to fully and correctly reverse engineer FBX.
I’m not faulting Blender developers for the reverse engineering, I’m arguing for a format that does the basics right, isn’t proprietary, and hopefully extensible.
This is the correct take. Game devs have been creating game-optimized models using the same tools as other 3d artists for decades.
I feel like the blender and Godot communities should have enough overlap to provide a steady stream of documentation and tutorials.
I would love to see a tutorial showing a minimal game built from the ground up including modeling, texturing, and animating models in Blender then transferring them to Godot and building the game. Instead people seem to focus on one app or the other and hand wave away the details of the transfer.
I haven’t been following the lay of the land for the last 20 years, but it was the same problem then. Some things don’t change.
3d studio max was the big player. .3ds was proprietary, binary and undocumented. They had an ASCII export, but it was bugged. The guys at moppi had an improved ASCII export plugin that solved those issues.
Collada was just around the corner, but seemed quite over-engineered.
@emperorofmars to me the biggest problem with gltf is its extensibility cannot actually be easily used without heavy export/import work per extension.
was reading about your stf endeavor … would it be possible to abuse the 3d format further by embedding extensions in the file itself?
Yes, so much yes on the first part! Want to implement the simplest thing in UnityGLTF? You have to fork it, and force all your users to use your very special fork.
I assume you mean my ‘nna’ project with the second part? That serializes data into the node-names of the model’s hierarchy. It is as stupid as it sounds, but it works reliably, and I don’t need to modify any exporter/importer. The data is part of the file itself.
If you wanted to embed data into a format more legitimately, you would have to modify its exporter/importer, and the format would have to support extensions in the first place.
Isnt this a mostly solved problem? (Not in Godot, but so far as such a format existing)
A lot of stuff works with USD.
