[Bf-taskforce25] unique integer ids for ID types

[Ton Roosendaal]

Hi,

I agree with Brecht, use it for rna lookups, but stay away from IDs for 
a while... the whole library linking, duplication, proxying, animation 
re-use, etc. topic is on our agenda for after the summer, I rather 
tackle this with good insight and a lot of time to investigate the 
impact and come with a design that fits future usage.

-Ton-

------------------------------------------------------------------------
Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands

On 11 Jun, 2009, at 20:31, Brecht Van Lommel 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
>