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.
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):
Some years ago, the normal texture coordinate was added to light shader to create gobos and other projection. Would it be possible to add kind of the same for world position? this would allow to create blocker or other “filter” we have on other engines that is very convenient for creative effects.
A request for Cycles renderer : Advanced SSS for movie, link An Advanced Path Tracing Architecture for Movie Rendering
As some characters to Grand Moff Tarkin from Rogue one (star wars) and Rachael (Blade runner 2049), they use great with Advanced SSS and that would be awesome if Cycles has it too
Perhaps the dev team need some math for this SSS advanced, some links may help them I hope :
Old but useful :
Towards Realistic Image Synthesis of Scattering Materials
Most recent :
Extending Separable Subsurface Scattering to Arbitrary Materials
A Learned Shape-Adaptive Subsurface Scattering Model
Hi, any chance of a seperate denoising albedo for volumes? All the other data in the current denoising albedo breaks multipass denoising.
Cycles already has that.
Which part of this are you referring to? Section 11.2 just described random walk SSS, Cycles has had that for a while.
Sorry if it already has that SSS and that is Ok. Good to know it.
I meant the realism with Cycles can have like the Renderman SSS for high realism in movie?
This is a bit old, but I think it can convince you about the quality that can be achieved, however a realistic model does not only depend on the SSS shader but on a correct use of the maps and the creation of these maps.
But check out on Blender artist.
And a shader Dermis: A Multi-Level SSS Principled Shader for Cycles - Blender Market
Incredible but true, I am convinced thank you for these links. Exactly it depends on the maps and the colors and especially the light how to have high degree realism too.
Isn’t that basically the same as to using an object’s position, while said object is just at the world origin?
no, not really, because either object texture coordinate or geometry position gives unique color value, which is not coordinates on which we can map texture.
Hello! I believe you can use the parametric output from the geometry input node to map textures on an area light (don’t know if it works with other types of light). You may have to tweak it a bit with vector math nodes or texture mapping node.
Maybe it’s not what you are looking for but hope it helps.
Cheers.