GSoC 2023: Add a shader preview node - Feedback

The add-on only works with Cycles, this works with Eevee. That alone is a substantial enough difference to make the built-in a widely used tool

3 Likes

Quick Feedback

  1. Love the new flat previews
  2. Rendering responsiveness does freeze the interface, a work around for that might be nice
  3. There is a need for new operator to toggle previews on all selected nodes would be nice, right now turning them on one by one by one or off one by one by one is a bit harsh.
  4. An ability to toggle some previews to 3D and others 2D would also be nice, not all. This could be another new operator too.
  5. The ability to tune the resolution of the render (for performance reasons) in the options panel could also be nice, a bit like the Compositor preview settings of mid, low, high.

Other than that, the performance and fleshed out UX, - this is SO nice. I love it so much already. Keep up the incredible work!

11 Likes

Thank you so much, I appreciate.

  1. The rendering responsiveness is a real problem, and it is highly dependent on the platform and render engine you are using. I’m not an expert in this area, but if you could create a bug report for the freezing with a little video capture, I’ll try to look at the issue you’re having.
  2. There is already an operator: press F3 and search for toggle preview. You can then add it to your favorite (which is a menu toggled with Q) and assign a shortcut if you want(maybe P). That’s how I worked actually.
  3. I dont think that is a good idea, it would make the UI much more complex than needed. It’s currently a tough question, and Pablo will take a look at this UX aspect of 2D/3D previews.
  4. That makes sens, I’ll see in the future.
5 Likes

In compositing nodes the operator is exposed in the context and header menus and there’s a keymap (Shift-H) bound for it. Maybe worth matching that? (Well, unless the module developers have other plans for that regarding unifying node editor experiences.)

2 Likes

In my opinion, since width is fixed now UI/UX part is at the good stage already. I’d advise you to forget that now and focus on remaining time on performance to make it as real-time as you can. Because feature requests simply will never stop, and most of the stuff requested can be done either by add-ons or by little PRs in the future. I think this thread did it’s job, there’s not much left to expect except good performance. One of the best GSoC projects yet.

4 Likes

probably too late for that, but IMHO it would look nicer if the preview was inside the node itself, not outside as it is right now

6 Likes

Personally, I think that looks a lot worse. Also, it would make it harder to toggle the preview on or off, as the button would jump up as soon as you press it.

12 Likes

DNA data will not depend on image context data and preview runtime data.

Great work so far! Are there plans to have all the thumbnails the same size?

I remember a plugin called Node Preview, very many nodes have to be recalculated every time you drag a frame, the screen is very laggy, even just dragging the view, so the results that have been rendered can be cached images, there is no need to move the view to recalculate every frame.

I thought so too, at first.
It would look more elegant, sure, but it would function worse.
Still, i think it’s slightly unpleasant that the edges of the preview image are not aligned to the edges of the node. If it could move slightly to the left, and had a corner, which the user could click and drag to resize it, i think that would be nicer.

Looks better inside tue !

If the frame were around it in that manner, then the preview icon jumps to 2 different places for clicking. I think the frame looks nice, but would rather have the button and the image name not jump up and down.

6 Likes
  1. Here is a test to try reproduce, where the compilation for rendering previews with Eevee will hang the build.

Selected all and hit F3 to toggle previews on selection. Node groups are complex but I assume those won’t be toggled? This node tree, though my lite version, is maybe around 50 nodes min. I toggled on a top level. I am on an RTX 4090.

By the looks of it, you may need to chain the preview generation instead of all at once?

ERROR (gpu.shader): GPU_material_compile Linking:
      | Fragment info
      | -------------
      | C7050: "out_aov" might be used before being initialized
      | Internal error: assembly compile error for fragment shader at offset 2081546:
      | -- error message --
      | line 71837, column 1:  error: too many instructions
      | -- internal assembly text --
      | !!NVfp5.0
      | OPTION NV_internal;
      | OPTION NV_gpu_program_fp64;
      | OPTION NV_bindless_texture;
      | OPTION ARB_draw_buffers;
      | OPTION ARB_fragment_program_shadow;
      | # cgc version 3.4.0001, build date Apr 13 2023
      | # command line args:
      | #vendor NVIDIA Corporation
      | #version 3.4.0.1 COP Build Date Apr 13 2023
      | #profile gp5fp
      | #program main
      | #semantic common_block : BUFFER[0]
      | #semantic drw_view_ : BUFFER[1]
      | #semantic shadow_block : BUFFER[2]
      | #semantic light_block : BUFFER[3]
      | #semantic probe_block : BUFFER[4]
      | #semantic grid_block : BUFFER[5]
      | #semantic planar_block : BUFFER[6]
      | #semantic renderpass_block : BUFFER[7]
      | #semantic node_tree : BUFFER[8]
      | #semantic unf_attrs : BUFFER[9]
      | #semantic drw_infos : BUFFER[10]
      | #semantic drw_matrices : BUFFER[11]
      | #semantic utilTex
      | #semantic shadowCubeTexture
      | #semantic shadowCascadeTexture
      | #semantic maxzBuffer
      | #semantic planarDepth
      | #semantic probePlanars
      | #semantic probeCubes
      | #semantic horizonBuffer
      | #semantic irradianceGrid
      | #semantic refractColorBuffer
      | #semantic inScattering
      | #semantic inTransmittance
      | #semantic samp0
      | #semantic samp1
      | #semantic samp2
      | #semantic outputSsrId
      | #semantic outputSssId
      | #semantic refractionDepth
      | #semantic backgroundAlpha
      | #var int gl_FrontFacing : $vin.FACE_FLAT : SSA : -1 : 1
      | #var float4 gl_FragCoord : $vin.WPOS : WPOS : -1 : 1
      | #var float4x4 _common_block._pastViewProjectionMatrix :  : buffer[0][0], 4 : -1 : 0
      | #var float4 _common_block._hizUvScale :  : buffer[0][64] : -1 : 1
      | #var float4 _common_block._aoParameters[0] :  : buffer[0][80] : -1 : 1
      | #var int4 _common_block._volTexSize :  : buffer[0][112] : -1 : 0
      | #var float4 _common_block._volDepthParameters :  : buffer[0][128] : -1 : 0
      | #var float4 _common_block._volInvTexSize :  : buffer[0][144] : -1 : 0
      | #var float4 _common_block._volJitter :  : buffer[0][160] : -1 : 0
      | #var float4 _common_block._volCoordScale :  : buffer[0][176] : -1 : 0
      | #var float _common_block._volHistoryAlpha :  : buffer[0][192] : -1 : 0
      | #var float _common_block._volShadowSteps :  : buffer[0][196] : -1 : 0
      | #var bool _common_block._volUseLights :  : buffer[0][200] : -1 : 0
      | #var bool _common_block._volUseSoftShadows :  : buffer[0][204] : -1 : 0
      | #var float4 _common_block._ssrParameters :  : buffer[0][208] : -1 : 1
      | #var float _common_block._ssrBorderFac :  : buffer[0][224] : -1 : 0
      | #var float _common_block._ssrMaxRoughness :  : buffer[0][228] : -1 : 0
      | #var float _common_block._ssrFireflyFac :  : buffer[0][232] : -1 : 0
      | #var float _common_block._ssrBrdfBias :  : buffer[0][236] : -1 : 0
      | #var bool _common_block._ssrToggle :  : buffer[0][240] : -1 : 1
      | #var bool _common_block._ssrefractToggle :  : buffer[0][244] : -1 : 0
      | #var float _common_block._sssJitterThreshold :  : buffer[0][248] : -1 : 0
      | #var bool _common_block._sssToggle :  : buffer[0][252] : -1 : 1
      | #var bool _common_block._specToggle :  : buffer[0][256] : -1 : 1
      | #var int _common_block._laNumLight :  : buffer[0][260] : -1 : 1
      | #var int _common_block._prbNumPlanar :  : buffer[0][264] : -1 : 1
      | #var int _common_block._prbNumRenderCube :  : buffer[0][268] : -1 : 1
      | #var int _common_block._prbNumRenderGrid :  : buffer[0][272] : -1 : 1
      | #var int _common_block._prbIrradianceVisSize :  : buffer[0][276] : -1 : 1
      | #var float _common_block._prbIrradianceSmooth :  : buffer[0][280] : -1 : 1
      | #var float _common_block._prbLodCubeMax :  : buffer[0][284] : -1 : 1
      | #var int _common_block._rayType :  : buffer[0][288] : -1 : 0
      | #var float _common_block._rayDepth :  : buffer[0][292] : -1 : 0
      | #var float _common_block._alphaHashOffset :  : buffer[0][296] : -1 : 0
      | #var float _common_block._alphaHashScale :  : buffer[0][300] : -1 : 0
      | #var float4 _common_block._cameraUvScaleBias :  : buffer[0][304] : -1 : 0
      | #var float4 _common_block._planarClipPlane :  : buffer[0][320] : -1 : 0
      | #var float4x4 _drw_view_[0].viewmat :  : buffer[1][0], 4 : -1 : 1
      | #var float4x4 _drw_view_[0].viewinv :  : buffer[1][64], 4 : -1 : 1
      | #var float4x4 _drw_view_[0].winmat :  : buffer[1][128], 4 : -1 : 1
      | #var float4x4 _drw_view_[0].wininv :  : buffer[1][192], 4 : -1 : 0
      | #var float4 _shadow_block._shadows_data[0].near_far_bias_id :  : buffer[2][0] : -1 : 1
      | #var float4 _shadow_block._shadows_data[0].contact_shadow_data :  : buffer[2][16] : -1 : 1
      | #var float4x4 _shadow_block._shadows_cube_data[0].shadowmat :  : buffer[2][4096], 4 : -1 : 1
      | #var float4 _shadow_block._shadows_cube_data[0].position :  : buffer[2][4160] : -1 : 1
      | #var float4x4 _shadow_block._shadows_cascade_data[0].shadowmat[0] :  : buffer[2][11776], 4 : -1 : 1
      | #var float4 _shadow_block._shadows_cascade_data[0].split_start_distances :  : buffer[2][12032] : -1 : 1
      | #var float4 _shadow_block._shadows_cascade_data[0].split_end_distances :  : buffer[2][12048] : -1 : 1

Here is a gif of a process showing lag and freezing, a relatively simple material. This is in a build from Main about a week ago.

bforartists_Zuxb6tV3EU

To reproduce:

  1. turn on previews on a pre-built shader with Eevee
  2. Press middle mouse button to pan shader editor
  3. Take note that you can’t use the GUI till compile is done

Here is the video with the same shader in vanilla blender build from main today.

2 Likes

For mixed 2D and 3D previews, I’d say 3D previews are mainly useful for BSDF nodes, so the overlays could instead have the options to use flat previews exclusively, 3D previews on BSDF nodes only, and 3D previews on all nodes.

2 Likes

Makes sense to me. I upvote this idea - round for BSDF nodes.

2 Likes

What ever happened to this? Why did this never make it into an official release? (even as experimental)

5 Likes

This is currently in Blender as an Experimental Feature. Go to User Preferences > Interface > Enable Developer Extras, then go to Experimental > New Features > Enable Shader Node Previews.

3 Likes

Note that Experimental features are only available in Alpha builds.

And the case is simple. The person who worked on this in last year’s GSOC didn’t come back to work on it after that, and no one else decided to pick it up.

3 Likes

Which is a shame because that was such a cool feature! I used to use a shader editor program for Renderman called ShaderMan, it had this feature and I was able to build shaders very effectively even with math nodes because of this… instead of waiting for the final result you could build it up visually in the nodes and then link it up further downstream, saving a lot of time of experimentation.

I think I have an alpha build with this on my hard drive… sigh