Fixed modified branched connect to light functions

Did a simple test to see if branched path tracing is affected by this, and in fact it is, as can be seen in these images. Note that this test was CPU only, so this is a regression and not limited to the new device backend. The branched functions will need to be corrected, I haven't looked too deeply at it yet, but it looks like some lines from the original are missing from the new versions of these functions. I'll do a more thorough look thru and testing later.

Cleanup and address comments from @Omar Ahmad (OmarSquircleArt) - thanks

Just thinking aloud, this might be an opportunity for a small refactor of cycles: currently, Cycles builds the BVH before it uploads geometry vertices to the device. Most ray tracing APIs (DXR, OptiX, Embree) work the other way round. Before we introduce an OptiX specific workaround, should we change Cycles to do vertices first, BVH second? That would also help the Embree backend and potentially a future DXR/Vulkan backend when we see more vendors deliver ray tracing hardware.

Thank you for your reply,

@Omar Ahmad (OmarSquircleArt) I've kept the eul_to_mat4 the same as in maths_rotation.c. OSL uses mat4 so I've tried to keep all the code as consistent as possible.

Address comments from @Omar Ahmad (OmarSquircleArt)

We are lacking more information here:

Fixed performance regression that caused BMW benchmark scene to only be 1.1x faster instead of 1.6x

In D3789#124877, @Charlie Jolly (charlie) wrote:

This wouldn't work with the mapping node as this exposes rotation values as socket inputs.

This wouldn't work with the mapping node as this exposes rotation values as socket inputs.

I wounder if we can implement this using graph expansion. It would expand to two nodes I think, a Vector Math node and a Mapping node. I used expansion before and it was very nice and easy to use. Maybe you should give it a try. Check the following commit for reference rB7a7eadaf.

Other minor remarks.

@Omar Ahmad (OmarSquircleArt) Thanks. I'll address the comments. Some of that was probably due to copying code from another node.

I think you should take care of those remarks first.

Updated patch so it builds with master

Ok, got it now - first rendering needed about 4 minutes (in debug mode, against ca. 40 seconds without) and completed,
then 2nd try with render write still finished with a cuda error - seems to be something like an timing issue - btw rendering in GUI with only one GPU aktivated works fine.

strange.. starting "blender --debug-cycles" Blender disappears again and the last i saw in the console window was "CUDA ERROR".
Then i used
"blender --debug-cycles --python-expr "import bpy; bpy.ops.wm.sysinfo(filepath=r'%temp%\blender\debug_logs\blender_system_info.txt')" > "%temp%\blender\debug_logs\blender_debug_output.txt" 2>&1 < %0 "
rendered withou an error...
I will do further testing, in the meantime her are the logs.

@Brecht Van Lommel (brecht) might know more here? Not sure we have that kind of config here to test it though...

Since theseare so closely related, will merge this into T58569...

@Brecht Van Lommel (brecht): mind checking (on D5478)?, there is a tiny bit more info in T68359...

T58569 is the same thing really...

 - Fixed a compile error when building with Embree (thanks @Alex Fuller (mistaed))

• Fixed an OptiX warning during pipeline creation
• Reduced number of used attributes in OptiX pipeline to two

This does not need a build option or #ifdefs in some many places in the code as far as I can tell.

AFAIK newer Intel graphics after core 6th gen CPUs are capable of OpenGL 4.x. Yes on my machine who has a 4th gen core i7 mobile processor, blender will nor run unless it uses nvidia video card.

Please fill out the bug report form correctly.

I would also be interested in D2324 to get some love, @Sybren A. Stüvel (sybren): have you checked that?

@Kévin Dietrich (kevindietrich) Are you still working on this?

loading of the compiled kernels when not using parallel compilation

I had this posted a day or two ago but I didn't understand how phabricator's differential works. I've made a basic inline comment in bvh_embree.h in which the new function needs fixing to compile properly:

Seems to crash during viewport rendering will need more testing.