You’re right, the scaling will need to be thought carefully.
There are many things to consider here. Should the scale be adjustable per node ? I dont think so, but at what holder is it relevant to put this preview scale setting ?
It could be in the material settings, the object settings or even somewhere else.
Overall, the user is going to matter about the nodetree viewed in the area. So maybe the settings relative to the previews could be stored by areas, and thus add a page in the N panel.
It isn’t the best solution regarding the fact that multiple areas can display the same material, but it is better to have per area settings than having settings relative to objects, materials, nodegroups…
With that in mind, the different settings mentioned above about the preview scene (object shape, lighting…) could be modifiable per areas to have no redundant settings over the different previewed nodes.
I’ve tried to put the previews atop the nodes in the compositor, annnnd, it is not complicated to move it like this forever.
I’ll wait until Monday to talk to Brecht and Hans about the possibility to move all the previews inside this overlay.
Good point about the scale! I have a big set right now that’s a 5*5km island with a lagoon around, and a smaller one that’s just the mangrove and the shoreline. I’m making most water effects procedurally, so there’s a very large texture for the breaking waves (waves are as big as 30m long) and another one for the small wavelets near the shore. I would have to be able to preview both with a scale that makes sense… I suppose the smaller texture wouldn’t actually need any scale (assuming the preview shows 1m² by default) but for the big one, a scale of 1% would probably be ideal.
This is exactly what @Forester64 has said about the floating window ABOVE the node, this makes the most practical sense, preview window does not change the node layout, perfect.
Although one small thing, the window should be locked to a 1:1 size ratio, as pretty much everything computer wise is a ^2 multiplication, and textures and previews are always a 128x128, 256x256 etc.
If you want it square, adjust your node width
Preview for Node in the top are not “Correct” for a long time work… and isn’t correct for a “Standart” using by the industry… The preniew need to place inside the node… We need a clear space and clearly delimited… not floatted ! Floatted above the node isn’t correct ! i don’t like the idea “Floatted preview” Blender team will tell you same you see later. And this is for that in compositor and textures nodes preview are inside and not above the node.
With this technic you create a multiple problems exemple : wire of the node make it more complicated to trace it…Because is not clearly definied.
But as others have stated putting the preview inside the nodes has its drawbacks as well. Expanding and collapsing the preview moves the inputs and outputs around which makes it cumbersome to manage the overall layout.
UV coordinates are in a ^2 (square) arrangement as in a square, textures are also in that said square, doing anything shader wise is within that said square, anything else than that would be inconsistency weather you or I like it or not, that is a technical thing.
But if you still think strongly that that is wrong then suggest for a global 1x1 lock/unlock
It seems that the aspect ratio and coordinate transformations are what gives rise to a special preview node…
While it is true from a technical standpoint that preview inside the node is technicly correct, with the best example shown here:
(for the purpose of explanation)
You also have to look at the least practical example for the inside window
(imagine if this node was twice as tall, like the unified shader node)
And here it just looks a bit odd, of course this could be personal preference and of course it might be easier to follow the spagetti flow of what image leads to what other image and of course this would be a “Industrial Standard” but,
my question is this, should the industry standard be followed blindly or can we improve upon it by doing it a bit differently ?
This example are not correct and you can’t take it. the ratio of the preview isn’t square. and i have already said… in my past reply… is not an industry standard… resizing a node by conserving this proportion is fully integrable it’s called “Responsive” also integrated in the node is clearly better, simple and responsive too! See many shader in google… if somebody thinking is a good idea is already implemented but is not a good idea. Sorry…
And yes is needed to follow the industry standard for BASIC FEATURES LIKE THIS! Because is for performance and optimizing work…yes clearly! We need a clear interface. So that the whole node can retract… however the idea of leaving it on top can be a good idea if we only want the preview and not the content of the node
In any case, no matter how much you ask for this, you won’t get it, it’s not confrm with the blender pipeline… and that’s why for the design our dev must consult @brecht to be sure inform he is not free to do what he wants, this topic is a feedback … Not a request for addition or other! In our prototype it was decided that the knot would be like this… That’s it!
See again the implementation choosen …
And here : GSoC 2023: Shader editor node preview - Weekly Reports
Now if you have ideas put them here : https://rightclickselect.com/
You have not given any single reason for why this is supposedly “not correct”. Perhaps you’d like to take part in the discussion ?
Because is not organized, simple and fluid. And the idea are not followed the original ideas, this proposal is out of context clearly.
You know it’s rather difficult to understand you sometimes with your text formatting,
Preview should be square at all the times as it would not make sense otherwise unless its a “final composition” node or something that would have a bit different use than math/shader nodes.
And when you say it’s clearly better with previews in the node, is it objectively better or subjectively ?
Because if the size of the node is barely anything bigger than a 1x1 square, sure the preview looks good and all but when you have it in a giant shader with lots of options and settings and then you have the preview window up there on the top of the node, is it still better ?
no matter how much you ask for this, you won’t get it
Also what’s up with this, this is a feedback thread where we have a discussion, which is what i’m trying to have.
if you are so attached to use this thing use the add-on… and not the new system, here is a new system for blender not a re-usable add-on
now stop asked the same thing everytime you see in more dev news this summer for the preview…
Forgive my direct and straingforwarding approach, but in my opinion, all solutions in a thread I saw are ugly or cumbersome.
Why not use the Viewer node as we know it from Geometry nodes?
- users are used to it
- It’s in Geometry nodes, it’s in Compositor nodes, and it is logical to be in Shader nodes.
- The same hot-key as in Geometry nodes and Node wrangler: Ctrl-Shift-click
- same usual behaviour when clicking the eye icon
Because some users wants a single preview for each node, and some developers want to re-use the existing API afaik
viewer like that is a good and bad idea in the same time. Becaus eif you want preview systematicly you need add more and more and more nodes, and create more datablocks for there are created “Séparatly” isn’t optimal… But it’s good idea if he come for a “Big preview” instead the small preview inside the node .
The benefits for preview for “ALL NODES” is you can see quickly what’s the node do, without putting an extra nodes… More faster ! More optimal ! Simply !
Conclusion, is a good idea if is it an Extra nodes for see the texture more bigger.
Because we want to be able to preview more than one node at a time. How is this so hard to understand for people? Viewer node should exist in Shader Editor but for exact same purpose that Node Wrangler does right now. I don’t think most of the commenters here realize what exactly node previews are.