Normally you would denoise all the components, together not a subset of them. So then this works fine.

@Brecht Van Lommel (brecht) so what's the point of 'noisy image' for now? We either can render denoised image, or without denoiser. If I render something for 9 hours and denoiser will throw me out a glitch I can't get the before-denoising image and do anything with that. All the time is wasted...

Maybe I did something really stupid, but I couldn't apply the patch to the recent master, and neither could I figure out what was the last commit this patch would work on, so I manually (and a bit painfully) introduced the changes and managed to make it build after fixing a few implicit conversions which appear to be disallowed by the compiler options (taking warnings as errors, I think).

While this may be a useful improvement, this is not considered a bug. The denoising passes only contain the selected components.

• Cycles: Added const to some variables.

Both RenderMan and Arnold have sphere lights that emit to the outside only.
RenderMan render:

Excuse my noobishness, did I get right that this diff didn't get committed as of yet? When can we expect it if so?
Thanks

@Brecht Van Lommel (brecht) bug or not?

Please mention Blender version, attach a .blend and provide exact steps to redo.

Hi there,

In D4676#106437, @Sergey Sharybin (sergey) wrote:

If desired, I can also change it to make the sphere a double-sided emitter by switching to uniform sampling when the shading point is inside the sphere (this is what PBRT does).

If desired, I can also change it to make the sphere a double-sided emitter by switching to uniform sampling when the shading point is inside the sphere (this is what PBRT does).

There is a slight performance hit from the more complex sampling.
Haven't done extensive benchmarking, but a test scene I measured went from 58s -> 59s CPU render time.

More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.

It seems to be connected to T63379.

After another testing with various settings I found another interesting thing. Somehow, when I set Render > Display Mode > Keep User Interface and using minimum layout (3D viewport, shader editor, and Outliner) EEVEE rendering perfectly fine (in ordinary setting it keeps crashing before 50 frames). I haven't tried this method with Cycles though.

In D3998#92436, @Marco Alamia (Macro) wrote:

In D3998#92422, @Dalai Felinto (dfelinto) wrote:

Would this fix this T59362?

Yes, it gives you a tool to fix that.

The way the original asset is setup will generate those results, that can't be fixed. If the geometrical normal is bent your TBN is bent and the colors are not flat.
If you straighten the normals though you get flat colors, but in the current blender you also get an incorrect projection and bad seams in the normal map. With the average normal for projection you fix the projection.
I have attached what I did to get the desired results.

I'm just going ahead and updating this with my fix, the history should still be there so we could go back to your fix.

Thanks @Caetano (Caetano). I managed to get it working using blender renderer. So now half of my project is rendered using blender renderer and other half using cycles! Its not ideal, but works for now.

As I explained earlier in this task, I don't think this is the right approach. It makes optimizations and some features difficult, volumes should be a type of object rather than a shader. I expect a native volume object type will be added in one of the releases after 2.80.

@haaput (haaput) no further work that I've heard of, although if you have a particular use case you'd like to solve, I might be of help to find a workaround.

In T60462#655682, @Muhammad Radifar (radifar) wrote:

Same issue here. And what is interesting is, when I change the thread from 4 (max) to 3, it significantly increase the amount of frame rendered before it crashed (around 2-4 times the number of frame). Using both CPU + GPU for rendering.

My system is:
Kubuntu 18.04
Intel Core i5 3570
DDR3 4 GB
NVIDIA GT 730 GDDR5 1 GB
Blender version: 2.80 Daily build (tried new build almost every week since february)

Same issue here. And what is interesting is, when I change the thread from 4 (max) to 3, it significantly increase the amount of frame rendered before it crashed (around 2-4 times the number of frame). Using both CPU + GPU for rendering.

@Caetano (Caetano) is this still pending? Hey @Brecht Van Lommel (brecht) I see this is assigned to you. If you are busy I can try to give it a shot next month but I don't have any experience with blender code base so I'll need some help with this.

Yes, it works with disabled experimenal features.

In D4644#105861, @Brecht Van Lommel (brecht) wrote:

Can you figure out why the indices are negative in the first place?

In D4644#105861, @Brecht Van Lommel (brecht) wrote:

This seems like a workaround more than a fix for the real issue.

I would expect it to only loop over pixels within bounds, not use zero for pixels outside of bounds.

Can you figure out why the indices are negative in the first place?

The only change between these builds was in adaptive subdivision, where it was not subdividing with the right detail in some cases. It may be that this caused finer subdivision and resulting higher memory usage, after which it runs out of memory for denoising.

This seems like a workaround more than a fix for the release issue.

Yes, I'm using denoising - after disabling blender stopped crashing. Turning on again - crashing.

• Please attach a .blend file to reproduce the issue.
• Are you using GPU or CPU + GPU rendering?