Surely not per node !!
Ok for preferences, that’s what I thought. I’ll try that for the moment.
1 Like
Compositor has already its own weird resolution. But it is not enough I guess for shader nodes, and this resolution is calculated differently. I’ll see if there is a way to share the sam resolution between compositor and shader.
My vote is for a dedicated preview node. It’s nice to be able to place and scale the preview node as you want without affecting the actual nodetree. On the other hand it’s weird to have a giant mix node or whatever just to be able to also scale it’s preview 
I vote for consistency with the Compositor previews.
2 Likes
I vote for both. That is, for a preview that is consistent with the compositor, and also a preview node.
In most cases, you do not need a large preview, or you can zoom in by simply scrolling the mouse wheel to see.
For the rare case, when someone needs a larger dedicated preview node, that can also exist.
And, still, the third option to show the preview in the N shelf only, is also valid.
1 Like
Seeing the complains about the node preview being too big on some nodes, I decided to make a small and very simple proposal.
Notes:
- Maybe have a maximum default size, that new nodes will never go over but can be scaled to up if desired. I think the size of the Mix node could work for that.
- Minimum size is the same as the absolute minimum width of any node.
Would also be nice to be able to see previews of collapsed nodes
1 Like
Is it me or do you all want to make the overlay more than just a quick inspection?
- Node uptime measurements make sense, but if you want something more, you need to do it in python.
- The plane preview image makes sense, but if you want to zoom in or change shape, just make a model with this material.
- Named of attributes can be displayed above node, but if you want them all, look in the spreadsheet.
No need to inflate overlay functionality that is not originally intended to be so widely used.
13 Likes
Agreed; I’m starting to get confused on the feedback as to what sort of expansion of the idea is being suggested…
It needs to be like a 256 pixel square on top of the node (I’m sort of guessing at the size, but you get the idea), and that’s about it.
Not an additional preview node, not something in the N panel, not some background feature like the compositor uses. It needs to be kept in mind that if users need some full-blown result preview, it’s right there in the 3D view… We already have that feature.
8 Likes
Not to mention, the direction being taken has already been decided- weeks ago. This discussion is all entirely hypothetical and entirely pointless at this point
4 Likes
Yeah node computation timings shouldn’t be part of this, though I definitely see their use for optimising shaders.
Some feedback after seeing the video! Loved the update from here: GSoC 2023: Shader editor node preview - Weekly Reports - #10 by Kdaf
- So nice! Glad it can be toggled per node on demand, and the overlays toggle also is handy.
- I hope some of the render previews can be rendered flat XY instead of on sphere, as sometimes you would need to see tiling or coordinates and patterns this way.
- To get flat 2D previews, would also be handy to be a toggle on the specific node.
2 Likes
Agreed, great vid preview!
Also hoping for 2D flat previews, yes. Spheres are great for some things, not great for other things.
1 Like
Looks really great! I haven’t found this in the details about the task, but: will it be possible to toggle many node previews at the same time? Something like selecting several nodes and Alt+LMB on one toggle to open/close all of the selected nodes’ previews.
1 Like
Looks really cool ! not too sure that the previews should scale when the node is widened, however. It looks logical and consistent from a visual standpoint, but node width is something you change because you need to make the contents fit (parameters, values…), whereas scaling up the preview is something you’d want for it to appear more prominently, perhaps because that’s a particularly important step in the nodetree. Those are two completely different operations and I don’t think one should be a side-effect of the other.
4 Likes
Thank you so much for those comments, I really appreciate it.
First of all, choosing between 2d and 3d is not in the todolist, but it is already possible to use the same preview as the material previews. I just forget to change this preview in the panel, but it is possible. I dont think I’ll add a new button for now, I’ll first have the patch merged, and then add this small addition.
Secondly, I agree that the UX is not optimal yet, but as I already said, I’ll mainly try to have something merged at first, and I’ll see those aspects later, as they will probably require more advanced thinkings with the UI team.
There is already a command in the (F3) search bar where you can enable/disable node preview for all selected nodes.
5 Likes
Ah, that’s good to know! Thank you!
One UI feedback I’ll leave is that if previews are disabled from overlays, those circle buttons that enable previews on nodes can be hidden too. Would make things cleaner (like it is now) if you don’t want previews
1 Like
Hiding a preview is a different matter than hiding interface elements; the “move” tool doesn’t disappear from the toolbar in blender, if the user hides all objects in the scene and therefore cannot move them. The animation workspace tab doesn’t disappear if the user has no animation at present.
A show/hide function should apply to all the previews, fine… but also remove the node interface button that shows/hides a preview? No. I might want to “hide all”, then click a single node to activate it’s preview.
1 Like
I think you misunderstand what overlays are in this case. Overlays aren’t hide all. They’re just turning off the feature from drawing all together. It doesn’t mean node previews that were shown before get hidden, no, once you turn on the overlay all the nodes that had previews enabled will have them, and those who didn’t wouldn’t. It’s just turning off temporarily.
Hide All/Show All is entirely different function that has nothing to do with overlays. And Gizmos especially are just entirely different things that have nothing to do with overlays. Hide All/Show All are operations that should have their shortcuts. Like Shift-Click on node preview button to solo it, Alt-Click to hide all/show all.
Hiding the button when overlays are turned off communicates with user that they’re turned off. If they’re shown user will be able to click on them and nothing will happen, which is not desirable. If clicking on buttons where able to turn on/off overlays that would defeat the whole point of previews being overlays, on which Colin worked so hard.
Why would we need a feature that disables everything entirely?
Perhaps I’m misunderstanding due to the nomenclature (what do you mean by “Overlays”? I see no overlays in the preview video). The user can show the node preview, or hide it. They can show all previews, or hide them. It sounds like the suggestion is another button or checkbox, that turns everything off completely… Effectively just disabling the feature?
If the user doesn’t want to see previews, just don’t click the show preview button on nodes…?