Create a unity style node ? is the best deal the user need the both side connection…
Vertically :
Horizontaly :
SEE GOOGLE MY IMAGE WAS DELETED BY A MODO… (Unity shader nodes preview)
But horizontally are not ok with the default pipeline of blender… you see the reuslt final are Verticaly.
And the idea of a “on hover” preview ? a bit like geometry node output hover behavior 
(Thinking out loud)
how’bout preview below? no shift
Looking at all these options above:
We already have a normal display of node socket values in tooltips, in which image could be displayed. And you don’t need nodes…
I regret not remembering this a month earlier.
Benefits of previews floating on the top of nodes:
I don’t think it’s worth reinventing the wheel in this case 
They should be square because most textures are square and their width / size should be similar to the mix node. It’s probably most common node and one what need preview of the operation. If they are too big by default then they will be too cumbersome to be left on.
I think “on hover” may be unnecessarily awkward? The one benefit it brings over a permanent preview is to move out of the way until you need it. That’s nice but I would personally prefer a toggle, it’s a more direct kind of interaction. I would say nodetrees are flexible enough to accomodate permanent previews too. There’s also the downside of not having multiple previews visible at the same time. Perhaps that’s a dealbreaker even…
Drawing the preview below the node sockets will still have it move around when the sockets are connected/disconnected/hidden, etc. For that reason I think it’s still inferior to “previews above”
Completly agree. this image below is the potential final result.Square.Top of nodes. Simply. Only the system for activate or desactivate the preview need a “Real discussion”
And btw @Kdaf are already submit a prototype for the node :
But now you can dev a new “Material preview node” with a custom shape object preview like this one
I try to make a news mockup with all ideas… humm i post in few hours stay tuned.
The last sentence sounds to me as describing what the node instance hash system does?
It stores the previews in a hash, with a unique key for each instance of a node taking into account group nodes. The hash is stored in the top level bNodeTree that is embedded in the Material datablock. And then at draw time it does a lookup in that hash.
I’m not sure how what you have in mind would be different, is there some new code that should be used instead that you can point to? Or am I misunderstanding the way you expect this to work?
ok so this is the mockup i can purpose from all ideas.
He have a texture modes and a material modes with object preview, and the “Live render” (For material) from the actual render-engine selected.
I just quickly glanced over this thread so forgive me if this was addressed already but how will the “scale-problem” be solved?
Most other apps that have such a preview feature are pixel-based. Therefore it’s straightforward to implement a preview if the base-texture size is known. In Blender that is not the case.
So how would this work? Let’s say we consider few usecases:
Would the preview only work for one artist?
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.
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.
Eeek, no
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 ?
