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

Toni Alatalo toni at playsign.net
Mon Nov 23 13:54:54 CET 2020

I'm not convinced that it can't be done nicely and with good performance in
an addon, but did not find definite information.

There is a 2009 issue in the Python tracker about UUID being slow, later
the discussion moved to another ticket, and it has been resolved in 2017.
Apparently operating systems have native calls for UUID generation which
Python uses when those are available. So you don't need to write some own
pure Python implementation.


I'd consider uuid1 because the computer network and time information is
helpful to avoid collisions, and I don't see terrible privacy concerns for
this application.

"Generate a UUID from a host ID, sequence number, and the current time. If
node is not given, getnode() is used to obtain the hardware address. If
clock_seq is given, it is used as the sequence number; otherwise a random
14-bit sequence number is chosen."

Anyway others know better how to have this nicely in Blender so I'll leave
it to you.


On Mon, Nov 23, 2020 at 2:36 PM Lissanro Rayen via Bf-committers <
bf-committers at blender.org> wrote:

> You are correct. As Harley Acheson noted, 128-bit UUID can be considered
> globally unique. Even in the scenario I was describing in my previous
> message, when there are copies of the same .blend files with an object
> with the same UUID, it is easy to make it globally unique for any
> practical purpose - just regenerate UUID in the copy.
> I recently worked on implementation with 32-bit hashes - unlike 128-bit
> UUIDs, 32-bit can only be considered unique within one file (this was
> sufficient for my purposes), since chances of random collision are
> pretty high even within my own collection of .blend files, if I would
> have generated 32-bit UIDs for all objects within them.
> 128-bit UUID is much better in this regard, chance of random collision
> is practically 0, unless you make a copy of it, but then it is not
> random and it is expected, even useful for some purposes - if you see an
> object with the same UUID, it is practically guaranteed to be either a
> copy or derivative of the original object with the same UUID (unless its
> UUID was regenerated to make it globally unique).
> If Blender had UUID support, it would saved me a lot of time and effort,
> since the only reason I ended up implementing 32-bit UIDs (instead of
> 128-bit like UUID supposed to have) is that my addon already had 32-bit
> hash function for generating Cryptomatte IDs, and I just reused it for
> generating random UIDs, this way I did not have to add a function for
> 128-bit hash. Even 32-bit hash function implemented in pure Python does
> not have good performance, if there is a need to process large number of
> objects. But loops in Python are often slow in general, so this is
> expected. Because of this I had many difficulties in my implementation,
> and it took a lot of effort to achieve acceptable performance when there
> thousands or even tens of thousands of objects in the scene.
> My point is, even though implementing UUID support in Blender addon is
> technically possible, it is inefficient and complicated. If there was
> native UUID support, I would not need to write all this additional code
> and the performance would be much better too. And there are many other
> use cases for UUIDs so many addons could benefit from native UUID
> support in Blender if it will be implemented in the future.
> On 23/11/20 11:25 am, Toni Alatalo via Bf-committers wrote:
> > 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
> >>
> > _______________________________________________
> > 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