Page MenuHome

Complex node setup: Longer render times in experimental build vs. stable release
Closed, ResolvedPublic


System Information
Operating system: Windows-10-10.0.17763 64 Bits
Graphics card: 2x GeForce GTX 1080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 431.86

Blender Version
Broken: version: 2.81 (sub 14), branch: master, commit date: 2019-10-06 14:05, hash: rB54a9649e2636

Short description of error
I've noticed that certain (very complex) shader node setups yield much longer render times on the current experimental build compared with the 2.80 stable release.

To demonstrate this, I've deliberately created a complex test shader with various layers of nested node groups (which perform a bunch of mathematical operations with Math nodes). The final output is just a black cube.

Rendering the exact same file on my machine (specs listed above) with both stable release and experimental build yields following render times:

Average render time with 2.80.75 stable release: 0.48 seconds
Average render time with latest experimental build: 4.30 seconds

Exact steps for others to reproduce the error

  1. Download & open attached .blend file
  2. Render on both stable release & latest experimental build
  3. Compare results

Event Timeline

Germano Cavalcante (mano-wii) lowered the priority of this task from Needs Triage by Developer to Confirmed, Low.Wed, Oct 9, 3:08 PM

Some changes in the node system were made during the releases.
@Brecht Van Lommel (brecht), do you know if any of them justify this delay?
Cc @Clément Foucault (fclem)

(4 seconds doesn't look like much since it's only on initial load).

(4 seconds doesn't look like much since it's only on initial load).

Thanks for your reply. The 4 second difference applies only to this example of course, I've had this same issue with other, more complex files where the discrepancy in render times was far greater.

Confirmed. Just changing the colour on the material takes ages to update and this is not the case on 2.80.

Clément Foucault (fclem) raised the priority of this task from Confirmed, Low to Confirmed, Medium.Wed, Oct 9, 6:24 PM

The issue is caused by the nodegroup flattening, which does the same thing as you would do if you manually ungrouped every nodegroup.

The problem comes from nodeUniqueName which is checking if the nodetree does not have two node with the same name. And it does that for each node added from ungrouped nodegroups.

As far as I can remember we don't use names to identify nodes in the GPU nodetree evaluation so it might be OK to bypass it. But maybe some utility functions are using names.

@Brecht Van Lommel (brecht) Any input on this?

This is vastly improved with the fix but the material updates (e.g when changing colour) are still slower on the latest builds. On 2.80 it is real time but on latest build there is a small lag.
@Johannes Lampert (alterdings) Out of interest what time do you get now?

@Johannes Lampert (alterdings) Out of interest what time do you get now?

Is the fix already implemented in the latest daily build (hash: f61a8a2abd07)? If so, I'll download it and try it out.