Something that just has come to my attention is that SketchUp, contrary to popular belief, actually does support having a texture positioning (aka UV mapping) set for a face that does not have any texture applied. This can be useful inside groups or components to make the texture positioning apply when painted from its outside (see image).
This is a quite obscure behavior though since applying the default material using the Paint Bucket Tool also purges the texture positioning. The trick to change the material while maintaining the texture positioning is to use the ruby API.
To achieve this do the following:
Position the texture as usual (I’m not covering that here)
Select all faces you want to apply the default material to
Open the ruby console (Window > Ruby Console) and run “Sketchup.active_model.selection.each { |e| e.material = nil if e.respond_to?(:material); e.back_material = nil if e.respond_to?(:back_material) }” (without quotes).
If these faces exist within a group or component, and you don’t paint them again using the paint Bucket Tool, the texture positioning should be maintained when painting the group/component as a whole.
I can’t understand a thing about that ruby language, but I used to paint faces with a placeholder textured material, then go to material manager and erase that material. If you don’t paint the faces directly again, you can use the bucket tool on the component and it works.
It’s basically the same approach, but rather than erasing the material as a mean to remove it from the face while keeping UV mapping, you use the API to remove the material from the face. Unlike paint Bucket Tool the API handles material and UV separately.
This was not so new to me, but it is indeed only little known. The previous version (now deleted) of the chair component tutorial was using a texture and replacing it.
Or the Entity Info panel (Paint Bucket replace material and resets UVs, Entity Info just replaces the material). There you can assign the default material (without deleting the original material), which keeps UV coordinates.
The major problem (and why I make little use of it) is that the Ruby API does not allow to get UV coordinates of untextured faces (even if they exist), but returns default UVs. That affects all exporters! If I make use of UV coordinates on untextured faces and export the model, the exported model will have messed-up texture positioning.
I’ve been using the Ruby console to get a rference from one selected object and apply it anotehr when I want to keep UVs. This is much simpler! I’ve always assumed it worked like Paint Bucket.
Yup, that’s the problem with this approach . It’d be nice though if support was added and it became official, not just a little hack.
This is an issue I’ve been pestering Tomasz (Thea4sketchup) about for years. He stated the same as you: until Trimble makes the hack official, he can’t support it in Thea, unfortunately, as it’s so handy.
JQL, Do you happen to know what would be holding Trimble back from making this hack a feature? Has it been mentioned in a different post or some other place I’ve missed?
I’m not sure whether I would call this trick a hack or its inconsistent implementation a bug.
UV coordinates are stored with a face independently from whether it has a textured material (removing a material does not entail deleting UVs). It’s rather a question why the API layer does an additional check for the presence of a textured material before it returns the UVs. This does not make sense, and creates another gap between what users can do in the UI and in Ruby. This gap causes exporting to be a “destructive” operation (which it is anyways), i.e. by exporting & reimporting, the model loses information.
I made several posts about this in the past. Either here or Sketchucation. I don’t know if they read them or not, I don’t know if they think it’s a too specific and niche feature.
I just know it holds tremendous potential and would be able to solve some of SketchUp shortcomings in material randomness on components.
These kind of almost there features really get into me. It’s been years of waiting for this seamingly simple support on the API, to happen.
Maybe someone at Trimble should be called upon to read this. I wouldn’t know who though.
It would be nice being able to read those UVs from Ruby/C SDK. Unfortunately both give the default UV mapping. I have reported it at least twice in the past, but no action/improvement so far.
That would be a cool workaround. Don’t forget that you probably shouldn’t apply that temporary material directly to the faces, you should probably assign it to the group/component instead.
At least that’s what you must do if you’re not using Ruby.
Oh! I triggers something I think I observed a very long time ago. Before my Trimble days… What I think is happening here is that when you have a positioned texture, the face has TextureCoordinate object applied to it. Normally that gets cleared by the UI when you apply a material with the Paint Bucket. In the case of the API, it appear to remove only the material reference, while leaving the TextureCoordiate information intact.
This is probably inadvertently behaviour. But I’d say it’s useful. In fact, would be nice to be able to define UV positions without a material via the API (I know that it’s trivial to use a temp texture and then remove it, but - would be nice to formalize it.)
Oh, it does? Hmm… that’s unexpected… I’d have to look closer at that.
Can one of you add a ticket in the issue tracker? Issues · SketchUp/api-issue-tracker · GitHub
(And the rest of you, vote it up )
The currently unintentional behaviour is a nice proof of concept that would be good to have formally supported.
. It’d be nice though if support was added and it became official, not just a little hack.
)