Yes, it's not Softimage related problem, it just happened that I have to do
it (again) in Soft and thought I've forgotten about some obvious
method/shortcut.

ObjectIDs will change between sessions and in some other cases, hence I
can't use them, I'll have a look at GUIDs out of curiosity. I am very
likely going to do what I've always done (ie. managing some sort of unique
IDs myself) - this discussion got me thinking though - as Raffaele said,
there is so many scenarios and variations in regards to creation time and
management/update time of unique IDs that I think it's better to leave it
to user to implement it.

Thanks again everyone, great ideas and info.



On 5 June 2013 01:39, Raffaele Fragapane <raffsxsil...@googlemail.com>wrote:

> 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 
> <moloney.cia...@gmail.com>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 <
>> raffsxsil...@googlemail.com> 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 <moloney.cia...@gmail.com
>>> > 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 <ml...@carbinestudios.com>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:* softimage-boun...@listproc.autodesk.com [mailto:
>>>>> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Ciaran Moloney
>>>>> *Sent:* Tuesday, June 04, 2013 3:55 PM
>>>>>
>>>>> *To:* softimage@listproc.autodesk.com
>>>>> *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 <ml...@carbinestudios.com>
>>>>> 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:* softimage-boun...@listproc.autodesk.com [mailto:
>>>>> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Ciaran Moloney
>>>>> *Sent:* Tuesday, June 04, 2013 8:52 AM
>>>>> *To:* softimage@listproc.autodesk.com
>>>>> *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 <doni...@gmail.com>
>>>>> 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!
>



-- 
----------
Michal
http://uk.linkedin.com/in/mdoniec

Reply via email to