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

Bastien Montagne montagne29 at wanadoo.fr
Wed Dec 2 11:01:10 CET 2020


Hi,

After talking with Brecht we agreed that having optional UUIDs for our 
data-blocks would be 'nice to have'. A design task was created for that:

https://developer.blender.org/T83019

We do not have currently any developer available to work on this 
project, but we would of course welcome a patch implementing this proposal.

Cheers,
Bastien

On 11/16/20 8:00 PM, Brecht Van Lommel via Bf-committers wrote:
> 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
>>
> _______________________________________________
> 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