I've edited the task name. Thanks for the heads up!

Hey @L. E. Segovia (amyspark), and welcome!
Please rename your task to some more specific name, we have more than one GSoC project this year again. ;)

same is true for Separate RGB btw.

I don't think shared meshes have anything to do with this, the output looks identical to me if I make each object use its own mesh.

can confirm on windows, somehow the material view works correctly, but the actual render doesn't.

This has been reported before, see T53498, I guess this could be merged?

Thanx for investigating.
Could you please attach a .blend as well so someone can reproduce with your geometry?

@Philipp Oeser (lichtwerk) @Jeroen Bakker (jbakker) Thanks for investigating this more. I also remember at some point when I was accessing the pixels directly through "Viewer Node" image block and stored them on disk. What I realized however was the pixels were sort of rotated. I remember the depth map rendering that I got was shown 90 degrees rotated. So I have a request from you: I would appreciate if you can provide a nice Python API that allows people to easily access the rendering results without having to store the renderings on disk. Maybe bpy.ops.render.render() could take an argument like keepInMemory=True. Then people can access the rendering results through something like renderings = np.array(bpy.ops.render.results). The should also account for having a couple of output nodes. For instance, if in the node editor I have 5 Viewer nodes, renderings should be a 5 x 4 x resolution x resolution tensor.

Interesting problem.

I believe this is caused by an extreme value for bump (causing the normals to point in all kinds of directions). Or I'll quote @Brecht Van Lommel (brecht) from T54498:

When rendering with OSL it compiles the shaders to native code and executes that, the SVM shader stack isn't used

Could you explain please, why does Open Shading Language helps in this situation? Enabling this thing was kind of desperate move, but helpfull in this case, so I am intersted in a bit more info

Increasing SVM stack size will marginally increase GPU memory usage.

That's correct, you can change the volume sampling method to Distance in the material if you want the same result on the CPU. Equiangular and multiple importance sampling reduce noise a lot when there are lights inside or near the volume, but increase it when that's not the case.

Pretty sure this is the difference between decoupled volume sampling on the CPU vs regular volume sampling on GPU (decoupled isn't supported on GPU). Doesn't look like a bug to me.

2.79 5bd8ac9 is quite old, please try 2.79b and/or a build from http://builder.blender.org and see if the problem persists.

@Brecht Van Lommel (brecht) Just an update: I can get somehow around the forking issue using subprocess and doing one rendering at the time. However, the problem with using subprocess is I have to literally import everything I need from scratch. This makes the rendering much more time-consuming than doing the rendering normally. Sorry if it's too obvious that I'm just trying to convince you to prioritize this :) I hope that happens :)

Hm, it's running against the stack size limit, see here

Gathering all volume intersections would be good also to improve performance.

A possible remedy would be to gather all volume intersections in one go (similar to intersect_shadow_all) and do the ray marching in a single step. There are hints that Arnold is using such a method in " Importance Sampling Techniques for Path Tracing in Participating Media", section 6.

Ok, thanks! Then I will just build it by myself.

@Brecht Van Lommel (brecht) I hope you will prioritize this in the future. Many people like me need to use Blender as a module for their research work. Anyways, I used gdb to get you the back trace after Python freezes. Here's what I get (I had to CTRL+C at the end):