Right, the fixed 0.25 roughness is definitely a hack, hopefully we can get rid of that too.

Maybe also the fixed roughness of 0.25 for the G term can cause some issues. Disney didn't really say in their paper from 2012 what the purpose of this hack was, but only that it's "found to be plausible and artistically pleasing". I will try at first to change only the D term to GGX without changing the G term (which means keeping the 0.25 roughness here) and look if this causes more problems and if so, I think we should go with having a consistent roughness throughout the whole clearcoat calculation. By doing so, we wouldn't need to have a distinction between clearcoat and non-clearcoat in the Microfacet BSDF anymore.

@Brecht Van Lommel (brecht), yes, I see this like you do. I don't think that we get a real benefit out of the GTR1 distribution. The difference (especially because clearcoat is only applied with a pre-factor of 0.25) should be pretty low and can thus be neglected. For me it seems ok to switch to GGX, but I will at first try to compare both versions today before adding a patch.

@Pascal Schön (VanCantus), the root of the issue here seems tricky to solve.

In T53068#466102, @Sergey Sharybin (sergey) wrote:

@Brecht Van Lommel (brecht), we don't have threadripper at the studio, only Ryzen 7 1800X.

Some other questions / ideas to troubleshoot the issue:

• Make sure all Windows updates are installed.
• Disable any possible power saving setting in BIOS.
• Disable any possible power saving settings in Windows itself.
• Disable HyperThreading.
• Check whether Blender detects proper number of CPU threads.
• Get Ubuntu LiveCD and see if there will be a performance issue on Linux.

@Brecht Van Lommel (brecht), we don't have threadripper at the studio, only Ryzen 7 1800X.

@Sergey Sharybin (sergey), is there a machine with a CPU like this in the Blender Institute?

The first time i tried to render the scene was unpacked. After hanging for hours i started using all the benchmark files on the blender website and comparing this with my intel system. On this point i saw a significant difference between the threadripper and my intel sytem. Not on the small ones like the BMW, classroom, but the production benchmark and my own scenes. In my opinion most of the threadripper tests where done on these scenes, and not large scale RAM scenes.

Does it work if you unpack the textures first?

@rob (blenderpedia) Okay, gotcha.

In T53068#465962, @Joel Godin (FloridaJo) wrote:

@Brecht Van Lommel (brecht) I'm not sure he did the OpenMP test as you described.
The video showed him changing threads in the UI as opposed to a command line command. Is that the same?
Rob, can you verify that you ran this in command line?

cd c:\<blender installation directory>
set OMP_NUM_THREADS=1
blender

@Brecht Van Lommel (brecht) I'm not sure he did the OpenMP test as you described.
The video showed him changing threads in the UI as opposed to a command line command. Is that the same?
Rob, can you verify that you ran this in command line?

Intresting result when doing a blender internal benchmark test. I used an 11 GB ram scene on my 4770K and threadripper workstations.

@Joel Godin (FloridaJo), the GPU is not involved in the synchronizing objects stage, so I doubt it's causing issues here.

It doesn't look like it's the CPU.
You may want to see if it is a GPU bottleneck.
GPUview is the tool for that, a description of it is here;
https://graphics.stanford.edu/~mdfisher/GPUView.html

In T53068#465673, @Brecht Van Lommel (brecht) wrote:

Which parts of the render are slow? The video shows just the synchronizing objects stage, is BVH build slow too, and path tracing?

Which parts of the render are slow? The video shows just the synchronizing objects stage, is BVH build slow too, and path tracing?

I created a video including microsoft Process Explorer.

Hello Rob.
Can you go to this page and follow the instructions for installing the Microsoft Process Explorer
to better show the threads running during that process?

I see. Just wanted to report it, in case it was a bug. Thank you very much, Brecht.

Unfortunately this is not supported yet, it will be for a future release.

I can confirm that there is a problem, here.
I had to open an Image Editor, modify Number of frames, Start Frame settings and enable autorefresh into Image Properties.

More than a week passed without a reply.

Well unless we have a way to reproduce that crash there is not much we can do, so for now i'm going to close this ticket, if the problem ever comes back, feel free to open this ticket again and attach a .blend file exhibiting the issue.

@LazyDodo (LazyDodo)
The render seems to completes successfully with denoising on System 1 with the (at the time of this writing) latest 32-bit build from buildbot.

There is some work being done in this area in T52572 , can you confirm with a build from http;//builder.blender.org that the problem has been resolved?

Indeed, please explain clearly what you mean by "not working" and provide us steps to redo the probmem. Does it crash, does it not save the file, does it render black, .. ? Does it happen with the default scene or only a specific .blend you are working on, etc. Are you using the GPU or CPU for rendering?

Please follow our submission template and guidelines and make a complete, valid bug report, with required info, precise description of the issue, precise steps to reproduce it, small and simple .blend and/or other files to do so if needed, etc.

Thank you very much, Vuk. Just tried it and it works. This should get me by while I save up for a new GPU. The main thing I need is the viewport render preview which I use a lot and the CPU is just not fast enough.

In T52752#459286, @Alexander Chaplinskikh (AlexChaplinskikh) wrote:

Wonderful. Any way to whitelist it and build it myself from the source? I don't know Python but I could try. I was excited for this release but this just screwed me up completely.

Wonderful. Any way to whitelist it and build it myself from the source? I don't know Python but I could try. I was excited for this release but this just screwed me up completely.

As mentioned in the release notes, we only support graphics cards with GCN architecture 2.0 and above).

More than a week passed without a reply.