Solved Scope of the hashes returned by C4DAtom.FindUniqueID(c4d.MAXON_CREATOR_ID)

Hi,

I cannot find any information regarding the namespace of the unique IDs generated with C4Datom.FindUniqueID with the application id MAXON_CREATOR_ID. I was wondering if someone knows more about it.

Unclear to me is:

1. Are there any guarantees regarding the collision resistance of the method in general and with that application id in particular?
2. What is the context / namespace of the hash returned by .FindUniqueID(c4d.MAXON_CREATOR_ID)? In a quick test the string representation of the returned byte sequence of the 'same' node in multiple instances of a document did seem to be same, but ultimately MAXON_CREATOR_ID being defined in ddoc.h and the lack of documentation makes it unclear to me, when I can expect a node to be hashed into the same value and when not.
3. Expanding on that: Can modifications of the scene graph impact the hashing of a node? A quick test seemed to also indicate that this is also not the case.
4. Is the method hardware and software (i.e. operating system) agnostic?

Thanks for your help in advance ;)

Cheers,
zipit

@zipit said in Scope of the hashes returned by C4DAtom.FindUniqueID(c4d.MAXON_CREATOR_ID):

1. Are there any guarantees regarding the collision resistance of the method in general and with that application id in particular?

Not really this should not happen, but I can't tell its true in all conditions. In the end it's a16bits CRC so we can't really do a miracle here. For more information about how to identify objects, I let you read the nice answers provided by Riccardo in Why are GUIDs not globally unique?.

@zipit said in Scope of the hashes returned by C4DAtom.FindUniqueID(c4d.MAXON_CREATOR_ID):

2. What is the context/namespace of the hash returned by .FindUniqueID(c4d.MAXON_CREATOR_ID)? In a quick test, the string representation of the returned byte sequence of the 'same' node in multiple instances of a document did seem to be same, but ultimately MAXON_CREATOR_ID being defined in ddoc.h and the lack of documentation makes it unclear to me, when I can expect a node to be hashed into the same value and when not.

Internally I found only use case of the internal marker in the undo process (See NodeData Management used to keep track to which object is which one. Since undo are document-related I would say there "namespace" are document-related. But they don't really have a namespace, on the creation of the object a new marker will be generated and this marked will be based on some data stored in the document, but this is only done during the creation of the marker once you have an object with a marker you can clone and object with the flag
COPYFLAGS_PRIVATE_IDENTMARKER and the GeMarker will be the same, even if you insert this object into another document.

@zipit said in Scope of the hashes returned by C4DAtom.FindUniqueID(c4d.MAXON_CREATOR_ID):

3. Expanding on that: Can modifications of the scene graph impact the hashing of a node? A quick test seemed to also indicate that this is also not the case.

No as said the CRC is defined on the creation of the object based on the GeMarker of the current doc. But once the GeMarker is generated, then its generated and will be carried over the lifetime of a BaseList2D.

@zipit said in Scope of the hashes returned by C4DAtom.FindUniqueID(c4d.MAXON_CREATOR_ID):

4. Is the method hardware and software (i.e. operating system) agnostic?

There are scene agnostic (saving/loading a file doesn't modify the marker) but their generation depends on the current mac address.

Hope it answers your question,
Cheers,
Maxime

MAXON_CREATOR_ID is used to get the ID stored in the internal GeMarker.

From what I can read, it seems that this ID is unique for each element in a given document.

See Unique ID and GeMarker Manual.

Hi,

thanks for pointing out the GeMarker manual. Confusingly enough it states:

Warning

These markers change when the source object is copied or when the document is re-loaded.

But my tests with FindUniqueID did not seem to follow that rule regarding multiple instances of the same document. It also would make the hashing somewhat pointless if it could not cross the document instance boundary. I understand that the hashing cannot be boundless and perfectly collision free (or is at least very hard to do), but I am still confused on what Cinema does guarantee and what not.

Cheers,
zipit

@zipit said in Scope of the hashes returned by C4DAtom.FindUniqueID(c4d.MAXON_CREATOR_ID):

1. Are there any guarantees regarding the collision resistance of the method in general and with that application id in particular?

Not really this should not happen, but I can't tell its true in all conditions. In the end it's a16bits CRC so we can't really do a miracle here. For more information about how to identify objects, I let you read the nice answers provided by Riccardo in Why are GUIDs not globally unique?.

@zipit said in Scope of the hashes returned by C4DAtom.FindUniqueID(c4d.MAXON_CREATOR_ID):

2. What is the context/namespace of the hash returned by .FindUniqueID(c4d.MAXON_CREATOR_ID)? In a quick test, the string representation of the returned byte sequence of the 'same' node in multiple instances of a document did seem to be same, but ultimately MAXON_CREATOR_ID being defined in ddoc.h and the lack of documentation makes it unclear to me, when I can expect a node to be hashed into the same value and when not.

Internally I found only use case of the internal marker in the undo process (See NodeData Management used to keep track to which object is which one. Since undo are document-related I would say there "namespace" are document-related. But they don't really have a namespace, on the creation of the object a new marker will be generated and this marked will be based on some data stored in the document, but this is only done during the creation of the marker once you have an object with a marker you can clone and object with the flag
COPYFLAGS_PRIVATE_IDENTMARKER and the GeMarker will be the same, even if you insert this object into another document.

@zipit said in Scope of the hashes returned by C4DAtom.FindUniqueID(c4d.MAXON_CREATOR_ID):

3. Expanding on that: Can modifications of the scene graph impact the hashing of a node? A quick test seemed to also indicate that this is also not the case.

No as said the CRC is defined on the creation of the object based on the GeMarker of the current doc. But once the GeMarker is generated, then its generated and will be carried over the lifetime of a BaseList2D.

@zipit said in Scope of the hashes returned by C4DAtom.FindUniqueID(c4d.MAXON_CREATOR_ID):

4. Is the method hardware and software (i.e. operating system) agnostic?

There are scene agnostic (saving/loading a file doesn't modify the marker) but their generation depends on the current mac address.

Hope it answers your question,
Cheers,
Maxime

Hi,

thanks, that answers all my questions.

Cheers,
zipit