In D6250#320582, @Tom Smalley (tomsmalley) wrote:

Is there any movement on this?

@Brecht Van Lommel (brecht) I know you have concern over performance regressions, but I'd rather it be correct and slow than incorrect and fast. I haven't been able to work around the artefacts (https://developer.blender.org/T85057) except for in some special cases.

Sorry, I left this thread for a while because there were no responses. Are reviewers still interested in this patch? Are there any technical issues other than performance?
I am currently busy in finishing a company project, so I may get some free time only after a couple of months.

Update the patch to be appliable to the latest revision.

For external path tracing libraries not supporting a feature for estimation of a tight ray start time at the moment, ray_offset() is restored as a fallback. However, self-intersection is still guaranteed to be prevented by this patch for them. Only functions ray_offset() and ray_update_tstart() need to be modified when those libraries are ready to support the feature.

In addition to triangle_update_tstart(), motion_triangle_update_tstart() is implemented to calculate a tight ray start time for motion triangle primitives.
I have completely forgotten triangle vertex motion.

For an AVX2-optimized CPU kernel, bvh traversal routines are set to use triangle_intersect() temporarily instead of triangle_intersect8() for rays with tstart updated.

External path tracing libraries now skip triangle_update_tstart() because the function does not work with them at all.
Some OptiX code is modified not to check unnecessary conditions. Optimization for OptiX is still left to experts.

In D6250#147614, @Patrick Mours (pmoursnv) wrote:

Thank @Patrick Mours (pmoursnv) for your advice. I have practically zero knowledge on OptiX.

Artifacts caused by mesh overlapping are resolved.

Recently I encountered an application which requires not only to render a scene filled with instanced objects correctly with arbitrary scaling but also to deal with objects of overlapped meshes without noticeable artifacts. For that application, my solution was to use this patch's method ( 'primitive id checking' ) with providing 'ray offsetting' as an additional option. I believe that we should put first priority on rendering a normal scene without glitches, but I admit that I am also distracted by mesh overlapping artifacts.

Cycles object property 'offset_bouncing_ray' and light property 'offset_emitting_ray' are added. Their default values are 'False' but if given 'True' for older blender files after the blender minor version number being raised, all previous versions of blender files would be rendered as before with the mesh overlap issue as less noticed as before. ( Self-intersection avoidance is guaranteed now with this patch, but brightness of hair geom test results will become darken a little. ) I believe this is how blender has evolved. The related UI change is not included, and it seems better for blender staffs to consider the UI layout themselves.

Thanks for spotting my last-minute error! I had to re-render benchmark scenes. Here are the results:

Logic for preventing self-intersection within a cardinal curve is revised to be consistent with logic for other primitives.
Epsilon check is introduced between adjacent line segments to make the algorithm more numerically robust. Since this epsilon is defined in the curve parameter space [0,1], it will not cause any harm unlike those defined in the world space or the object space.

Now I claim that this patch passed all the cycles regression tests.

Many bugs are fixed.

8>>! In D6250#144466, @Sergey Sharybin (sergey) wrote:

That is exciting to see movement on this front!

Unfortunately, with this change there are some real regressions caught by out regression suit. Just some of them: visibility_particles, ambient_occlusion_only_local, point density_vertices_world, volume_overlap, volume_scatter_albedo.

In D6250#144466, @Sergey Sharybin (sergey) wrote:

That is exciting to see movement on this front!

Unfortunately, with this change there are some real regressions caught by out regression suit. Just some of them: visibility_particles, ambient_occlusion_only_local, point density_vertices_world, volume_overlap, volume_scatter_albedo.

In T71071#806625, @jens verwiebe (jensverwiebe) wrote:

Hi robobeg
Yes. Using the the "spring" scene as test again, the same error occures with only the screen driving gpu should render.
So the issue seems not to be the balancing between differently VRAM equipped gpu's, your fix looks okay here.
I now follow your assumption that its another issue.
I can get the scene to render by either reducing the haircount or other simplifications that reduce memory usage.
I think now that the memory used for the attched screens is not taken into account. ( ? )

You might end with the same result as me, is it okay you make a new bugreport out of this find yourself ?
You are the specialist here.

Greetings ... Jens

ㅡ>>! In T71071#806412, @jens verwiebe (jensverwiebe) wrote:

Unfortunately this does not fix the Optix render if one of the gpu's is driving the screen.
I get with 2 exact same RTX 2080 and the spring test scene:

OptiX error OPTIX_ERROR_LAUNCH_FAILURE in optixLaunch(pipelines[PIP_PATH_TRACE], cuda_stream[thread_index], launch_params_ptr, launch_params.data_elements, &sbt_params, wtile.w * wtile.num_samples, wtile.h, 1), line 668

and then only the not screen driving device renders the scene. Cuda seems fine now.

Jens

Parentheses are added around ‘&&’ within ‘||’ to make it easier to understand and silence strict compiler warning.

The style of comments is modified.

In D6126#141224, @Sergey Sharybin (sergey) wrote:

This isn't really a higher level overview of the problem.

Am i right that the issue is that multiple compute devices were using same device pointer, while the code was relying on the fact that it never happens?

In D6126#141224, @Sergey Sharybin (sergey) wrote:

This isn't really a higher level overview of the problem.

Am i right that the issue is that multiple compute devices were using same device pointer, while the code was relying on the fact that it never happens?

In D6126#141137, @Sergey Sharybin (sergey) wrote:

The code related to 'device_memory' does not handle this situation properly.

Can you elaborate a bit more about it (on a higher level) ?

Tab spacings were modified according to surrounding codes.

Thanks for a quick fix. In the above patch, I found one initialization was missed:
(svm_closure.h, line 336)
bsdf->T = make_float3(0.0f, 0.0f, 0.0f);
and it is not in function 'bsdf_microfacet_ggx_refraction_setup()', either.

This patch might result in wrong merges of MicrofacetBsdf closures.

I found that this patch made 'device_only_memory<T>' over-allocate device memory by a factor of sizeof(T). I think that line 248 of 'device_memory.h' should be revised from

data_size = num*sizeof(T);

to

data_size = num;

I made a simple example showing the bug.
An emissive sphere is reflected on a floor with two different principled bsdfs. The left half has 'subsurface: 0.000' while the right half has 'subsurface: 0.300', so the latter is expected to look fuzzier.

That's it! Thanks for a quick fix!
Although I cannot test the patch at the moment, I am certain that it will work for the 'path tracing' mode because 'shader_bsdf_pick' and 'shader_bssrdf_pick' now perform sampling closures in the same way with the same 'randu' ( = PRNG_BSDF_U ). ( ... besides numerical issues. How about sharing the code body as a common function? )

Yes. I will upload the .blend file after this weekend.

I encountered an issue related to this patch. Using blender v2.79 I made a test scene having a floor with rough reflection. However, the floor was rendered like a mirror with the blender executable built with the latest master branch. I found that the phenomenon occurred when a single shader generated multiple BSDF closures along with BSSRDF closures.

Oh... I've always taken a snapshot of projects/blender.git at the git://git.blender.org/blender.git but it has given me mixed files.
The master version contains the atomic version of util_math_matrix.h, as you said.
Thanks.

I also encountered this problem and found a remedy.

I have been working on a rendering project, which heavily relies on the cycles denoising feature. ( Thanks a lot~! )