Mars
Squeak
Shy Red Squirrel, if found give beer!
I make 3d avatars and assets for social VR games.
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.
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.
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.
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^^
I mention why USD does not work in 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. Godot doesn’t support USD.
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^^ USD may be very nice for VFX, gamedev is fundamentally different. I need ‘just a fileformat’. If USD just worked across the board, I would have likely just used that. It is very complex and appropriately hard to implement. In don’t fault Godot at all for not supporting it.