I use the same preview scenes as in the material preview panel, and I temporarily chose sphere rendering because for demo purpose it is better. But plane previews can be better, I’ll probably have a try on a way to change that in the following weeks.
Regarding the preview size, I agree that it is inconvenient to have too wide previews for wide nodes, but it comes from the way the info tooltip is drawn. One way to deal with it is probably to hardcode a max size of a fixed size (it is not clear to me which is better). I’ll add it to my todolist for the next weeks.
I’m sure many will like a 3D object as the preview, but in most cases I prefer a 2D plane. When I’m working with noise and contrast and alpha channel borders, a flat view makes it easier to see fine adjustments as an actual mapping vs “interpolated into UV”. As I’ve mentioned previously, I’m already able to see a 3D preview of the result in the 3D Viewport.
I think following material properties makes sense, one of the options there is a plane.
We should find some way to expose that option in the shader node editor, though I’m not immediately sure what the best place is. Maybe it’s fine in the overlays panel, even though it’s a per-material setting rather than a setting of the editor.
The downside of sharing the setting would be that this also affects asset thumbnails, so if you switched to a plane temporarily for viewing, that would affect the asset as well unless you remember to set it back. Some solutions to that could be a separate preview type for the asset. Or a node editor option to switch between 2D and 3D previews, while still having the 3D shape defined by the material and shared with the asset system.
Do we anticipate that the preview in the shader/node editor is going to generate faster than is currently within the shader preview in the properties panel (which is quite slow)?
I assume part of the slow rendering in that panel is due to it showing other render effects, such as shadows - which isn’t required for the nodal area.
Yes and no
On one hand, I said I would try to implement further improvements such as AOVs for non shader preview (most of them I think). For cycles this might be an improvement (I don’t know if it will be noticeable).
I tried with eevee previews and it is already smooth like butter without any form of optimisation (scene construction…).
One thing that came to my mind is whether we could set eevee for every non shader previews : it could make sense because it would not differ (not sure).
And on the other hand, the system will fundamentally be the same and will continue to be, because I do not think that having a totally different pipeline for that use is a good thing.
Those optimisation element are the things I’ll normally work on in July, so stay tuned .
I guess that would depend if the preview primitives should be set globally or per node?
With the latter maybe this can be put inside Node Context Menu under RMB?
First, looks like a promising start. Things I’ve noticed:
Preview appears to be 3D sphere only? I’m guessing other styles coming later, or else they are already there and I couldn’t find the setting to change it to square.
Update speed is not good, when changing parameters - I mentioned this concern earlier in the thread; it’s lagging behind all the other previews. Don’t know if that’s because it appears to be using exactly the same preview as the shader sidebar, and being evaluated after everything else.
Previews are very low resolution, even when displayed at the same size of the shader sidebar preview.
I find myself constantly trying to click on the preview window as part of the entire node when dragging nodes. This doesn’t work, but would nice if it did.
That’s what’s intended I think. As the preview scene is different, there is no way to render them. Maybe I could try to preview the current object but I consider it an extra task.
preview scene such as sphere/cube/etc… is planned, but I prefer do all the major preview management now and focus on those aspects later
update speed is really important, I know, and I’m currently trying some optimisation techniques. It’s will be very hard to make cycles preview realtime.
the resolution will be changeable, and I’ll make it appear somewhere for the user to change it, after finishing the main work, that’s already in the TODOs
regarding the node behaviours in term of moving nodes, selecting etc is unclear for now, I’ll have to discuss it with the UI team and figure what to do, some discussion already happened about it on blender.chat
So, I’m currently busy doing the main functionalities. Even if the aspects you mentioned are very important to use node previews, I’ll work on them later.
Oh, you mean that convertor nodes are not meant for previewing ?
I personally think previewing every type of node makes sens, because when you add two different noises, you want to see the result for example. I may have misunderstood what you meant.
Yeah, I would agree that it’s valuable to have a preview on every node, whether it’s a converter node or not.
I’d rather see every step in the process, and the effect that each node has, rather than having large blind spots, where it’s unknown which node is doing what.
Ultimately, I think it’s actually more valuable to have the previews on those nodes, as generally I already know what a noise or image texture looks like, and it’s the transformations that I’m applying to it that I want to preview.
Hey, I would like to ear your thoughts about the preview resolution.
I explain: when rendering previews for nodes, there is no reason to use the size of the preview rectangle as rendering size, because we dont want to recalculate previews for every zoom.
So we will need to have a fixed value for resolution of the preview (currently hardcoded as 120x120px). The user will be able to change it depending on the hardware(perfs), screen DPI(display), …
Where should it be set ? Per node area ? In the preferences ?
Preferences should be fine. You’ll hardly ever change that feature. And the cases of needing different resolution for Compositor and different for Shader will be almost zero.
Not per-node, no. I’d suggest preferences. It’s something you’d set once (or very occasionally), and doesn’t need to be node, shader, or file specific.
.
.
