Blender obsessed on rendering tiny 16x16px material previews


#1

Hi, I am trying my material library in Cycles and Eevee now called materialiq; https://polygoniq.com/materialiq/features

And the biggest problem so far is that Blender is trying to render all the material previews whenever I click the little material icon to change the material on the active object.

I imagine Blender loads two 4k textures per material, renders a 16x16 px sphere and then goes onto the next one. Which takes a while because it’s 200 materials…

The previews are so small they are not that useful anyway. But this makes Blender unusable every time I want to change the material and it slows down to a complete crawl.

Or maybe there could be a button called “Render all material previews”.

Possibly this could easily use CPU threads 1 thread per material and scale down textures by itself (since the preview is so small anyway) and be done on the background slowly over time.


#2

@brecht or @billrey or @Hypersomniac Could you take a look into this? It’s making scenes with lots of materials hard to edit as Blender slows to a complete crawl when you click on the material button. It also often makes Blender eventually crash if you decide to have the viewport rendered with Eevee at that point = out of vRAM.

Personally these previews could be improved as right now they are not that useful because they are very small. Maybe always lowering texture size to 512 and doing it in the background 1 material = 1 thread + saving them into the Blender file? (I think that happens).

30%20PM


#3

In most cases the material preview will already exist, generated while the user is editing the material. Is your addon generating many materials through code somehow, which then do not have previews yet? Or is there another way you are ending up with many materials without previews?

Lowering texture size would not help much, Blender would still need to load the full resolution image before scaling it down.

Generating material previews could be restricted more perhaps, only when the material is edited by users and not whenever the UI code ask to display them. But would still be good to understand how you end up in a situation with so many materials without previews.


#4

I have a 200 material library and often append them or create an entirely new file. It’s from 2.79 so I suppose material previews were lost.

Also I am not sure if this is correct but seems like previews use the actual environment I set up so every time I change the world it forces all previews to rebuild. Here I think it would be best to just have a simple scene set up for consistency and not really care about what World is being used.

In general material previews should be utilized more and in bigger resolutions and different menus than that drop down of 10 materials at once.

Material previews are great but rendering should happen in the background without user realizing and not freeze Blender. I know Max has exactly the same problem and there it would only be enough to limit preview rendering threads to half let’s say. Although there is a button that pauses preview rendering in Max.

I think the same issue goes for image previews. Oftentimes whenever I have Image Editor open and I just open one single image through finding for it it forces previews out of all images I somehow came upon during that operation.

Are the material previews stored in the material datablock itself? So if you appen or Ctrl+C and Ctrl+V from a different scene they get preserved?

Here you can see how a material library looks with Corona in Max.
The button at the bottom left is for enabling / disabling rendering of previews.
Click “Open image in new tab” to see full resolution


#5

I have actually noticed this problem too when using Eevee. If you open up a file with lots of materials and open the material ID selector, your machine may crawl to a halt because the GPU is fully occupied rendering material previews using Eevee.

For Cycles this doesn’t seem to be an issue because I presume the previews are being generated using the CPU.

I don’t know what the solution is though.


#6

Omg. Yes. Please give us at least the option to disable those thumbnails. I had a project with some 32k textures. Maybe you can imagine the pain I had to go through with those useless thumbnails I had to wait for everytime I assign or change shader. In total, probably hours of my time wasted that way.


#7

I’ve noticed this too.

If new previews are being rendered every time a drop down list is displayed that seems a little wasteful. This should be cachable and only need re rendering after the material is modified. That seems to be what brecht said happens but it doesn’t seem to be the case.


#8

The material previews are cached, and only marked as needing to be re-rerendered when the material is changed. That re-rerendering happens the first time the preview is displayed.

There was a bug in an older Blender version where undo would clear the previews, but this should be fixed in the latest official release and daily builds.

If there are still cases where material previews are seemingly not cached properly, we need steps to reproduce that. The design is fairly weak, but with an asset manager coming we need previews even more.

There is a preview that can take into account the environment, but most do not. Changing the world does not force any previews to rebuild besides the world itself, if it happens that’s a bug I don’t know how to reproduce.

Yes, they are on the datablock itself and preserved on copy/paste.


#9

I think the main problem is I have a 200 material library taken from 2.79.

Every time I type to search through them a lot of un-rendered previews pop up in the meanwhile as I type which were there from Cycles from 2.79. This makes Blender freeze to 0.1 fps for a while and focus gets lost easily.

Gradually the preview cache is being filled up but this will be a very common occurrence in the coming months once Blender is released.

Bazillion bytes of 2.79 Blend scenes with massive amount of textures to load.

There are 2 options:

  • have a button to render all previews at once taking a LONG time to finish on big files but once finished everything is OK

  • have the preview render use lower GPU priority if that is possible as something should definitely be done to make Blender GUI usable while it’s happening


#10

Regarding improving the previews maybe a completely separate data-set could be created next to the raw data used for rendering. This data-set could be globally stored in the Blender app folder to be able to reuse it outside of the currently opened .blend file. Which is what needs to be done for proper Asset Manager anyway.

So if you load the same texture name or exactly the same byte size - as textures could’ve changed name - a lookup is performed to see if the preview already exists. Ideally Blender should have previews of all images in root folders opened by textures in any .blend files ever opened. This could be helpful because lots and lots and lots of images are reused constantly.

This cache definitely needs some restrictions though but Adobe Bridge caches often take 3 to 5 GB in professional studios and people are completely OK with that.

So the preview of these textures is used to render the preview of the material.

At 16x16 px you would not really know the difference anyway - it only helps with general color of the materials.

Honestly though I would prefer the material previews to be at least as big as while browsing through textures as seen above.


#11

Once more this is a problem. I had a class showing of the new Blender and was so afraid to change materials, it was a bit awkward ^^ and when I did I had to explain what happened and that it’s not the fault of Blender it’s just that it renders these tiny images. Not a good impression people had but hopefully they understood.

If Cycles is better at rendering the previews wouldn’t it be possible to use 1 thread for 1 preview and do it all through Cycles which seems to be better at not hijacking the computer anyway? Cycles is surely reaching the same efficiency as Eevee with such a simple scene. I reckon it takes only hundreds of miliseconds to render any material on even the slowest of CPUs. I hope it doesn’t render the sample set up in render settings but some low number like 10 or 20.

Also so important: the previews could be bigger! 16x16 px is really not enough to see anything else than color and maybe how reflective the surface is. I wouldn’t really be against having options to have 32x32, 64x64, 128x128 or even massive 256x256 previews.

I also found out that Color Management settings are being taken into account and I don’t think that should happen as the preview scene and maybe HDR is always the same coming from Blender itself.

There are many scenes where you need to have Exposure 4 because you are in the dark but then the material preview gets pure white and there are scenes where there is so much light you need -3 exposure and then the previews are simply just black spheres.

See here: