I have been enjoying having all of my texture maps be a part of skms. This, however, has lead to some rapid file bloat. The “material resizer” plugin from SU team has been helpful in the past to reduce some of that bloat, but I don’t think it resizes the linked normal, roughness, ao, metalness images along with the albedo. Can anyone from the team:
A: Confirm that it does/does not reduce the size of the rest of maps in a material?
B: Make that part of the plugin if it does not currently?
Only the ‘albedo’ image gets resized.
Material Resizer seems to have not been updated in five years. I’m not even sure if the creator of the extension still works at SketchUp!
But I will ask, and see if it could be updated to resize all parts of PBR materials.
In the meantime, you may need to use smaller texture maps. Or, another option is to make the resized material be unique, and have the AI generate the extra maps for the smaller image. Probable won’t be as good as the dedicated maps, but they all would be at the smaller size.
Thanks Colin,
Your workaround (or even setting up photoshop automations to batch all of my materials/maps) could definitely be a thing, TBH, it would probably cost way too much in time alone for me to give it a go, but if things become unstable without doing it, might have to make the time investment either way.
Also, thank you for asking around to see if it could be updated, even if it doesn’t happen, it’s pretty cool knowing that you guys are out there listening.
Question: Are the PBR maps best if they are the same size and aspect ratio to the albedo texture?
It’s possible that you might have different map sizes/ratios than your albedo, like say if you wanted a fairly plain albedo, but wanted to add a displacement map that added unique texture to the render, could be a thing (some engines allow for both, and will let you scale other maps differently than albedo), but for dedicated set of maps, yes, all same is ideal.
I asked about this in a meeting today. Still didn’t figure out who at SketchUp created the extension. I logged a bug report asking for Material Resizer to be able to resize all of the maps in a selected material. The report is SKOR-20939 in our system.
Thanks for continuing to chase this down Colin. Excited to see how it goes.
@colin if you track down someone to update material resized, I think it would be valuable to add a “pixel density” column, calculated as the total pixels in the image divided by the tile size of the material. I use this in one of my unpublished extensions and find it very useful for detecting materials that despite reasonable pixel counts are grossly over-detailed for the model area they cover. I’ve seen 512 x 512 images tiled onto a square mm where they just show as a monocolor blur. For these, editing the tile size is a better fix than rescaling the image.
Are you indirectly talking about DPI? Normally a 1024x1024 image is that size no matter what the DPI, but a 72 DPI image that is 1”x1” will be 1/8th the memory of a 300 DPI 1”x1” image.
Material resizer changes the resolution of the materials not its size, if all the other maps are not changed that won’t affect how it looks the material anyways on the realistic textures style.
To be completely clear on what I am talking about, a SketchUp material has both a texture image and a specification of the size tile (in model units) that image is to be mapped onto in the model. If you apply a material with a 1" x 1" tile size onto a 10" x 10" face, the tile will be repeated 100 times to fill the face. If the texture image is 512 x 512, that will correspond to 51.2 dpi in model units, not necessarily in display pixels. You won’t even be able to see the material’s pixels unless you zoom in quite close, probably so that 1" in model space is several inches on your display. So, such a material is wasting the image detail. I have found materials in real models posted on this forum with pixels to area ratios in the millions, even when the images themselves are not unreasonably large. One especially bad case is when a single-color image is used as texture instead of a color.
Yes, you can stretch the material after it is applied to a face by dragging the pins in the editor, but that begs the question of why you didn’t create the material with a more appropriate tile size in the first place. It also can cause a variable ratio of texture pixels to model dimensions if you do the same stretching of the material on different sized faces. If it has no fixed size, that raises the question of what the image is supposed to represent.
This is a different concept than the amount of memory used by the material. That is determined purely by the pixel count of the image, not by how the material is used in the model. It could conceivably be appropriate to apply a 2048 x 2048 texture to a large surface, e.g. to avoid needing a massive amount of geometry for cosmetic details.
The Goldilocks extension calculates the ratio of texture image pixels to display pixels for the current view, a related but not quite equivalent idea. That calculation is different for every view, whereas what I propose is a fixed number.
at first, like Colin, I wasn’t sure, but I get your point.
having a massive material is not just having a 4000px image. it’s having it applied in a way that in sketchup it’s a 10cm tile.
on the other hand, if you’re using a 4000px image to tile 15m, it’s big, but it’s coherent.
Glad you mentioned Goldilocks. I will check whether @AdamB is handling PBR materials ok.
I have looked at the code and the extension currently clears the image page & origin metadata using the “+repage” parameter (to ImageMagick’s convert utility) then after reassigning the newly resized image to the material’s texture, it resets the tile size to what it was before the resizing (which BTW, is in inches as it’s an API call. It will however display in model units in the GUI.)
It looks like some of the new PBR materials like the plywood have 1m x 1m tile default. Many of the old materials were 1 foot square.
Currently the extension does not (but could) change the image’s units or pixel density (which is per the image units.)
Using the term “pixel density” will lead to confusion as this is already used.
Perhaps we can call it “tile density” ?
But it would affect the file size here. If the albedo map gets reduced in file size (by lowering resolution). If my sketchup file holds all of the materials, including all maps, and I reduce the file size of the albedo map to some managable balance between appropriate visualization and weight of SU file, that material would still have upwards of 5 image files for the maps which are likely adding significant weight to the file, and using material resizer ultimately will not give the expected benefit.