UUID missing in (some?) older files?

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.)

Thanks,
Sol

Looking through the openNURBS 5.0 code, it looks like this might be the block of code responsible?

  // make sure objects have valid ids
  m_model.m_object_id_index.Empty();
  m_model.m_object_id_index.Reserve(m_model.m_object_table.Count());
  for ( i = 0; i < m_model.m_object_table.Count(); i++ )
  {
    ONX_Model_Object& mo = m_model.m_object_table[i];
    if ( ON_nil_uuid == mo.m_attributes.m_uuid )
    {
      ON_CreateUuid(mo.m_attributes.m_uuid);
      change_count++;
    }
    m_model.m_object_id_index.AddUuidIndex(mo.m_attributes.m_uuid,i,false);
  }

This seems like really bad news for my purposes – is it actually impossible for end user code to tell when m_uuid is meaningful rather than random for this run?

Hi @colomon,

Not all versions of Rhino used uuids. This is most likely what you are running into.

– Dale