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

Did this work in earlier versions of Blender?

I can confirm the issue.

I've just spoken to Jules Urbach from Octane, he's going to ask Lino from his Dev team to help you out.

In T68920#794109, @Brecht Van Lommel (brecht) wrote:

I'd prefer us to first try a better solution, like ignoring backfaces, which may not be all that complicated.
Also as described in T37814#773025, this needs changes in BSDF evaluation too.

I'd prefer us to first try a better solution, like ignoring backfaces, which may not be all that complicated.

I get the same result. Here's a less noisy version.

I managed to run a few tests and it works!

confirmed. This is a major issue!

I want to add that this is not just an error that appears in very few situations. It appears (for my understanding) for nearly every realistic sized light (lights <1m).
I have a big project where I can render no single frame without this error. ~90% of the light comes from area lights (10x10cm floor lights).
It looks like the contrast or brightness setting is different when rendering with CPU or GPU. GPU frames are always a lot brighter than CPU frames. I currently don't know which device produces the correct output. It's annoying and very time consuming that you cannot use both devices at the same time anymore to speed up rendering.

Another possible workaround is the operator "make instances real". Execute, then deactivate the particle system. At least for rendering still images it worked for me, before I sent the file to our renderfarm.

Move inversesqrtf to function

For anyone requiring a work-around for this bug, I have been able to successfully render from the terminal by rendering one eye at a time, and manually combining both left and right eyes into one image, after the render is complete.

Maths Node: Additional functions

I am able to replicate this bug without rendering from command line. Scene is complex, and is being rendered out in spherical (equirectangular) stereoscopic format. Cycles, affects both GPU and CPU render.

In T49234#791232, @Kévin Dietrich (kevindietrich) wrote:

You have to apply the patch and compile Blender to test the feature, it is not in the daily builds. Also your file does not have velocity information (the array size is 0). So without the patch and without custom velocities, Cycles is just using an interpolation between the previous, current, and next frames.

Pablo suggested poking. So i'm poking :) Increasing motion blur steps doesn't help.

You have to apply the patch and compile Blender to test the feature, it is not in the daily builds. Also your file does not have velocity information (the array size is 0). So without the patch and without custom velocities, Cycles is just using an interpolation between the previous, current, and next frames.

I have some blurriness, but it doesn't seem to look right. (see Images)
This is a particle system that I exported and then reimported to reverse the movement. And the plane is a dupliobject on the vertices of the ABC.
I would not expect to see a clear outline of the plane in the image with motion blur. Also, the position of the blur is set to Center. But this seems more like Start. And the shutter duration also has no effect.

For those who haven't noticed, I updated and fixed the patch D2388, please try it if you can!

Can confirm, checking... seems code in BlenderSync::sync_world still relies on a blender world (mixes the background color with the viewport color), will have a look.
[eeve seems to pick the theme color as a fallback if no world is present? maybe cycles should do this as well -- or just black...]

In T66855#788826, @Dalai Felinto (dfelinto) wrote:

Talked to @Brecht Van Lommel (brecht) and this is indeed a bug, however volume + render passes has always been weak, thus this is not a high priority:
"It's more of a design issue really, no way to cleanly separate volumes and render passes. So we have to make some choices or add settings to control it."

Talked to @Brecht Van Lommel (brecht) and this is indeed a bug, however volume + render passes has always been weak, thus this is not a high priority:
"It's more of a design issue really, no way to cleanly separate volumes and render passes. So we have to make some choices or add settings to control it."

I can confirm.
You can easily observe by selecting one of the invisible objects and enabling the Ray Visibility Camera option.

It's 2 GB actually, but anyway - thanks for claering things up, will jsut render at CPU if GPU crushes.

I can do full rendering again. I do not know why but if I render with a Tile Size equal to the final resolution all works normally.
The problem is that I can not enjoy my PCs with multiple GPUs.

OK thanks, that looks like it’s confirming that you are just hitting the limits of your GPU here, GT 740 is a pretty low-level entry one from 2014, with only 1GB of memory… It won’t make miracles. You can follow the link given at the end of those messages (https://docs.blender.org/manual/en/latest/render/cycles/gpu_rendering.html), but this probably won't help much in that case.

This is a compiler bug in the ROCm drivers, which we don't support yet for Cycles. Many changes to the Cycles kernel were made since 2.79b.

There's people in the world who never really used CMD, and i'm one of them. This commands tells NOTHING on how and in which order they should go;
However, after reading about CMD itself and one more half an hour later i figured all out, here's the .txt file with all that console recorded:

strange, the download link worked in the report preview. I have tried again.

To address this issue, what do you think about adding a "shadow bias" parameter to control an offset from the surface along the geometric normal ? I know its not a perfect solution but at least it would allow users to avoid a lot of rendering artifacts that are due to shadow termination.

Don’t want to be rude, but seriously… http://letmegooglethat.com/?q=blender+command+line will give you all you need to know in the two or three first answers…

1. Yep, using latest driver version; GeForce Game Ready Driver, version 436.48, release date (Month/Date/Year) 10.1.2019