Well this is turning into discussion what Overlays are, but very well. Essentially Overlays in Blender are things in the interface that are drawn on top of objects(or nodes, image, keyframes, based on editor). For example annotations are overlays, as are timings on top of geometry nodes, they’re drawn on top of the editor. From overlays tab you can turn off visibility of those things, or just visibility of every type of overlay (Shift+Alt+Z).
Colin converted node previews to overlays, meaning user now has choice to decide whether they’re drawn or not. You can click Shift+Alt+Z and disable them all, again and they’ll come back. Point of overlays is that it just quickly disables something, instead of hiding.
So turning off overlays doesn’t turn off node previews on any node, it just doesn’t show to you. Blender remembers which nodes have previews on and which ones have off, they’re just not shown to you temporarily. That is very useful when you want to inspect something and overlays are getting in your way.
Yes, ok. I understood that annotations or other types of things (safe area markings, etc) are overlays, but wasn’t getting that preview squares were also considered an overlay. (Which confuses discussion, but it’s been cleared up now.)
The tooltip should probably include the word “material previews” or something of that nature, to be sure the user doesn’t think to themselves “Well, this square is not a colored or dashed wire.” Or perhaps remove the mention of colored wires, and use a more generic description (ie, editor extras, etc).
I agree. By the way, this makes me wonder how are dashed wires or wire colors overlays ? Does anyone ever turn these off ? seems to me they’re foundational to a well-functioning node editor. Previews on the other hand, are good candidates for overlays. Apologies for the slight off topic
I do. However I almost exclusively use the shader node editor, so wire colours aren’t too important and dashed lines are non-existent in that editor to my knowledge.
Hey, little updates from my side.
I know some people here like to have demos to better see the progresses.
So, lil video demonstrating one of the tasks of this week: refresh only the previews of the nodes most likely to have changed.
You have probably seen that the previews are flickering, this a limitation of the current implementation, it’s coming from the render side, and it is in the TODO list.
Have downloaded the build (PR110065), and noted some things:
I was concerned the preview speed might be an issue, and it is. The order of screen updates appears to be Viewport → Shader Properties Panel → Node Editor. Meaning, there’s notable lag within the node editor when you change a parameter, as it’s waiting for everything else to update.
Having the Node preview use the actual assigned preview as the shader property is not pleasant. If I want all the previews to be 2D squares (and I do), I have to change the preview style in the shader to 2D. In a scene with 50+ materials, I don’t look forward to to having to change 50 preview styles. There should be a global setting of some sort, that assigns a singular preview style to the node editor regardless of what the shader property preview is.
The transparent background of the previews is not “locked” to the preview window. It’s visually odd/distracting to see the checkerboard not “travel” with a node, but “reveal behind it”.
Image map preview crops are not correct; I cannot quite tell what cropping is being used. It’s not a full square, nor is it the XY ratio of the image file itself. (see image)
I don’t love the preview square size being determined by the width of the node. (see image) I’d prefer all the squares be the same size. (I’m aware this would make the image map previews smaller.) I can live with it either way, but decided to mention it.
Well, I’ll try to give an answer to those issues. I’ll talk about them with my mentor too.
The preview speed is not good I know, and this patch is a MVP, so I did not add optimisation. I have some optimisation tricks that are coming after this patch is landed. For the order of the area redrawing, it will not be possible to change that I guess (I’ll ask other devs for that, it would make sens to have the previews first). The lag is mainly happening with Eevee I guess because the shader compilation takes longer.
I currently have no better design than using the material scene used for that purpose. If you’re willing to propose something simple and clean, I might do that after this patch gets landed.
The transparency of the background does not seem too problematic I think, and I have another patch ready that will add the background for those nodes.
The mapping of the image seems correct to me. Actually the image is projected according to the UVs of the preview scene, and there is no real better way of doing that. If you were using a default plane with this material, you’d have the same result. I once thought about a setting “preview UV scaling X and Y”
The size of the preview will be fix in a future patch, with the size of the compositor previews too. That’s not too important for an MVP.
I’ll try as much as possible to fix most of those disturbing behaviours by the end of the summer. As far as I see you did not notice a real blocker for a MVP ?
Counterargument, if you are having to edit 50+ materials as you say, would changing the style really be the bottleneck here? Wouldn’t be just one extra edit for something you will be editing regardless?
@Kdaf How do the previews work with eevee? After compilation is there an extra cost for having the previews? And if I don’t have any nodes with previews is it the same cost as before the patch in terms of memory and speed?
list the nodes that needs to be re-previewed (none or all)
start a new render (building the materials, … according to the engine)
display the images from the renderresult
You already noticed I guess that the eevee material building can be quit long (in term of milliseconds), that’s what takes so much time when rendering the previews I guess(not sure).
If no nodes are previewed, it is absolutely the same as before. The difference of speed compared to the realtime preview of the 3D editor is that the 3D editor keeps everything in cache for the next redraw. It would probably not be possible to do that for the node previews.
The “50 materials” example could be reworded as “every material I’ve ever made, and every material I ever intend to make”.
It’s an extra button click in perpetuity, to not have a ball preview in the node editor. And extra clicks over that, if I don’t have the shader property already visible. Or having to open a secondary properties window, because I’ve locked the first to a different particular editor.
TLDR: UX is important, and when the feature is being initially coded - that appears to be the time to raise such concerns. Otherwise, one expects that “V1” of the feature will always remain “as is”, until Blender 7.0 when something else is entirely redone.
IE, “these concerns should have been raised pre-release, it’s too late to fix now. If you want to suggest a change, start a thread on RCS.” I’d like to avoid that.
We can probably make it prioritize the preview rendering of the active editor, at least for node and properties editors. The 3D viewport render happens in parallel and I think should remain like that.
In principle sliding parameters can be made fast. It may be possible to compile the material to render a bit slower but do faster updates, by not baking the socket values into the shader. In fact I thought it did this mostly already, but I vaguely remember some Metal related optimizations that may have affected this. Would need to be profiled where exactly the bottleneck is, which may also be platform dependent.
For the preview shape, I think we should have a Previews > “3D Shape” option in the node editor popover, that is off by default and in that case always shows the flat plane. And then when you turn it on, it uses the material setting for the preview shape.
Eevee is all I use, ever - so, definitely the one I’m more concerned with.
I don’t understand why UV mapping really needs to be involved? Perhaps I’m missing the obvious, but the actual UV result is already showing in the 3D view window.
For the preview, this would seem sufficient. (Also, have made the images display as would be preferred, which includes their embedded alpha channels… images with an alpha channel should always be displayed as such, without requiring an extra transparent node just to see that the image indeed has an alpha in the preview).
(Also, I don’t know what “MVP” means in this context.)
Since this project started there’s questions about how to display previews, and I still don’t get it why you would need anything besides flat plane? For final result you already have shader balls, but why would you need cloth or sphere or hair to preview images and textures? It would save you some time if it was just planes, which is I think what everybody will use anyway.
And for the speed, I don’t understand why Node Previews add-on is so much faster. You would expect it to be far slower since it’s an add-on, but it’s almost unnoticeable. This is good enough for MVP yes, but if speed of add-on is better than built-in feature I don’t think lot of people will be using built-in
