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.
@brecht or @billrey or @fclem 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).
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.
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
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.
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.
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.
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.
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
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.
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.
Yes indeed, it does seem as if Cycles is a able to render the material previews in the background better without hogging the main GPU and causing slowdowns.
We could maybe force the mini-previews to always render with Cycles, even if you use Eevee, although there are some material discrepancies which might make this not a 100% perfect solution.
There is a cool workaround though. Everytime you change a material you can save the .blend scene, close Blender and open it up again. It takes just a minute so it’s better than waiting tens of minutes for the previews to rerender.
Also problematic is that even if you let the previews render the textures are not unloaded from memory so that it just grows and grows.
It might not be 100% perfect solution but honestly waiting tens of minutes for a couple of 16x16 px images is also not very 100% perfect:) I experience this daily and lost a couple of hours and considerable amount of flow potential. ^^
@brecht Pretty please I would welcome an option to turn this off if not easy to force Cycles to render the previews:). As I noted earlier, the previews in current resolution don’t serve much purpose. Also the fact that Color Managemet affects them is faulty I think, most of the time they are black when I have exterior scene or white when I have interior scene (more light in exterior = lower exposure, less light in interior = higher exposure).
@billrey@brecht@fclem Sorry for the shoutout, but even after the latest addition of new preview system this here is still a massive problem and I hope there are plans in works to solve it.
What we do for example in our material library is switch all texture paths to 2048 or 1024 or 512 resolutions and that effectively makes Blender throw away all material previews although that might not be the case. I am not sure what causes Blender to get rid of previews, maybe it’s because some NodeGroups are used in many materials but I seldomly change those.
But the bigger issue is how badly rendering previews is implemented in Eevee. It hogs 99% of the GPU making everything unresponsive and in scenes with many materials this absolute crawl can go on for a couple of minutes eventually resulting in unavoidable Blender crash (given there are enough materials).
I guess it’s very much against the goal to reduce buttons but if there was an option (in User Prefs) to turns rendering those freaking tiny 16x16 px previews that are so small they are virtually useless I would turn it off in an instant.
My Blender crashed 2 times in a row right now because when I click to change material - and I know perfectly well which one without the previews - it loads all the textures one by one gradually filling up my vRam, then Windows goes black, most applications like Chrome, Photoshop, VLC and also Blender crash and then gradually everything starts responding again.
I don’t know too much about programming but I know that this is definitely not helpful behavior. Blender is essentially hogging performance of my computer for unwanted reasons. I don’t want those previews if they cost me so much focus and time.
Sincerely Blender 2.8 is awesome except for this. This is simply just poor implementation at the moment and it’s a shame because everything else works so well, hell I even fit three hundred 2048x2048 textures into vRam and it loaded in about 2-4 minutes and worked flawlessly. While rendering those previews takes ages, freezes the computer and eventually crashes Blender.
Here is a short video showcasing how it usually pans out. It has 2 minutes but Blender is frozen 95% of the time so you can just click through it and watch the lower right corner how GB are rising.
I think we’ll probably disable these small material preview icons for Eevee, at least until they are not as bad for performance. We can keep them for Cycles I think, but should check it uses the CPU only then.
