I tend to agree with Matt, and to be really honest granting UID persistency
in a large software is frequently done on the side, specifically with that
intention, and either user controlled, or if left to heuristics either very
conservative or very changing (IE: at what point do you decide to lock an
ID? On creaiton? On Topo change? What happens if you swap the primitive
like you can do with Curves?).

Your best bet is emulating the above yourself by tagging objects at the
stages you want to ID them, and changing it if and when you need it. It's
actually not hard to do in terms of difficulty, but it can result in a
large and pervasive toolset before it's reliable enough, which is probably
why Michal outlined he'd rather avoid it.
It's what we do in a couple places actually to support name agnostic
operations in our pipe (plenty renaming happening since, in example, the
same rig can be imported several times for different characters).

I'm afraid there's little alternative to controlling this yourself, and to
be honest this is a rather generig CS problem more so than it's a Softimage
specific one.
The Identity of an item is a very ambiguous and volatile concept that every
user and pipeline will have a different idea of the extent of.

What Soft might want to do is offer an open parameter with a creation ID,
that way there's always something fairly static couple with the object, and
leave it to the user to modify it if they require more frequent mutation
than the first time the primitive comes into existence. This will need to
be wrapped around by every command offering creation of sorts. Gets,
Extracts, Duplicates and so on.
Log the request if you feel it's important.


On Wed, Jun 5, 2013 at 9:49 AM, Ciaran Moloney <[email protected]>wrote:

> Yeah, I figured as much.
> Not that I doubt Matt's observations, but it would be nice to have some
> official word on the reliability of this method - unique ID's are a request
> that come up all the time.
> In the mean time I'll proceed with caution, since it's the simplest
> general purpose solution.
>
> Ciaran
>
>
> On Wed, Jun 5, 2013 at 12:35 AM, Raffaele Fragapane <
> [email protected]> wrote:
>
>> I doubt it's an issue with GUID at an algorithmic level, if two identical
>> GUID could be produced by the same person on the same project, and
>> therefore the conflict noticed, the windows world would be in very deep
>> S*** :)
>> Identical GUIDs on one platform should be centuries apart.
>>
>> It's more likely a case of generation/re-use on Soft's side, either
>> intentional for non-obvious reasons or a bug.
>>
>>
>> On Wed, Jun 5, 2013 at 9:00 AM, Ciaran Moloney 
>> <[email protected]>wrote:
>>
>>> So, if the GUID isn't unique, that's a pretty lousy algorithm....
>>> Luckily, I haven't observed that so far.
>>>
>>> Ciaran
>>>
>>>
>>> On Tue, Jun 4, 2013 at 11:57 PM, Matt Lind <[email protected]>wrote:
>>>
>>>> Object GUID is persistent, but not granular enough.  I’ve run into
>>>> cases where multiple items get the same GUID.   Same goes for CLSID.***
>>>> *
>>>>
>>>> ** **
>>>>
>>>> Matt****
>>>>
>>>> ** **
>>>>
>>>> ** **
>>>>
>>>> ** **
>>>>
>>>> ** **
>>>>
>>>> ** **
>>>>
>>>> *From:* [email protected] [mailto:
>>>> [email protected]] *On Behalf Of *Ciaran Moloney
>>>> *Sent:* Tuesday, June 04, 2013 3:55 PM
>>>>
>>>> *To:* [email protected]
>>>> *Subject:* Re: Persistent objects ids****
>>>>
>>>> ** **
>>>>
>>>> Yes, you're right...I can reproduce a change of ID when deleting an
>>>> object and re-opening a scene. However, I would not dismiss the object
>>>> GUID, which appears to persists between sessions despite the change in the
>>>> object ID value. In the below snippet the sphere object changed ID but not
>>>> GUID.****
>>>>
>>>> ** **
>>>>
>>>> # Name: cylinder****
>>>>
>>>> # ID: 114****
>>>>
>>>> # GUID: {090F2A9A-D1FC-4112-ACC5-9345BEB48954}****
>>>>
>>>> #****
>>>>
>>>> # Name: disc****
>>>>
>>>> # ID: 92****
>>>>
>>>> # GUID: {D03EF191-3962-4540-929D-F5438CE59D79}****
>>>>
>>>> #****
>>>>
>>>> # Name: torus1****
>>>>
>>>> # ID: 68****
>>>>
>>>> # GUID: {1AC14CC7-1175-4E30-9CDD-BC0C0C1DE6EA}****
>>>>
>>>> #****
>>>>
>>>> # Name: sphere****
>>>>
>>>> # ID: 80****
>>>>
>>>> # GUID: {CC63558A-D5A3-4F55-8621-6D428FE2743A}****
>>>>
>>>> # --------------------****
>>>>
>>>> ** **
>>>>
>>>> # Delete cylinder, save and re-open scene ****
>>>>
>>>> ** **
>>>>
>>>> # Name: disc****
>>>>
>>>> # ID: 92****
>>>>
>>>> # GUID: {D03EF191-3962-4540-929D-F5438CE59D79}****
>>>>
>>>> #****
>>>>
>>>> # Name: torus1****
>>>>
>>>> # ID: 69****
>>>>
>>>> # GUID: {1AC14CC7-1175-4E30-9CDD-BC0C0C1DE6EA}****
>>>>
>>>> #****
>>>>
>>>> # Name: sphere****
>>>>
>>>> # ID: 99****
>>>>
>>>> # GUID: {CC63558A-D5A3-4F55-8621-6D428FE2743A}****
>>>>
>>>> #****
>>>>
>>>> # --------------------****
>>>>
>>>> ** **
>>>>
>>>> ** **
>>>>
>>>>  ****
>>>>
>>>> On Tue, Jun 4, 2013 at 6:38 PM, Matt Lind <[email protected]>
>>>> wrote:****
>>>>
>>>> This is not safe between sessions as IDs are dynamically generated and
>>>> assigned in the order objects were created in the scene.  If an older
>>>> object is deleted and the scene reopened, everything after it will have a
>>>> new ID.****
>>>>
>>>>  ****
>>>>
>>>> Matt****
>>>>
>>>>  ****
>>>>
>>>>  ****
>>>>
>>>>  ****
>>>>
>>>> *From:* [email protected] [mailto:
>>>> [email protected]] *On Behalf Of *Ciaran Moloney
>>>> *Sent:* Tuesday, June 04, 2013 8:52 AM
>>>> *To:* [email protected]
>>>> *Subject:* Re: Persistent objects ids****
>>>>
>>>>  ****
>>>>
>>>> Hi,****
>>>>
>>>> did you try XSIUtils.DataRepository.GetIdentifier() passing the
>>>> siObjectGUID argument?****
>>>>
>>>> I've used this to keep track of ICE nodes without relying on name
>>>> strings. It's persistent between sessions and is preserved when models are
>>>> exported. ****
>>>>
>>>> Works like a charm.****
>>>>
>>>> The only problem is that it's possibly a bit tricky to get a pointer
>>>> back to the object, since you need to know what you're looking for. I use 
>>>> Application.FindObjects()
>>>> to get a collection of objects of this class, then check for the ObjectGUID
>>>> I'm looking for.****
>>>>
>>>>  ****
>>>>
>>>> Ciaran****
>>>>
>>>>  ****
>>>>
>>>>  ****
>>>>
>>>> On Tue, Jun 4, 2013 at 12:49 PM, Michal Doniec <[email protected]>
>>>> wrote:****
>>>>
>>>> Hi,****
>>>>
>>>>  ****
>>>>
>>>> Is there any obvious way I am missing which would allow me to identify
>>>> objects in the scene, but not by name?****
>>>>
>>>> Something like ObjectID, but persistent between scene saves and
>>>> loads. I can generate UUID or something similar using "ObjectAdded" event
>>>> and store custom property but I'd rather avoid it.****
>>>>
>>>>  ****
>>>>
>>>> I want to be able to track objects regardless if they were renamed or
>>>> not.****
>>>>
>>>>  ****
>>>>
>>>> --
>>>> ----------
>>>> Michal
>>>> http://uk.linkedin.com/in/mdoniec ****
>>>>
>>>>  ****
>>>>
>>>> ** **
>>>>
>>>
>>>
>>
>>
>> --
>> Our users will know fear and cower before our software! Ship it! Ship it
>> and let them flee like the dogs they are!
>>
>
>


-- 
Our users will know fear and cower before our software! Ship it! Ship it
and let them flee like the dogs they are!

Reply via email to