[Bf-taskforce25] unique integer ids for ID types

[Nathan Letwory]

UUIDs would be also an interesting way to go. Granted, it's 128-bits,
but that should still be ok to do with a set of integers. Using the
UUID algorithm I think we can guarantee that no ID block will have in
quite a long time. These UUIDs would be placed in the ID block name
field. The DNA namespaces can still be used (OB, ME, MA, etc), with
the UUID bytes just concatenated after it.

Additionally, it would solve some issues I have been thinking about
when working on dbblender, and that is precisely ensuring that there
won't be ID block conflicts across files.

The datablock ID then would be hidden to the artist, and a custom
property for Name can be used instead of the current naming scheme of
datablocks for users. This incidently would solve the name limit some
users find themselves looking at.

So, instead of adding a new field for UIDs, as per Joe's suggestion,
I'd suggest using the current name field for storing UUIDs and hide
that from the user, and present a custom string property to the user
instead for datablocks we want the user to be able to name.

This old name field would never ever change after being created, and
the custom name property would be changed.

IMO this would be a more future proof solution that can already be
implemented within the current data structures without breaking
anything.

This has been discussed before on IRC, with Briggs at least being in
favor (as I recall it) for something like this.

/Nathan



2009/6/11 joe <joeedh at gmail.com>:
> For ID blocks, we could just have two uids, one for the ID block and
> one for the source file it came from.
>
> Joe
>
> On Thu, Jun 11, 2009 at 12:31 PM, Brecht Van Lommel<brecht at blender.org> wrote:
>> Hi Joe,
>>
>> On Thu, 2009-06-11 at 07:13 -0600, joe wrote:
>>> I had an idea the other day.  What if we store a unique integer id
>>> (uid) in ID blocks, bones, nodes, etc?  This would solve a number of
>>> issues, as I see it:
>>>
>>> 1. RNA paths would be faster and more reliable to resolve.  If you
>>> rename an object, or a bone, or a material, the uid stays the same, so
>>> there's no need to go through and update existing RNA paths.  And
>>> looking up integer uids would be much faster then looking up names.
>>> 2. Things without names (e.g. nodes) require something like this,
>>> since basing the RNA paths off of simple indices would be far too
>>> unstable.
>>> 3. This might work for constraint targets, too; e.g. the constraint
>>> would store a uid, but present the user with the same UI of typing in
>>> a bone's name, of course.  This idea would probably need more thinking
>>> through, however.
>>
>> I think this would indeed simplify RNA path handling, and avoid messy
>> code to update RNA paths, or constraint updates on bone renames, etc. So
>> I'm in favor of this. It doesn't solve the problem of keyframes on
>> removed data staying there, though it's easy to code a function that
>> removes all invalid RNA paths (not sure when that would run, but at
>> least it you don't have to care about it while manipulating data).
>>
>> If this should be done for ID blocks too, I'm not sure. With library
>> linking mixing ID blocks from multiple files, it is a bit harder to keep
>> such uid's unique. However, for animato we may need to solve this
>> problem?
>>
>> If we have the restriction that RNA paths must always start from an ID
>> block and can not jump to other ID blocks, there is no problem. I would
>> really like to have this restriction, but from the animation discussion
>> that was held it seems like people would like to define animation at
>> scene or group level too, which would include ID blocks in the path
>> then.
>>
>> In that case, I would still prefer it if an ID pointer + RNA path is
>> used, where the ID pointer is resolved using the standard mechanism for
>> it. That moves some of the complexity to the animation system though, if
>> you want to support duplis, but I think an array of ID pointers + RNA
>> path would be sufficient to represent such things.
>>
>> Brecht.
>>
>>
>> _______________________________________________
>> Bf-taskforce25 mailing list
>> Bf-taskforce25 at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>>
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>
>