A Tip For Optimizing Colorless Textures

General Forums Blender and CG Discussions
1

Textures have always been relevant, but with there being a PBR craze in the whole industry at them moment colorless textures are becoming more and more relevant
I mean you got your

Rough/Gloss
Metal/Spec
Displacement
Bump

These are all textures which you’ll never use any color on.

Some texturing tools/resources recognize this,
Tools like

Substance painter automatically set your texture to a single channel image

Websites like Poliigon, also host textures which have been optimized for this too

However sometimes, like with the case of Megascans, it just doesn’t do it

Resulting in a higher render time and more memory being used overall

So I’ll just explain how to optimize them.

In Games

It can help reduce loading times to go the extra mile and combining 3 textures into one

Since it only has to load one texture and split the textures channels into the desired texture instead of loading 3 separate textures
https://blenderartists.org/forum/attachment.php?attachmentid=479425&d=1491553879&thumb=1

I also like doing this for the sake of not having so many damn texture nodes in the node editor in blender. :confused:

Hell, in some engines like Unity 3D, this is the only way you get to change the smoothness value.

In Every Other Area In CG

It’s faster,more memory efficient and usable to just convert to greyscale and save the image in your favorite image editor
as proven in the replies in the thread below

2

i care. my laptop struggles quite a bit when i try to use pbr materials

3

What would be cool would be a script to do this automatically, kind of like Gaffers HDRI->JPEG conversion.

4

Why not just save each image individually as greyscale image?
And set them to non-color data. (Something that should be done always for images with no color information like these).

AFAIK
8 bit Grayscale=1 byte per pixel

24bit RGB(8bit x 3 cahnnels) =3 byte per pixel.
[TABLE=“class: wtable”]

[/TABLE]
Sorry I don’t understand the benefits.

5

Means that when you render,
cycles only has to load in one texture.

6

I’ll do a test to see whether it actually does save memory

7

Cycles has supported single-channel textures for a while now. Make sure to save your image as single-channel.

As far as Cycles is concerned, it’s either one byte (single channel) or four bytes (RGBA).

8

It will save memory, but you need a scene where there are a lot of textures. In a simple scene it wont make too much difference. By the way, this method is mostly for games. It is better to use single channel textures for renders or cgi, easier to edit and manage.

If you want to save even more memory you can use vertex paint to control shading info or material blending…

9

Tests are in

Megascans out of the box textures

Rendertime : 38 Seconds
Peak Memory : 203.80 MB
Avg Memory : 179.87 MB

Screenshot (21).png1366×768 244 KB

My optimization trick

Rendertime : 22 Seconds
Peak Memory : 171.28 MB
Avg Memory : 147.35 MB

Screenshot (20).png1366×768 229 KB

I’ll redo the first one with the textures set to grayscale, just to make sure
(obviously it’ll be neck and neck with the “optimized” version because well, 1 + 1 + 1 is still 3)

10

@fdfxd

Are you’re rendering on CPU? (As I can see In your screen shots?)

Did you ever had a limitation of textures on RAM?

I though you were trying to limit the size on GPU Mem.

11

It’s a good trick, once you get a PBR texture library where a single file can handle 3 aspects of a material.
Another usage might be grouping 3 textures in one by type: 3 scratches patterns, 3 grunges, 3 fingerprints etc…

12

It turns out that having all the textures separate with grayscale is exactly the same (if not slightly better) than my method

However I tested using a CPU
results may vary

In complicated scenes with loads up textures, this method would probably defeat the grayscale method
as loading one texture is still faster than loading 3(I think)

I still think this is useful for us game industry people(seriously save the load times.)

Attachments

Screenshot (23).jpg1366×768 249 KB

13

memory and file size ? so its quicker and faster ? :wink:

unfortunately its not. As sunburn said:
A greyscale texture should only have one channel which holds (most commonly) 8bit per pixel.
If you somehow manage to use or convert a greyscale to RGB it would use up more memory.
That would be bad. :slight_smile:

So we are talking 1x R8G8B8 or 3x R8

The only minor upside would be to have less drawcalls (really true ?)
But I guess those are not really important for renderings.

True, to some degree !

But only if you know how to do it then.
The block compression in RGB textures is quite harsh when treated as colordata.
This means - when used naively - you could end up with a 1024x1024 diffuse texture that looks like a
256x256 in every channel seperately, thanks to 4x4 Block Compression.

+1

My personal protip: Dont do it, its not worth your time !

Edit: Damn fdfxd, you are fast ! :slight_smile:

14

I’m kind of confused both by the title and the posts here.

I thought we were talking about Cycles rendering and memory limits.
At first I though we were talking about GPU memory limitations which is a real problem that you face everyday with heavy (unoptimized) scenes.
Then I realized it was about Cycles CPU rendering and RAM loading. Is that true?

Or we’re talking about optimization in textures loading in a game engine?
Specifically blender game engine or any engine?

Is loading e.g a 4MB file in RAM or VRAM noticeably faster than loading 4x1MB files?
If any of you more technical guys has an info about this I would like to know.

I feel that is more time consuming to combine 3 images in one single image than convert a bunch of images to greyscale. (It can be fully automated)

15

Somewhat related, here is an addon to split images to new single channel images from blender.
blender_image_channel_splitter

16

Yes, I might have carried the topic a bit away with my texture compression thing. I cant help it…

To make it clear and simple again:
Dont do what fdfxd originally suggested. It has no noticeable effect.

17

I’ll edit the thread to make it relevant with my recent discoveries.

18

If using jpg format 3 channel still wins: it’s three files in one which is handy for 1jpeg-1material workflow, and also it is lighter on the harddisk than three separate grayscale jpg

19

Hum, even with best quality jpeg you may have changes in the RGB channels, I’ve tried this to export ID mask in separate RGB channels , and with jpeg you get some artefacts comming from other channels ( some Red infos getting into the Blue channel)

Maybe you should consider using PNG when tiny details matters :slight_smile:

I personnally prefer this approach rather than having a lot of file , but I guess it’s a matter of taste…

20

Building three material maps into one texture may indeed work as one would expect, the downside is that you have to make a new texture whenever you want a different combination of maps (so it can eventually lead to bloat in your texture folders).

More likely, major speedups in image texture rendering will come if Cycles finally gets support for mipmaps (though done in a higher quality fashion than what’s used for games). Arnold does this through .tex file generation and people get a massive boost in rendering as a result.