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

[Toni Alatalo]

Just a bit of echo,

AFAIK UUIDs are a good solution to deal with integrating Blender and many
kinds of other systems with which we want good integration, via exports or
even two-way export-import cycles.

Back about 10 years ago, we made a pretty cool integration from Blender to
a Ogre3D based virtual worlds system, realxtend.org, in rex2blender Blender
add-on which was developed by Caedes (Pablo Martin, Crystal Space and
Blender add-on dev at the time).

It also used UUIDs to know which objects from Blender, maybe continuously
reimported to the game engine side, were the same objects as in a previous
export. Worked well, I don't recall any problems, though the design is
certainly not trivial when you think of how to deal with the issues
mentioned here, duplicates, copies of the same project file etc. But having
real UUIDs there always helps, whatever you decide to do, and it never does
any harm (except mem use if you go really low level, but we only considered
it on object level).

In my understanding, they really should be globally unique, not within a
blend. That's the first U in UUID: *Universally* unique.

We work with BIMs a lot now, and they also have UUIDs in the format spec,
but I recently learned that many BIM creation tool vendors have been
stupid, and just put whatever IDs there, sometimes even overlapping IDs
within the same project, and with zero quarantees of those IDs being unique
cross projects, or different creation tools. So it's just sad and useless,
all the folks who write import tools need to create new sensible IDs.
Learned that on twitter here:
https://twitter.com/xeolabs/status/1320671615441686529

So please, real UUIDs, afaik the math for it works well.

2cently yours,
-Toni

On Sun, Nov 22, 2020 at 9:03 PM Lissanro Rayen via Bf-committers <
bf-committers at blender.org> wrote:

> In theory, you are right. But in practice, chance of collision in many
> real-world scenarios is 100%. As an example, consider the following
> scenario:
>
> I have a .blend with some objects ("A"), all objects in it already have
> generated UUID. I open the file, edit something, save as different file
> ("B"). Then again I open the original file, and save it under different
> name ("C"). Then I create new empty file and append objects from "B" and
> "C". If I append the same object from both files, there will be UUID
> collision. But this is not an issue as long as there is a check to make
> sure that each appended or duplicated object has unique UUID in the
> scope of the current .blend file, and if not, just reset its UUID (it
> can be generated later on demand if necessary). I think this is
> preferable to blindly regenerating (or dropping) UUIDs, since if there
> is no collisions, I may have a reason to preserve UUIDs as is when
> appending my objects. Besides, Blender already does collision detection
> for object names to automatically rename them if it happens. But for
> UUID, it is safe to just invalidate it if it conflicts with another UUID
> of already existing data block, and generate a new one later when
> necessary.
>
> On 21/11/20 6:33 pm, Harley Acheson via Bf-committers wrote:
> >> It would be impossible task to make them truly unique across all .blend
> > files, there are always a possibility of collision.
> >> UUIDs have limitations...will not change unless there is a collision).
> > That does not sound right.
> >
> > If 128-bit UUID are implemented properly according to standard, the
> chances
> > of collision is *zero* *for all practical purposes*. The chances of
> > collision are so low that implementations can ignore it. To get to a 50%
> > probability of at least one collision you need to create 2.71
> quintillion -
> > so generating a billion of them per second for 85 years.  Just to get a
> > one-in-a-billion chance of a duplicate requires making 103 trillion.
> >
> > Cheers, Harley
> > _______________________________________________
> > 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
>