Entity ID and Materials!

[Marc477]

I discovered that the entityID (for materials) is not the same when getting it from the Ruby API or the cpp SDK:

Example (using the same material in both example)

Ruby API

//aMat is a material
aMat.entityID
//Returns 183 

Cpp SDK

//aMat is a SUMaterialRef
int id;
SUEntityRef entity = SUMaterialToEntity(aMat );
SUEntityGetID(entity , &id);
uint matID = (uint) id;
//Returns 201

I tested this using a custom attribute dict to make sure it is the same material in both cases, it seems that the material in the SDK has always an ID of +18, and if I don't cast it to a uint, its value is always negative.

Why ?

[tt_su]

entityID are not persistent. They are not serialize in the SKP file format. Whenever you read a file they are regenerated.

[Marc477]

Then how can I find: starting from a ruby API material: the corresponding SDK material ?

[Marc477]

I don't really understand how it is possible to have no persistent ID. In the skp file: how each face knows to which material it is bound? I supposed there is an ID saved with the face that tells which material is linked to the face.

[TIG]

Any Material will have a unique '.name'.

So that is effectively its 'ID' spanning sessions...

[tt_su]

The serialization and serialization use its own way to store the material references for each face. But entityID is not something restored between sessions. As TIG mentions, the material name is the persistent ID for materials.

[Marc477]

Ok thank you! I though 2 materials could have the same name.

[jiminy-billy-bob]

@tt_su said:

As TIG mentions, the material name is the persistent ID for materials.

But the name can change, right? How is that a persistent ID?

[tt_su]

@jiminy-billy-bob said:

@tt_su said:

As TIG mentions, the material name is the persistent ID for materials.

But the name can change, right? How is that a persistent ID?

It's persistent in the sense that it will have the same name when you reopen the file and for as long as until you change it - as oppose to entityID which will change. And it's an ID because you cannot have two identical material names in a model.

[jiminy-billy-bob]

Yeah but the plugin has to be installed and active to keep track of name changes.
As opposed to groups/instances GUIDs which will remain the same no matter what. The plugin will always be able to retreive it.

For me that's a huge difference.

[tt_su]

@jiminy-billy-bob said:

Yeah but the plugin has to be installed and active to keep track of name changes.

Yes a GUID is a different animal. I see where you are coming from.

[TIG]

In that case you need to give the material you want to keep track of an attribute that will endure across sessions and is thereby independent of its 'name' etc.
tid = Time.now.to_f some_material.set_attribute("matID", "tid", tid)
Now save 'tid' in some meaningful data collection 'external' to the SKP, or say in an array in an attribute dictionary attached to the model itself...

Later on you reopen the model and you want to find a specific material that has some recovered 'tid' float value...
material = nil model.materials.each{|mat| if tid == mat.get_attribute("matID", "tid", nil) material = mat break end }
If the material has been deleted you get no match - material == nil - and you adjust your stored data collection accordingly.
Otherwise it exists...
You can also batch process a model.materials, and if there is not one already you add a 'matID' with a 'tid' attribute to each material, and also update the stored data collection...

[jiminy-billy-bob]

Yeah TIG, I already do just that with layers

But calling the name a "persistent ID" was not right to me.

[Marc477]

Also, I found that 2 materials CAN have the same name in a specific case: If you name one material Color_000 for example, it will be named like the Sketchup internal material of the same name: [Color_000]. (It seems that the SDK removes the brakets '[' and ']' when you get the name of an internal material with SUMaterialGetName()).

[tt_su]

Ah, yea - there is name and display_name - at least in the Ruby API. name is the unique one that should be used to refer to materials. display_name should be used only to display the material name to the UI.

However, it appear that the C API doesn't quite do that. Let me have a chat with the rest of the team.