"Sticky" materials

Some of my collections of textures in skm format behave perfectly in SU 2016 pro and earlier versions but in SU 2017 pro and SU 2018 pro there is a real problem as described below. (I am on an iMac 5k running High Sierra 10.13.1).

In the problem sets, whatever material I use first cannot be changed for another. If I apply a material to a face and then try to apply another material from the set to a different face in the model, only the first selected material can be used. I can change materials if I pick from one of the problem free sets however.

I presume there is something in the skm file that the later SU versions are reading and choking on.

My workaround is to either use SU 2016 for materials or to use eneroth’s material extractor and drag the resulting model into mine. The extracted materials work OK. The problem with the latter approach is that I need to apply all the materials in the sets to a bunch of faces first in SU 2016 since the extractor only works on materials in the model, not collections of materials.

A better solution would be welcomed.

hi Chris,

just had another look and I can replicate the behaviour on El Capitan, so that eliminates one possibility…

I also re-wrote one of the document.xml to no avail…

it’s a huge slow loading library and I think there are better ways to access them in v18, but I written it yet…

do you have access to the source images to save me extracting them?


Unfortunately I do not have the source images.


the problems seems to be the new internal method…

The #unique_name method is used to retrieve a unique name from the materials collection that is based on the provided one. If provided name is unique it will be returned, otherwise any trailing indices will be replaced by a new index.

SU is assigning all with the name as <auto> due to a naming format error in each .skm…

this means it carries on applying the original <auto> until you find one with a different name…

it does not appear to be ‘appending’ auto in v18, which I’m sure it did in the past…

I think there is a bug as well as the error xml’s causing the <auto> name in the first place…

on hover the display name is showing correctly but internally only one is used due to this bug…

mats.each{|m| p [m.name, m.display_name]}
["<auto>", "<auto>"]

@tt_su have you heard of this happening…

@chrisjknight do you really need such large textures?

I remade them at a smaller file size… [was 138MB now 17MB]

they load much faster and still look ok on 2.5m sheets although the gif shows them badly…

PM me your email and I’ll send them…


That’s great detective work! Thank you very much. In all likelihood I do not need such large textures and I should be grateful if you would send me those you have modified. I will PM you my email.


I can probably make 2 or 3 versions for LOD type usage as it’s mostly automated now…

I extract the images from the zip…

I just use sips to resize the originals that are 300 dpi with a lot of internal errors…

feed them back into SU then create/save a Duplicate of the ‘In Model’ materials…

SU writes the new .skm files…

even a one to one conversion will reduce the file size they are so bloated…

I needed a big folder of textures for testing a new materials extension I’m working on…


That’s just a new API method - should not affect the UI logic.

How are you applying the materials? Via the paint bucket tool, or Entity Info?
Can you share an example .skm material that demonstrate this?

@tt_su, it’s the ‘Egger wood’ set from the SCF store…

there is a THREAD there, where Chris left a sample .skp file, but both Dave and I d/l the collection to test further…

I could replicate on my mac, but have now dumped the folder…



I think it’s a mac thing, here’s a gif…



Good Evening

I’m experiencing the same thing, using a Mac as well, in my Sketchup Pro 2017

Is there a solution to this at this time?

Kind regards


It does appear to be a problem with only one of my Texture sets, and does happen in Pro 2018 too.

I’m therefore guessing that this set is somehow damaged.

which texture set?

there are a lot out there…


Hi @john_drivenupthewall

It is the “Weave” set. Last week I purchased the set from Sketchucation and have only just had the chance to try them today.

It is part of the ‘Cyber Material Collection’

All my other texture sets work ok.

Kind regards


So, I thought I might have found the problem…

I have two sets which do not work correctly, and when I looked at them, the file format was different to the sets which are working correctly. For example, in a set which is working ok, the file same is;


In the set not working, the file name is in a different format;


I wondered if the underscore and capital letters were causing a problem, rather than the hyphen and lower case letters in the working sets.

So… I edited the file names in the set not working correctly, to match the sets which do. Hence;

SUC_Fabric_001.skm became suc-Fabric-001.skm

I had fingers crossed, and for a moment, thought ‘A Ha!, solved!’ Alas, it made no difference.

I noticed that when I hovered over the texture in Sketchup, it still showed ‘SUC_Fabric_001’.

So, back to the drawing board.

Anyway, thought I’d share that. I’d like to share the ZIP folders, but they are too large, if anyone cares to have a look.

For now, I will just delete them from the support folder.

Kind regards


I don’t know whether the name format is the cause of your problems, but…

This is a bit like components: the material name is embedded in the skm file contents, not just in the file name. Changing the file name alone will not change the name by which SketchUp sees the material.

Yeah, I did wonder that after I tried it. I was all hopeful for a few minutes and then brought back down to earth :wink:

Oh well, luckily I don’t have much use for ‘Weave’ and ‘Fabric’ in my work, at the moment, so I’ll just delete them.

Many thanks


did contact Rich at SCF to let him know?

it is an internal naming issue, the only way I found to fix the other set was to remake them…


Ah, that’s a good idea.

So next dumb question: SCF?


SketchUcation Community Forum


Thank you @john_drivenupthewall

Much appreciated.