OPTION to keep materials external from model

[alz]

If I remember correctly, before version 6, SketchUp use to reference materials -- not include them with the model.

Now SU takes a copy of the material from the library and saves it with the model. If that material is ever updated, it has to be updated manually for each model that uses it (and of course communicated to everyone it's been updated).

[Alan Fraser]

Materials were always archived within a skp file. The thing that changed with V6 was that the skm files changed from representing an entire library of externally referenced images to representing a single material with a bundled image file inside.

[alz]

So to paraphrase -- before V6, each SU file would have any number of Materials pointing to external textures. Whereas now, each SU file contains one (base?) Material which includes the external textures?

[Gaieus]

No, SU files always contained the materials not just pointed to them. Good example: if you uploaded a SU5 model to the warehouse, it kept the materials otherwise it would have been a "clay" model with just the default colours.

The difference now is that in the materials folder there are not just plain jpg files but skm files (they are actually disguised zip files - you can rename them and see what's inside). Still SU works the same way; the skippies contain the materials themselves. That's how we can share models without needing to include the materials themselves. And it was alike in earlier SU versions - although I started to use SU with v5, Alan knows even earlier versions as well.

What SU uses to convert its models to GE models works the opposite way. Since xml files (which are basically simple text files) cannot contain textures, they need those textures to be added. Rename an kmz file to zip (yes, again), and if there were textures in the skp model it was exported from, you'll find them in a subfolder there.

[alz]

Ah... thanks for the clarification, Gaieus!

I remember discovering SKMs and KMZs were just zip files – all things should be packaged as such when possible!

So to paraphrase(again) --

(Materials = the shader wrapper for the texture)
(Textures = the raw jpg file)

In SU 5, the models contain the materials used. The browser points to Textures, requiring you to create a Material every time you use it.

In SU 6, the models contain the materials used. The browser points to pre-made Materials.

Maybe my initial confusion rested with the Material Browser. If a Texture changes, that change doesn’t update the Material SKM files.

In trying to verify this, I hit a brick wall... is something wonky with my SU or am I realizing you can’t EDIT a Material from the Browser, unless it’s been applied to a model in the scene? If that’s the case, you’re actually editing a copy of the original Material – meaning you never touch the original SKM material (unless of course you apply to a model, edit it, then save it back out).

To reiterate this thread for sanity – a feature I’d love to have is the ability to not save Materials with Models. Have the model point to external SKM files. In addition (if the above paragraph is true), have Materials point to external Textures, instead of sandwiching them inside the SKM file.

[Alan Fraser]

Personally, I'd hate that. It would mean a skp file behaving like a 3ds or obj. You'd never be able to share a model without zipping it up first with all its textures and some kind of skm that now behaved just like a mtl file, in order to reference them...and that before you even start on the problems involved with maintaining the correct paths to those textures to get them to load at all.

At present, if you need to change a custom material all you need to do is send a replacement jpg then go to Edit on the In Model Materials palette and navigate to the new image file. It will change all instances of the now defunct material globally.

[alz]

I agree with you on a small scale or from a community perspective. This option would greatly speed up game level production, though. With multiple people working on one large level, it takes a lot of time to step through all the objects and manually update them (or at the very least, stop by everyone's desk and ask them what/if they changed anything from the day before).

It's definitely a low-level difference, having an option to externalize internal elements. I could maybe see a script or external app. that could compare/check SU against external elements, but I suspect that parsing process would get bogged down after a hundred or so files.