I don’t think previews work for texture nodes. Using overlays would be inconsistent with compositing nodes, but consistent with geometry nodes.
I’m not sure how much any existing implementation would be reused for this though. I’d hope that the compositor implementation wouldn’t be used anyway-- the “node instance hash” system used for it doesn’t fit well with more recent node developments. Previews should be stored in a data structure that’s completely separate from bNodeTree and looked up at draw-time.
I think that having the preview above or under the node would be better, since currently the part with the links gets shifted downwards, which moves the wires around when the preview is toggled.
On the topic of that, unlike the compositing nodes, many shader nodes have multiple outputs, so a design of selecting which output to preview, and showing which output is currently being displayed will have to be made.
I’d like to quickly add, a nice feature to have could be toggling the color channels to be displayed in the preview of color/vector outputs.
It’s definitely not needed to preview every single node…
A similar approach to geometry node would be nice, a preview dedicated output
or passthrough like this
Are smart designs that do not interfere with the node styles.
Best to ask for user’s opinions on social media to reach the masses before taking design decisions like these
Came here to say this. Not only noodles getting shift buts its very annoying when you turn it on and your sliders suddenly pop down and you have to scroll. Geometry Nodes has perfect concept for it and i would like to see this concept use that, newer UI design rather than older, Compositor one. And then update Compositor to this method
“It’s definitely not needed to preview every single node…”
Sure it is, anyone who needs complete control over the node flow will need it, look at Substance designer, imagine making textures without previews on every node, you would lose sanity real quick.
However, that does not mean that it shouldn’t be flexible, it should cater to multiple workflows:
Preview window on all nodes,
Preview node on the graph if you have node preview turned off,
etc.
And it would make sense that the preview window is outside the node as if it were inside it would mess up the node flow of inputs and outputs.
Unless you make a visual design change about how node windows behave, it shouldn’t just be tucked on.
That addon on BlendMarket is the perfect example what’s efficient without disrupting the flow of the node itself.
Then all blender node magicians must be insane already
Note that a dedicated preview node could give us the possibility later to add preview settings.
Implementing preview settings on generic “for-every-nodes” designs would be more tedious , perhaps.
What do i mean by preview settings? For example the user would want to preview on a 3d sphere? or on a suzanne? or on a 2d plane? Exactly like currenty preview system in the material properties
Why the padding and square ratio tho?
Here’s a mockup with no padding, ratio would be adaptive to the node width, and the preview icon is similar to the old geometry node preview icon
Basicly a texture is in square format… You can’t make your node like that… and the advantage to the square already present in the node when he spawning is the place are already definied and you don’t need again to move your node. And you can choose if you want activate or disabled the preview by clicking in the X icon is very simple.
See all texture preview, everything are in square ! Is a preview of texture not a render by camera remember that.
See below a few exemple of node preview :
Octane :
SEE GOOGLE MY IMAGE WAS DELETED BY A MODO…
3ds max
SEE GOOGLE MY IMAGE WAS DELETED BY A MODO…
maya
SEE GOOGLE MY IMAGE WAS DELETED BY A MODO…
Unity
SEE GOOGLE MY IMAGE WAS DELETED BY A MODO…
unreal
SEE GOOGLE MY IMAGE WAS DELETED BY A MODO…
Substance designer
SEE GOOGLE MY IMAGE WAS DELETED BY A MODO…
In conclusion, the format need and applied are square. Texture are systematcly in Square format (64x64 - 128x128 - 256x256 - 512x512 -1024x1024 - 2048x2048 - 4096x4096 - 8192x8192 etc etc…)
I wouldn’t have the preview be part of the existing node layout. I don’t think having either the node’s title bar OR the contents shift vertically whenever the preview is toggled is acceptable from a UX perspective, when there are solutions that avoid this issue entirely. Obviously the preview could be placed above, it’s not quite a convention yet but geometry nodes do this with statistics already so that would be consistent. reducing vertical occupancy on mostly horizontal displays makes sense to me.
What do you think ?
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:
If nodes are aligned horizontally in lines then previews will align too
If you turn on or off previews position of sockets won’t change
Height of node won’t affect position of preview
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 :
one imput, one output and a menu bar for selecting the object like in shader preview
combine both, (Object selection with the preview) and you got a new node for a Material preview and not a texture preview…
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?
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:
(Thinking out loud)
