I’ve had to set aside getting our openNURBS code working with openNURBS 6.0 for a bit. But I cherry-picked one part of the work I did for that back to our current libraries: switching from using the index in the object table as the ID to using the UUID for the ID. In particular, I’m using on_object.m_attributes.m_uuid to get it.
However, I’ve hit on what seems to be a fairly major stumbling block here. One of my primary uses for ID is to identify objects between test runs. So if B-rep 9170505C-92DE-CD47-985D-E5D984656005e had certain properties in one run, I check to see if it has the same properties in the next.
The other thing I did because of the 6.0 work was adding the “official” 3dm sample files to my test suite. And the combination of these two things is showing me that for at least some V1, V2, and V3 files from the samples, on_object.m_attributes.m_uuid seems to have a different value each time I run the software.
Any hints on what might be causing this? Are all V1, V2, and V3 files just getting freshly generated UUIDs when you import the data? I’m only seeing the issue from files in your sample file set, which seems odd – I’m fairly certain we must have at least one other V3 file in our test suite.
I guess maybe what I’m looking for is a way to tell when the UUIDs are not from the file? (In openNURBS 5.0, mind you, though with luck I’ll need to know how to do it in 6.0 in the next month or two.)