MaterialsObserver>texture change>>3 events

Developers Ruby API
, ,
1

Hi,

I have noticed a completely unexpected behaviour from MaterialObserver.

When I load a new texture to a material the Observer gets 3 onMaterialChange() events. One would be enough.

Is there a way to tell when the first event is caught that we are dealing with texture change?

I can think of weird workarounds, like starting a timer and waiting until no increase in onMaterialChange() calls happens within given time.

There are two subsequent events issued when a textured material is coloured and a single event when a colour of untextured material changes.

Could we have a specific event - when texture changes? I think currently there is no way to tell what has changed within material. Updating a texture in external software is relatively the most “expensive” action. It is not good being forced to save material texture to a disk with every single material change - say when in-model texture size is modified.

Maybe there could be an indication in onMaterialChange() of what actually has changed within a material ?

2 Likes
2

Observations (using SketchUp v 2018):

Change a material object’s name manually via Materials panel OR Ruby code.

onMaterialChange() fires once, followed by onEntityChange() firing once.

Change a material object’s alpha (via Ruby code.)

onMaterialChange() fires 3 times, followed by onEntityChange() firing once.

Change a material object’s color (via Ruby code.)

onMaterialChange() fires 2 times, followed by onEntityChange() firing once.

Initial set for a material object’s attribute (which creates an attribute dictionary.)

onEntityChange() fires once.

Change for a material object’s attribute (in existing attribute dictionary.)

NO observer fires on material object proper.
onEntityChange() fires once on the material’s attribute dictionary object.

Initial setting a material object’s texture manually.

(Ie, checking “Use texture image” and selecting a PNG from the file browser dialog.)
onMaterialChange() fires 4 times, followed by onEntityChange() firing 2 times.

Changing a material object’s texture file via Ruby code.

onMaterialChange() fires 4 times, followed by onEntityChange() firing once.

Checking the “Colorize” checkbox manually.

onMaterialChange() fires once, followed by onEntityChange() firing once.

Change a material object’s colorize type (via Ruby code.)

onMaterialChange() fires 2 times, followed by onEntityChange() firing once.

Change a material object’s texture size manually with aspect lock OFF.

(Note, the values must change for the observer on the material object to fire. If the value was the same and resulted in no actual change, the materials observer does not not fire, even though the observer attached to the Texture does.)
onMaterialChange() fires once, followed by
onEntityChange() firing 2 times on the Texture object.

Change a material object’s texture size manually with aspect lock ON.

onMaterialChange() fires 2 times, followed by
onEntityChange() firing 2 times on the Texture object.
(I think the double callback on the material is caused by SketchUp adjusting the 2nd size to match the ratio from the user’s size change.)

Change a material object’s texture size via Ruby code. (Aspect lock no difference.)

onMaterialChange() fires 3 times, followed by
onEntityChange() firing once on the Texture object.

Reset a material object’s texture color manually (after it has been changed from that calculated from the texture image.)

onMaterialChange() fires 2 times on the material, followed by
onEntityChange() firing once on the Texture object, followed by
onMaterialChange() firing once on the material, followed by
onEntityChange() firing once on the Texture object.

I agree with Tomasz, this is just ridiculous.

3 Likes