You won’t be able to implement anything using the halfway vector in non-closure node. H is only defined when you have both ingoing and outgoing vectors. At the time the shader graph is evaluated, only the view direction is known, but not the light or reflection directions. Only after the shader graph is flattened to closures, Cycles goes into light and BSDF sampling and knows the second vector.
For calculating a half-way vector you need a light direction vector, but currently there’s no node that provides it. Light direction is freely available in Cycles code tho. If you want to stick only to existing shader nodes, you can try to make a trickery trick and get a cos(L, H) from comparing a principled diffuse with roughness=0 and roughness=1. For more information check out function calculate_principled_diffuse_brdf() in bsdf_principled_diffuse.h
1 Like
Well since I am extremely unfamiliar with cycles code, I guess my new suggestion is to add the light vector to the light path node. Thanks for the help though:)
Can you also define L and H for me, thanks.
I do wish to see some speed and memory improvements around this particular issue. We have similar problems around setting up scene optimized plants, hair cards etc with Cycles.
1 Like
L - a unit vector from the point of incidence to a light source
V - a unit vector from the point of incidence to the camera
H = normalize(L+V) - the half-way vector from your question
2 Likes
Hey guys,
Do we have any info on when and how light passes are going to be implemented as render passes,
Even just separating GI and others light is a great start. As a VFX artist, it’s literally the only thing left in blender to make it production-ready for medium-sized VFX Shops. Would love to hear the current limitations and time frame for this.
2 Likes
Is that possible to give a documentation for cycles source code, I try to read the source code but it is quite difficult for me.
1 Like
Hi,
There is some documentation here. I will also be working on improving it soon so if there is anything you think needs work first, please let me know.
Regards,
William
Multiscatter GGX needs to be fixed. For some reason when roughness is around 0.02, the something wierd happens to the highlights
Not sure if this is the right section, if not, please feel free to move my post somewhere else.
When I update the textures in an existing node setup, all the previous color space settings get always reset to sRGB. Other than adding time to the process, as I have to manually fix each node, sometimes it also leads to mistakes, either because I forget to change one node, or because I clicked on the color space drop-down menu and maybe picked the wrong color space by error.
Is there a way to keep the color space in the nodes as they are when replacing the texture?
1 Like
Here you have a build with Light Groups, also I just applied a patch from @KevinDietrich to be able to import arbitrary attributes for alembic caches, patches are still WIP so they can have bugs, the same with Light Groups, patch by @boberfly 
2 Likes
I think you should create a bug for this. Use the report a bug from the help menu and fill in the details.
Makes sense, I will 
I do get crashes with Cycles if the viewport render preview is enabled, but this issue reveals itself more often with heavier scenes. I will try to file a bug before doing I would like to know if anyone else has this issue.
I am using Blender 3.0 bd734cc4419a RTX 2070 Super, Win10
Stack trace:
blender.exe :0x00007FF7124CD620 ccl::device_memory::is_resident
blender.exe :0x00007FF7124BE6A0 ccl::CUDADevice::move_textures_to_host
blender.exe :0x00007FF7124BD120 ccl::CUDADevice::generic_alloc
blender.exe :0x00007FF7124BE3D0 ccl::CUDADevice::mem_copy_to
blender.exe :0x00007FF712797F30 ccl::GeometryManager::device_update_attributes
blender.exe :0x00007FF712796680 ccl::GeometryManager::device_update
blender.exe :0x00007FF71275E950 ccl::Scene::device_update
blender.exe :0x00007FF7127628B0 ccl::Scene::update
blender.exe :0x00007FF7128B66F0 ccl::Session::run_update_for_next_iteration
blender.exe :0x00007FF7128B6190 ccl::Session::run_main_render_loop
blender.exe :0x00007FF7128B5DC0 ccl::Session::run
blender.exe :0x00007FF715785C10 ccl::thread::run
blender.exe :0x00007FF7121A1350 std::thread::_Invoke<std::tuple<void * __ptr64 (__cdecl*)(void * __ptr64),ccl::thread * __ptr64>,0,
ucrtbase.dll :0x00007FFC5D931430 configthreadlocale
KERNEL32.DLL :0x00007FFC5FB87020 BaseThreadInitThunk
ntdll.dll :0x00007FFC5FCBCEA0 RtlUserThreadStart
Threads:
Thread : 0000380c
ntdll.dll :0x00007FFC5FD0C410 ZwDelayExecution
Thread : 00003d44
ntdll.dll :0x00007FFC5FD0BE10 ZwWaitForSingleObject
KERNELBASE.dll :0x00007FFC5D632660 WaitForSingleObjectEx
blender.exe :0x00007FF7160AA920 IlmThread_2_5::Semaphore::wait
blender.exe :0x00007FF7160AA0F0 IlmThread_2_5::ThreadPool::numThreads
blender.exe :0x00007FF7160AAD90 std::_LaunchPad<std::unique_ptr<std::tuple<void (__cdecl IlmThread_2_5::Thread::*)(void) __ptr64,Il
blender.exe :0x00007FF7141EA360 std::_Pad::_Call_func
ucrtbase.dll :0x00007FFC5D931430 configthreadlocale
KERNEL32.DLL :0x00007FFC5FB87020 BaseThreadInitThunk
ntdll.dll :0x00007FFC5FCBCEA0 RtlUserThreadStart
112 16:57:12.756543 22900 device_impl.cpp:711] Buffer allocate: __tex_image_byte4_070, 16,777,216 bytes. (16.00M) in device memory
I1112 16:57:12.771504 21852 device_impl.cpp:711] Buffer allocate: __tex_image_byte4_031, 62,685,184 bytes. (59.78M) in device memory
I1112 16:57:12.863770 22616 device_impl.cpp:711] Buffer allocate: __tex_image_byte4_062, 67,108,864 bytes. (64.00M) in device memory
I1112 16:57:12.950537 7628 device_impl.cpp:711] Buffer allocate: __tex_image_byte_071, 4,194,304 bytes. (4.00M) in device memory
I1112 16:57:12.956521 5832 device_impl.cpp:711] Buffer allocate: __tex_image_byte4_067, 67,108,864 bytes. (64.00M) in device memory
I1112 16:57:12.956521 9032 device_impl.cpp:711] Buffer allocate: __attributes_map, 13,984 bytes. (13.66K) in device memory
I1112 16:57:12.977465 9032 device_impl.cpp:711] Buffer allocate: __attributes_float, 16,388,088 bytes. (15.63M) in device memory
I1112 16:57:12.994418 9032 device_impl.cpp:711] Buffer allocate: __attributes_float2, 42,941,088 bytes. (40.95M) in device memory
I1112 16:57:13.020856 11736 device_impl.cpp:711] Buffer allocate: __tex_image_byte4_069, 67,108,864 bytes. (64.00M) in device memory
I1112 16:57:13.020856 9032 device_impl.cpp:711] Buffer allocate: __attributes_float3, 84,630,464 bytes. (80.71M) in device memory
I1112 16:57:13.108623 18056 device_impl.cpp:711] Buffer allocate: __tex_image_byte4_042, 67,108,864 bytes. (64.00M) in device memory
I1112 16:57:13.143528 9032 device_impl.cpp:711] Buffer allocate: __attributes_uchar4, 3,438,360 bytes. (3.28M) in device memory
I1112 16:57:13.154497 9032 device_impl.cpp:711] Buffer allocate: __objects, 16,679,520 bytes. (15.91M) in device memory
I1112 16:57:13.155495 3928 device_impl.cpp:711] Buffer allocate: __tex_image_byte4_072, 67,108,864 bytes. (64.00M) in device memory
I1112 16:57:13.197383 3672 device_impl.cpp:711] Buffer allocate: __tex_image_byte4_073, 67,108,864 bytes. (64.00M) in device memory
I1112 16:57:13.214841 16096 device_impl.cpp:711] Buffer allocate: __tex_image_byte4_084, 67,108,864 bytes. (64.00M) in device memory
I1112 16:57:13.232793 22900 device_impl.cpp:711] Buffer allocate: __tex_image_byte4_075, 16,777,216 bytes. (16.00M) in device memory
I1112 16:57:13.246757 9384 device_impl.cpp:711] Buffer allocate: __tex_image_byte4_074, 16,777,216 bytes. (16.00M) in device memory
I1112 16:57:13.258726 21852 device_impl.cpp:711] Buffer allocate: __tex_image_ushort4_076, 33,554,432 bytes. (32.00M) in device memory
I1112 16:57:13.273685 22616 device_impl.cpp:711] Buffer allocate: __tex_image_byte_077, 4,194,304 bytes. (4.00M) in device memory
I1112 16:57:13.275681 5832 device_impl.cpp:711] Buffer allocate: __tex_image_byte4_079, 16,777,216 bytes. (16.00M) in device memory
I1112 16:57:13.305599 7628 device_impl.cpp:711] Buffer allocate: __tex_image_byte4_078, 67,108,864 bytes. (64.00M) in device memory
I1112 16:57:13.345492 9032 device_impl.cpp:711] Buffer allocate: __attributes_map, 13,984 bytes. (13.66K) in device memory
I1112 16:57:13.346489 9032 device_impl.cpp:711] Buffer allocate: __attributes_float, 16,388,088 bytes. (15.63M) in device memory
Error : EXCEPTION_ACCESS_VIOLATION
Address : 0x00007FF7124CD631
Module : blender.exe
Thread : 00002348
crash.txt (64.5 KB)
Yeah, the temperature is not promotet on object level, but you could use this light node: Blackbody Node — Blender Manual
Speaking of the blackbody node, it’s also worth mentioning that this node is currently just an RGB approximation of the blackbody emission, which means it is not accurate. A real physically accurate blackbody node would need to wait for Spectral Cycles to come, though there will probably be some design decision debate when the time comes.
5 Likes
Roughness-aware Fresnel node would be great addition. This would allow to create coatings-over-translucent or other rough multilayered coated materials. I’m not aware of current workaround for this except this nodegroup that works only for GGX:
However @angavrilov, author of this nodegroup made patch for fresnel node to use it as reference. it’s available here:
This is similar proposal from rightclickselect (not mine):
3 Likes