Why are GUIDs not globally unique?

Helper

On 18/08/2017 at 14:06, xxxxxxxx wrote:

Martin, attach few expression tags and you will get always changing addresses/pointers of objects. Same object remains untouched, but you make a mouse click and it changes and it will report to dirty flags, and most likely to ID assigning staff that you must remove/add things (not just update them slightly). Welcome to Cinema 4D >:E :))
Let's ask Maxon to solve this ID issue and update the API for recent couple of major Cinema versions.

Helper

On 18/08/2017 at 15:56, xxxxxxxx wrote:

i also would like is to be able to identify objects by using an unique object id.
as stated here BaseObject.GetGUID() is not unique (?)
and even if it is, there is no method to get the BaseObject if you just have the GUID.
(is there one?)

btw it would be nice if it wouldnt be just an in-memory id,
but would stay the same when quitting the app and reopening the file.

ps if you str() an object you get
<c4d.BaseObject object called 'Null/Null' with ID 5140 at 0x1412bd6d0>
is this hex address usable for indentification?

Helper

On 28/08/2017 at 01:31, xxxxxxxx wrote:

I have found that the best way to identify an object that is not in a cache is to use AddUniqueID(). This should be serialized to the file as well. It has been working fine for me.

If you don't care about changed IDs with cloned scenes or re-created objects, you can always use GeMarker().

My problem is that I actually have scenes where ALL visible geometry is exclusively coming from object caches. This is where my approaches start to fall appart. Most of the time I can rely on FindUniqueID() of the CacheParent() and the UniqueIP() to reconstruct a unique identification. Unfortunately, this breaks with ojects like the subdivision surface object who do not assign uniqueIPs and also do not make the generator source objects identifiable.

@zeorge: having the GUID, traversing the document to get the BaseObject should not be that time consuming. Even with several thousand objects.

Helper

On 28/08/2017 at 03:56, xxxxxxxx wrote:

If I may drop some insight here on why GUIDs might not always be unique: It's likely due to the use of crc32. In scenes with many objects, especially many generators used, there will be collisions.

I ended up calculating GUIDs myself, only using UniqueIPs, hasing them with xxHash (https://github.com/Cyan4973/xxHash), fixing some of the obvious shortcomings by adding dummy IPs for generators - or something like that, it's been a while.

Works pretty well for uniqely identifying objects across frames of an animation - unfortunately it's useless for identifying objects across insertions/deletions in the scene.

Originally posted by xxxxxxxx

Actually the plan is to add the info to the SDK docs.

Please add "not using crc32" to said plan.

Helper

On 28/08/2017 at 04:29, xxxxxxxx wrote:

From what I've experienced, the identical GUIDs were not due to hash clashing but actually objects that where generated from the same source object, thus being "identical" to them. Unfortunately, that makes it impossible to identify the generated objects

I also use hashing throughout my parsing and use 64-bit SipHash (https://131002.net/siphash/).

Helper

On 01/09/2017 at 09:44, xxxxxxxx wrote:

Thanks both Yves and Martin for keeping your insights to come.

@fused: actually we internally use CRC64 which make the chance to get GUID collisions really unlikely; the reason because there might be equal GUIDs in the scene is mostly related to how GUIDs are currently generated.
@assoc: to reduce (not to exclude) the chance to avoid GUIDs duplication you can enumerate you objects in the scene by setting their IP (BaseObject::SetUniqueIP()) using something like:

  
const Bool SetObjectsIP(BaseObject *op)  
{  
  Int32 ipnum = 1;  
  while (op)  
  {  
      if (!SetObjectsIP(op->GetDown()))  
          return false;  
  
      op->SetUniqueIP(ipnum++);  
  
      op = op->GetNext();  
  }  
  
  return true;  
}

As I've described in my previous post, we are aware of the fact that caches might end up in sharing the same UID, and we are also aware that unique identification is a pretty relevant topic for interactive rendering purposes. That said I'll try to rise up in the future an internal discussion on the topic to see if and how the desired behavior could be addressed.

Best, Riccardo.

Helper

On 04/09/2017 at 00:13, xxxxxxxx wrote:

Thanks Ricardo.

Yes, using SetUniqueIP() is what I would expect to be used by generators that have several objects in their caches. As I am parsing the scene - not generating objects myself - I have no influence how other generators are handling UniqueIPs.

In this regard, I noticed that the Subdivision object does not use UniqueIPs. So I am having a hard time to identify the generated objects between scene changes because they don't have UniqueIPs. So I was trying to use their GUID as fallback but then noticed that the Subdivision object had objects with the same GUID in its cache as well. The GeMarker unfortunately does not help either as it changes frequently.

So I have this case where all methods of the SDK to identify generated objects in a cache fails.

Thanks,
Martin