Cycles Requests

Maybe I’m stupid, but it looks like the principled BSDF uses the half-way vector to calculate its theta i term for its fresnel. Meaning its fresnel falloff looks attucurate at roughnesses above 0.

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

I believe you’re talking about this kind of feature: ⚙ D12871 Cycles: Light Groups

Multiscatter GGX needs to be fixed. For some reason when roughness is around 0.02, the something wierd happens to the highlights
Imgur
Imgur

You should report a bug
image

1 Like

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?

@ReubenT

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 :slight_smile:

1 Like

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 :+1:

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.

3 Likes