Why are there different Texture Image Paths?

Hi All,

This is on a Mac so would be interested to hear if Windows users experience anything similar?

I have a Sketchup Model where the materials with texture images seem to fall into 4 categories:

1. textures with temporary paths that reference a temporary file on ANOTHER machine:

/var/folders/bn/_z3j64l11lb352yh_mz1b34w0000gn/T/com.sketchup.SketchUp.2018.macbookpro/metal.jpg

2. textures with temporary paths that reference a temporary file on THIS machine:

/var/folders/3s/g_n2y1415fqdlk41k1xp86_h0000gn/T/com.sketchup.SketchUp.2018.imac05/metal.jpg

3. textures with paths to the local texture library on ANOTHER machine:

/Users/macbookpro/Dropbox/support/_textures/metal/metal.jpg

4. textures with paths to the local texture library on THIS machine:

/Users/imac05/Dropbox/support/_textures/metal/metal.jpg

So…

A. what the heck is going on here?

B. As you can see I’m using Dropbox to share texture libraries. Any recommended protocols to NOT make textures machine specific?

C. The REAL reason I ask is that I wanted to simply print all the texture image thumbnails to a custom HtmlDialog. Is there a way to bypass all the path shenanigans and access the thumbnails directly? Especially because getting the texture image file does not account for image rep colorize or any alpha adjustments.

When a texture path is from another machine … it only means that the material was created on another machine, and then you imported the SKM file (or a component with that material) into a model on this machine.

Naturally these paths are historical and of no real use anymore. Ie, you don’t need to access these image files directly because the material object or it’s SKM archive has the image file stored within it. (FYI, an .skm file is actually a zip archive containing XML files that describe the properties of the SketchUp material and have a resources subfolder that contains that image file for the texture. There may also be a thumbnail image for the texture within the archive.)

On the local machine, there are workflows that temporarily create image files in the TEMP folder. These paths also need to be considered historical.

Your mode of operation needs to be to get the filename of the texture for your own use to save thumbnails to a special local path for your own use.

def save_matl_thumbnail(
  matl_name,
  thumbs = File.join(__dir__,'thumbnails')
)
  unless File.directory?(thumbs)
    fail(IOError,"Directory \"#{thumbs}\" does not exist.",caller)
  end
  matl = model.materials[matl_name]
  if !matl
    fail(ArgumentError,"No such material \"#{matl_name}\".", caller)
  end
  texture_path = matl.texture.filename
  if texture_path.empty?
    texture_name = matl.name.gsub(' ','_')
  else
    texture_name = File.basename(texture_path, '.*')
  end
  thumb_path = File.join( thumbs,"#{texture_name}.png" )
  result = matl.write_thumbnail(thumb_path, 128)
end

def save_all_matl_thumbnails( path = nil )
  model = Sketchup.active_model
  model.materials.each do |matl|
    if path?
      save_matl_thumbnail(matl.name, path)
    else
      save_matl_thumbnail(matl.name)
    end
  end
end

ADD: It will up to your extension to maintain the “thumbnails” folder wherever you decide to keep it.

Wow that is surprising. Can’t I just access the thumbnails already stored within the SKM files? That would seem way more efficient (and transportable) than maintaining a thumbnail library.

I don’t think so. It’s just reality. Oh … you can check to see if the path leads to a valid image file, and save yourself some time … maybe… but the texture images may not be thumbnail size, so you’d still have work to do.

Perhaps you can. IF … if you have the SKM file on the local system.
If you don’t (ie, the material came from an imported component,) you’ll have to use Sketchup::Material#save_as to write out a SKM file first.

SKM files are zip files. To access them you need the zip library (which is a gem.)

Try …

Gem::install("rubyzip")

And before you ask, the answer to “Is there a published schema for the XML files internal to the SKM?” the answer is no. But they are not that complex.