[Bf-committers] Proposing a unique ID for Blender objects system, for use with game engines.

Brecht Van Lommel brechtvanlommel at gmail.com
Mon Nov 16 20:00:52 CET 2020


I can see how this would solve a real problem and improves usability when
exporting assets to Godot.

Note that USD explicitly chose not to use UUIDs. But I can see how this
makes more sense for simpler pipleines that don't follow more strict naming
conventions or fix up names afterwards.
https://graphics.pixar.com/usd/docs/index.html#IntroductiontoUSD-NoGUIDS

To me a UUID makes sense when you want to make a connection between two
completely different databases. Like Blender and a game engine, or an asset
manager that manages data from multiple applications. Any time you have to
do that kind of syncing and no longer have a single source of truth, it's
not an ideal situation in the first place, but UUIDs do help.

It can be misused as well. For example I've heard requests for this so
add-ons can store relations to Blender datablocks at runtime, or saved in
.blend files. To me that would be a mistake, as references to datablock
should be done explicitly with pointers that are managed by Blender, that
can be properly referenced counted, cleared, replaced, etc. Also for
library linking datablocks between .blend files this is tempting, but again
it also comes with it own set of issues.

If this were to be implemented, it does raise some questions:
* Would we want to do this for every datablock? Presumably not because the
memory overhead and cost of generating a UUID, so I guess it would be
something that is generated on demand.
* Are UUIDs supposed to be unique within one .blend file, or globally
unique across all .blend files? What happens when you copy or rename a
.blend file, do the UUIDs change?
* Do overrides copy the UUID or generate a new one? I'm guessing it should
generate a new one.
* What about datablocks that are the result of geometry nodes evaluation?
How does this UUID remain stable if geometry nodes can output an arbitrary
number of objects, that might even vary over time?
* How does this relate to the asset manager design? There was some
discussion of having UUIDs for that though no conclusion. If it is needed
there, would that UUID be the same?




On Thu, Nov 12, 2020 at 5:24 PM Juan Linietsky via Bf-committers <
bf-committers at blender.org> wrote:

> Hi guys, lead Godot dev here.
>
> I wanted to discuss with you a problem we are often having that I am not
> certain how it can be solved entirely from our side, I add a proposal for
> this, but if you guys have a better recommendation, I'm very open to any
> ideas.
>
> Basically, Godot will import scenes (GLTF/FBX/DAE/etc) as they come from
> blender, and it generates the same object names, resource names, etc. as
> they come from Blender and the resource file.
>
> We use the same names so we can keep track of changes in the Blend file. If
> an object is moved, a material is changed, etc. we detect on re-import and
> everything is updated in Godot.
>
> This is especially more annoying in Godot than in other game engines,
> because Godot can read the whole Blender scene and keep it more or less
> intact, so users love using this for level design workflow (so they can
> design levels in Blender).
>
> So, the problem is that it often happens that for some reason, artists want
> to rename the objects in Blender. Be it because they didn't care at the
> beginning and they want to become more organized later, or because the
> scene became bigger and they need to make their naming of things more
> precise to navigate it around. In this situation, when something is renamed
> on the Blender side and re-exported, the game engines have no idea where
> this object went, so we need to either remove it (resulting in loss data)
> it or orphan it (resulting in duplicated data).
>
> While I do think that good practices solve this and this is probably not
> such an issue in a professional environment, truth is that game development
> has become a huge hobbyist activity, and our users find this situation
> constantly and are annoyed with it, and there is nothing we can do from our
> side.
>
> The obvious proposal to solve this would be to ask Blender whether it's
> possible to generate a unique object ID (UUID?) and make sure it does not
> change over time even if objects are renamed, then changing the exporters a
> bit to (optionally if selected in the export settings) add this information
> as extensions in the existing format (on GLTF it should be rather easy).
>
> If you guys think this is possible, it would be very helpful for us, if you
> have other ideas on how we could solve this, we are very open to
> discussion.
>
> Best
>
> Juan
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>


More information about the Bf-committers mailing list