Slow initialization in the rendered viewport after the default normal map added #97378

New Issue

Stay_Here · 2022-04-16T07:41:36+02:00

Stay_Here commented

2022-04-16 07:41:36 +02:00

System Information
Operating system: Windows-10-10.0.19043-SP0 64 Bits
Graphics card: Quadro RTX 3000 with Max-Q Design/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 512.15

Blender Version
Broken: version: 3.1.0, branch: master, commit date: 2022-03-08 18:16, hash: c77597cd0e
Worked: (newest version of Blender that worked as expected)

Short description of error

slow initialization time in viewport rendering.mp4
The slow initialization in the rendered viewport occurs after the default normal map node was added in the Skin shader. (The Skin shader is very simple - it contains just a Principled BSDF and Material Output.) I have tried both CUDA and Optix, and the slow initialization exists in both cases after the default normal map node added.

Exact steps for others to reproduce the error

Sample to test slow initialization in viewport rendering.blend

Steps to reproduce the bug:

1, Download the sample file and open Blender;

2, Select the mesh, and go to the Sculpting mode, and then under the "Remesh" tab change the Voxel Size from 0.4 m to 0.004 m, or even smaller value if your computer can handle. Click "Remesh".

3, Then click the rendered preview. You will find that the higher the poly-count, the slower initialization speed.

4, Go to the Shading mode, and remove the Normal Map, and click the rendered preview. Your initialization speed returns to normal, even if the poly-count is high.

**System Information** Operating system: Windows-10-10.0.19043-SP0 64 Bits Graphics card: Quadro RTX 3000 with Max-Q Design/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 512.15 **Blender Version** Broken: version: 3.1.0, branch: master, commit date: 2022-03-08 18:16, hash: `c77597cd0e` Worked: (newest version of Blender that worked as expected) **Short description of error** [slow initialization time in viewport rendering.mp4](https://archive.blender.org/developer/F13003692/slow_initialization_time_in_viewport_rendering.mp4) The slow initialization in the rendered viewport occurs after the default normal map node was added in the Skin shader. (The Skin shader is very simple - it contains just a Principled BSDF and Material Output.) I have tried both CUDA and Optix, and the slow initialization exists in both cases after the default normal map node added. **Exact steps for others to reproduce the error** [Sample to test slow initialization in viewport rendering.blend](https://archive.blender.org/developer/F13004836/Sample_to_test_slow_initialization_in_viewport_rendering.blend) Steps to reproduce the bug: 1, Download the sample file and open Blender; 2, Select the mesh, and go to the Sculpting mode, and then under the "Remesh" tab change the Voxel Size from 0.4 m to 0.004 m, or even smaller value if your computer can handle. Click "Remesh". 3, Then click the rendered preview. You will find that the higher the poly-count, the slower initialization speed. 4, Go to the Shading mode, and remove the Normal Map, and click the rendered preview. Your initialization speed returns to normal, even if the poly-count is high.

Stay_Here commented

2022-04-16 07:41:37 +02:00

Added subscriber: @Stay_Here

Lukas Stockner commented

2022-04-16 22:30:29 +02:00

Added subscriber: @LukasStockner

Lukas Stockner commented

2022-04-16 22:30:29 +02:00

If the issue can't be reproduced with another file, here are some things you can check to narrow it down a bit:

Does the slowdown also happen with CPU rendering?
Does the slowdown also happen in Blender 3.0 (or older nightly builds)?
Does starting an F12 render also take longer with the Normal Map node there?
- If yes, can you run the render from the command line and check which step takes longer?
In case you can compile Blender locally: If you interrupt the process while it's loading, what are the threads doing?

If the issue can't be reproduced with another file, here are some things you can check to narrow it down a bit: - Does the slowdown also happen with CPU rendering? - Does the slowdown also happen in Blender 3.0 (or older nightly builds)? - Does starting an F12 render also take longer with the Normal Map node there? - If yes, can you run the render from the command line and check which step takes longer? - In case you can compile Blender locally: If you interrupt the process while it's loading, what are the threads doing?

Stay_Here commented

2022-04-17 07:46:12 +02:00

In #97378#1342302, @LukasStockner wrote:
If the issue can't be reproduced with another file, here are some things you can check to narrow it down a bit:

Does the slowdown also happen with CPU rendering?

Does the slowdown also happen in Blender 3.0 (or older nightly builds)?

Does starting an F12 render also take longer with the Normal Map node there?

If yes, can you run the render from the command line and check which step takes longer?

In case you can compile Blender locally: If you interrupt the process while it's loading, what are the threads doing?

The task has been updated, and a sample file has been uploaded and the steps to reproduce the bug are included.

This problem has something to do with the poly-count of the mesh.

To answer your questions:

Yes, the slow down does happen with CPU rendering.
Yes, the slowdown also happens in Blender 3.0 and 2.93.
Pressing F12 render is not affected in the Blender 3.1.0, and works normal.
I don't know how to compile Blender locally.

Thank you!

> In #97378#1342302, @LukasStockner wrote: > If the issue can't be reproduced with another file, here are some things you can check to narrow it down a bit: > - Does the slowdown also happen with CPU rendering? > - Does the slowdown also happen in Blender 3.0 (or older nightly builds)? > - Does starting an F12 render also take longer with the Normal Map node there? > - If yes, can you run the render from the command line and check which step takes longer? > - In case you can compile Blender locally: If you interrupt the process while it's loading, what are the threads doing? The task has been updated, and a sample file has been uploaded and the steps to reproduce the bug are included. This problem has something to do with the poly-count of the mesh. To answer your questions: 1) Yes, the slow down does happen with CPU rendering. 2) Yes, the slowdown also happens in Blender 3.0 and 2.93. 3) Pressing F12 render is not affected in the Blender 3.1.0, and works normal. 4) I don't know how to compile Blender locally. Thank you!

Lukas Stockner commented

2022-04-18 00:22:42 +02:00

Thanks for the info!

Turns out that the slowdown is the tangent space computation. The reason for the slowdown when adding the node is that the Normal Map node requires tangents to operate. In an F12 render, the shader graph would be optimized, and the unconnected node would be removed. However, for viewport renders, this optimization is not performed. This is on purpose: Otherwise, you'd end up in a situation where e.g. changing a mix factor from 0 to 0.1 would trigger a complete rebuild since a branch of the shader just "came alive". Therefore, interactiveness is prioritized over startup time.

You can verify this by connecting the Normal Map node to the shader: Now an F12 render also takes longer.

I've added some optimizations in D14675 to speed this up a bit, but some level of slowdown is expected here unfortunately.

Thanks for the info! Turns out that the slowdown is the tangent space computation. The reason for the slowdown when adding the node is that the Normal Map node requires tangents to operate. In an F12 render, the shader graph would be optimized, and the unconnected node would be removed. However, for viewport renders, this optimization is not performed. This is on purpose: Otherwise, you'd end up in a situation where e.g. changing a mix factor from 0 to 0.1 would trigger a complete rebuild since a branch of the shader just "came alive". Therefore, interactiveness is prioritized over startup time. You can verify this by connecting the Normal Map node to the shader: Now an F12 render also takes longer. I've added some optimizations in [D14675](https://archive.blender.org/developer/D14675) to speed this up a bit, but some level of slowdown is expected here unfortunately.

Stay_Here commented

2022-04-18 03:47:24 +02:00

Thank you for your explanation!

In #97378#1342585, @LukasStockner wrote:

You can verify this by connecting the Normal Map node to the shader: Now an F12 render also takes longer.

In the sample file, after remeshing the cube with the voxel size from 0.4 m to 0.004 m to get 1.5 M vertices, my render result after pressing F12 is:

Unconnecting the Normal Map node: 10.10 s

Connecting the Normal Map node to the Normal on Principled BSDF: 18.01 s

Thanks again!

Thank you for your explanation! > In #97378#1342585, @LukasStockner wrote: > > You can verify this by connecting the Normal Map node to the shader: Now an F12 render also takes longer. In the sample file, after remeshing the cube with the voxel size from 0.4 m to 0.004 m to get 1.5 M vertices, my render result after pressing F12 is: Unconnecting the Normal Map node: 10.10 s Connecting the Normal Map node to the Normal on Principled BSDF: 18.01 s Thanks again!

Pratik Borhade commented

2022-04-19 08:41:40 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Pratik Borhade commented

2022-04-19 08:41:48 +02:00

Added subscriber: @PratikPB2123

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Slow initialization in the rendered viewport after the default normal map added #97378