| Field | Value |
|---|---|
| Name | Node Peek |
| Tagline | Live rendered thumbnail previews above shader nodes |
| Tags | Node, Material, Render |
| License | GPL-3.0-or-later |
| Website | https://github.com/mlstr0m/node-peek |
| Support / Bug tracker | https://github.com/mlstr0m/node-peek/issues |
See what every node does — without plugging it into the output.
Node Peek renders a small thumbnail above each node in the Shader Editor, showing that node's actual output. Textures, ramps, math, mixes, and full BSDFs all get a live preview, so you can read a material at a glance instead of rewiring it to the Material Output over and over.
When your material changes, Node Peek hands a copy of just that material to a
persistent background Blender running in --background mode. It renders each
changed node's output to a small image, which the add-on then draws above the
node with the GPU. Your actual scene is never modified and never re-rendered.
GPL-3.0-or-later. Source, issues and contributions: https://github.com/mlstr0m/node-peek
Built by mlstr0m — Résidence Principale.
Independent, clean-room implementation inspired by the idea behind the commercial "Node Preview" add-on. It shares none of that product's code.
Node Peek 0.5.5 adds individual preview sizing to the Shader Editor.
Select one or more nodes and use Individual Preview Size in the Node Peek sidebar to scale their previews from 25% to 300%. Each node keeps its own size, while multiple selected nodes can be resized together.
Reset Selected restores the selected previews, and Reset All restores every preview to its default size.
Resizing is instant, does not trigger a new render, and never modifies or dirties the .blend file.
This extension requests the following permission:
Write temporary render results to the system temp directory
Indeed does what do needs to be done...
Pretty incredible, and the design is quite elegant. One note - currently it doesn't support material nodes created through python, by scripts and addons - and I'm also pretty sure that such nodes also prevent the nodes downstream from rendering properly. I think you should be able to get around that by collapsing these custom nodes into regular node trees in a copy of the material you send for rendering. Either way, such change would be very welcome.
Thanks a lot for this report! The diagnosis was spot on, and it's fixed in v0.5.0, now live.
Root cause: the render worker runs with --factory-startup, so node types registered by other add-ons loaded as "undefined" there, no preview, and everything downstream evaluated flat, exactly as you described.
Your suggestion (collapsing custom nodes into regular groups in the shipped copy) was the right idea. I implemented it with a slightly different mechanism that gives the same result with less graph surgery: the worker now registers lightweight stub types for the custom node idnames before loading the material. Blender then binds the nodes by idname, and Cycles renders their internal tree natively so previews, and everything downstream of them, match what you see in your own render. This also works for custom nodes with per-instance node trees (two instances with different settings get distinct thumbnails) and for custom nodes nested inside groups.
One honest limitation: add-on nodes that aren't node-group based (pure-Python nodes, nodes for other render engines) can't be rendered by Cycles at all, in your own render either so those now show no thumbnail instead of a misleading flat one.
If your specific add-on still doesn't preview correctly, I'd love to know which one so I can test against it directly: https://github.com/mlstr0m/node-peek/issues
Thanks again, reports this precise make the add-on better for everyone.
Great addon! I would love to have the possibility to set a unified size for the thumbnails, instead of it being solely dependant on the node width.