The shadow catcher is still there in the latest build of Cycles-X for me. It just appears that the shadow catcher in the viewport has stopped working? Maybe wait until the build bot of Cycles-X is next done and try it again?
2 Likes
I’ve looked into it. If the display was to update 60 times a second (60fps), then you can lose roughly 5% of the ray tracing performance when testing with my hardware (results vary based on hardware, scene configuration, and other factors. This is also an estimate). So, rendering a scene without display updates, you might be able to get 100 samples per second. With a display up every 60th of a second to get 60fps, you may only be able to do 95 samples per second.
The patch I have created is not that bad. It only updates every 10th of a second at the most (10fps) and that’s only for the first second of rendering. In that case, you should only lost about 1% performance at most, and only for the first second, the performance hit is reduced in the following seconds until it reaches a display update every 2 seconds which has very little impact on the ray tracing performance
It should be noted that display updates can change depending on a bunch of factors. I picked some of the bad values I saw in testing just to show off how bad it can get.
4 Likes
I did some tests, I don’t understand how to use some parameters like IOR and Subsurface anisotropic, but I am satisfied with the result that can be achieved with the Cycles SSS, congratulations.
test with 4 HDRI, white indoor, Studio, Night outdoor, and day outdoor
6 Likes
Hey,
I just watched the stream from sergey today.
And I thought for what do we need tiles?
I mean cycles x is without right? And woldn’t it be slower? And could you turn off tile rendering to render the whole frame like previously?
I was just wondering
What stream?
Tiled rendering is mainly for reducing memory usage for very large renders, I think. And it should be optional.
1 Like
After testing ‘custom’ Cycles X and working with path tracing in UE 4.27 switching to the default Cycles X was kind of painful in a way. Here is why: Cycles X has a feature that dynamically reduces ‘resolution’ of the viewport during ‘initial passes’ or when you are moving through the scene. But then (e.g. when you stop moving or adjusting something) the resolution progressively goes back to normal. This feature has unwanted consequence - it makes it really hard to understand and assess how the changes you make affecting and propagating through the scene.
Here is what it looks like in Cycles Master (2.93) with ‘start pixels’ set to 512:
And here is what it looks like in Cycles X (3.0):
As you can see - the difference between the picture during the ‘initial passes’ in Cycles X and the final picture a few seconds later is huge. In many cases this difference makes it even hard to understand whether you changed something or not.
A solution to this issue could be bringing back ‘Start Pixels’ and adding a switch (checkbox) called ‘Dynamic Scaling’. If true, Cycles X uses dynamic ‘resolution’ scaling (default Cycles X behavior). If false, Cycles X switches to the user defined ‘Start Pixels’ value (like in Cycles Master).
1 Like
Rather than having a start pixels value, maybe a start resolution divider or something similar, start pixel size? Navigation pixel size? That way you get values like 1 (full resolution), 2 (quarter resolution because area math), 4 (sixteenth resolution because area math), etc. Basically make it the same as the Pixel Size option we already have (it’s called Resolution in your image) but it only applies to the start of rendering.
And maybe in combination with this, the resolution should jump straight from navigation resolution to viewport rendering resolution when it starts refining. Because if you have slow hardware, it’s changing from something like sixteenth resolution, to quarter resolution, then to full resolution. All the resolutions between navigation resolution and full resolution can be argued to be “wasted processing” in a sense which isn’t great for slow hardware.
1 Like
But if I have encountered a Cycles crash that occurs constantly, do I have to report the problem or is this still not taken into consideration?
# Blender 3.0.0, Commit date: 2021-08-23 13:59, Hash 6ff8b06fe770
bpy.ops.wm.open_mainfile(filepath="/home/pafu/Documenti/blend_files/Candle-SSS-test.blend", load_ui=True, use_scripts=False, display_file_selector=False, state=2) # Operator
bpy.ops.wm.tool_set_by_id(name="builtin.select_box", cycle=False, space_type='IMAGE_EDITOR') # Operator
bpy.ops.wm.tool_set_by_id(name="builtin.select_box", cycle=False, space_type='VIEW_3D') # Operator
bpy.ops.wm.tool_set_by_id(name="builtin.select_box", cycle=False, space_type='NODE_EDITOR') # Operator
bpy.ops.view2d.pan(deltax=-183, deltay=40) # Operator
bpy.ops.view2d.zoom_out(zoomfacx=-0.0375, zoomfacy=-0.0375) # Operator
bpy.ops.view2d.zoom_out(zoomfacx=-0.0375, zoomfacy=-0.0375) # Operator
bpy.ops.view2d.zoom_out(zoomfacx=-0.0375, zoomfacy=-0.0375) # Operator
bpy.ops.view2d.zoom_out(zoomfacx=-0.0375, zoomfacy=-0.0375) # Operator
bpy.ops.view2d.zoom_out(zoomfacx=-0.0375, zoomfacy=-0.0375) # Operator
bpy.ops.view2d.zoom_out(zoomfacx=-0.0375, zoomfacy=-0.0375) # Operator
bpy.ops.view3d.select(deselect_all=True, location=(546, 324)) # Operator
bpy.ops.view2d.zoom_out(zoomfacx=-0.0375, zoomfacy=-0.0375) # Operator
bpy.ops.view2d.zoom_out(zoomfacx=-0.0375, zoomfacy=-0.0375) # Operator
bpy.ops.view2d.zoom_out(zoomfacx=-0.0375, zoomfacy=-0.0375) # Operator
bpy.ops.view2d.zoom_out(zoomfacx=-0.0375, zoomfacy=-0.0375) # Operator
bpy.ops.view2d.pan(deltax=-228, deltay=-35) # Operator
bpy.ops.view2d.pan(deltax=-46, deltay=34) # Operator
bpy.ops.view2d.zoom_in(zoomfacx=0.0375, zoomfacy=0.0375) # Operator
bpy.ops.view2d.zoom_in(zoomfacx=0.0375, zoomfacy=0.0375) # Operator
bpy.ops.view2d.zoom_in(zoomfacx=0.0375, zoomfacy=0.0375) # Operator
bpy.ops.view2d.pan(deltax=-47, deltay=25) # Operator
bpy.ops.node.select(wait_to_deselect_others=True, mouse_x=182, mouse_y=141, extend=False, deselect_all=True) # Operator
bpy.ops.node.select(wait_to_deselect_others=True, mouse_x=182, mouse_y=141, extend=False, deselect_all=True) # Operator
bpy.ops.node.link(detach=False, has_link_picked=False, drag_start=(-545.17, 200.959)) # Operator
bpy.ops.node.link(detach=False, has_link_picked=False, drag_start=(-545.17, 200.959)) # Operator
bpy.ops.node.select(wait_to_deselect_others=True, mouse_x=185, mouse_y=140, extend=False, deselect_all=True) # Operator
bpy.ops.node.select(wait_to_deselect_others=True, mouse_x=185, mouse_y=140, extend=False, deselect_all=True) # Operator
bpy.ops.node.link(detach=False, has_link_picked=False, drag_start=(-539.122, 198.941)) # Operator
bpy.ops.node.link(detach=False, has_link_picked=False, drag_start=(-539.122, 198.941)) # Operator
bpy.ops.node.select(wait_to_deselect_others=True, mouse_x=243, mouse_y=90, extend=False, deselect_all=True) # Operator
bpy.ops.node.select(wait_to_deselect_others=True, mouse_x=243, mouse_y=90, extend=False, deselect_all=True) # Operator
bpy.ops.view2d.pan(deltax=136, deltay=24) # Operator
bpy.ops.wm.tool_set_by_id(name="builtin.select_box", cycle=False, space_type='NODE_EDITOR') # Operator
bpy.context.space_data.shading.type = 'RENDERED' # Property
bpy.ops.view2d.zoom_in(zoomfacx=0.0375, zoomfacy=0.0375) # Operator
bpy.ops.view2d.zoom_in(zoomfacx=0.0375, zoomfacy=0.0375) # Operator
bpy.ops.view2d.zoom_in(zoomfacx=0.0375, zoomfacy=0.0375) # Operator
bpy.ops.view2d.pan(deltax=-89, deltay=-40) # Operator
# backtrace
./blender(BLI_system_backtrace+0x20) [0xac15860]
./blender() [0x100869b]
/lib/x86_64-linux-gnu/libc.so.6(+0x3f040) [0x7f5961eeb040]
./blender(_ZN3ccl43kernel_cpu_avx2_integrator_init_from_cameraEPKNS_13KernelGlobalsEPNS_15IntegratorStateEPNS_14KernelWorkTileEPf+0x32bb) [0x2c5cbbb]
./blender(_ZN3ccl16PathTraceWorkCPU28render_samples_full_pipelineEPNS_13KernelGlobalsERKNS_14KernelWorkTileEi+0xfa) [0x2e8b03a]
./blender() [0x2e8b525]
./blender() [0x13e5415]
./blender() [0x13e56cb]
./blender() [0x13d42c7]
./blender() [0x13df100]
./blender() [0x13e113c]
./blender() [0x13e1339]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x76db) [0x7f59636306db]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7f5961fcd71f]
# Python backtraceDo you have an example blend file for the crash or stepts to reproduce? You can just answer here, we do not accept Cycles X bugs in the bug tracker yet.
Here is the blend (Candle-SSS-test.blend) file and to reproduce the crashes With view port mode in preview rendering, when I move the sliders of the flame color ramp to one side or the other Blender crashes
Hi, I started testing the SSS shader, I made a quick test just comparing Random Walk, and random Walk Fixed Radius with exact same values except a scale difference of 0.1 on the radius scale:
As you can They are reasonably comparable. Is that expected or there is an inconsistency bug in the scale?
If I use same exact values the Random Walk seem to scatter light less far than Random Walk fixed radius:
To complete the test, here is the same meshes rendered in Master 2.93.3:
The behavior looks similar or identical to Cycles X Random Walk Fixed Radius.
Random Walk Fixed Radius should be close to, if not identical to Random Walk in Master.
As for commenting on the rest of your comment. I do not know enough to answer.
There was a comment made earlier in this discussion that might help but I’m not sure: Cycles-X feedback - #502 by Enzo-Roa
Thanks! If you are referring to this:
I don’t know If Albedo inversion is related to this.
I think I’m just experiencing the same issue that @Eary is having with the new Random Walk Implementation, i mean this:
to be precise, I believe that difference the scale factor is 10 and not 15.
For example this post still doesn’t explain the difference, to be honest Just confirms that there is a scale problem with the new Random Walk:
I did another test, this time with orthographic view and a directional light perpendicular to the objects, so we are sure that they are equally lit. I used a driver to sync the radius main input in both RWSR and RW, and put a multiplication by 10 node on the RW, then increased the radius. they look identical to me as long as the RW has 10 times the radius of the RWSR radius. If this is the case, it looks like a scale bug to me:
Experiment Setup:
Just to clarify:
I’m aware that so far in master, the Subsurface slider scales both the radius of the sss and the mix with the albedo simultaneously, that’s why I made the tests using only SSS (albedo black, and subsurface slider set to 1), and changing just one variable (the radius multiplier implemented with math nodes).
Honestly I think that the subsurface factor should only affect the color mix with the albedo, and the scale of the radius should be a separated slider, unless the current solution is designed like this for energy conservation reasons that I’m not aware of. Infact I often just use the sss at 1 and scale the radius with nodes as in this example for convenience.
When I talk about changing the scale, I’m not talking about not using real world units, but just converting in centimeters for convenience (so I can easlily input 1 for 1cm and precisely control the slider). I always use real world scale models to make sure the sss is consistent.
I’m getting crashes with CyclesX Optix on the ODIN execution after the rendering. CyclesX CPU on the same frame denoises fine. RTX 3090, frames are 5442x3628. No problems on 1920x1080 frames with OptiX.It doesn’t make sense because ODIN is pure CPU based but it gets the renderpasses from the rendering device so.
Can confirm the crash on Windows.
@brecht Stacktrace in case it’s useful.:
blender.exe :0x00007FF7DBAF6010 ccl::kernel_need_sample_pixel
blender.exe :0x00007FF7DBAAA140 ccl::integrator_init_from_camera
blender.exe :0x00007FF7DBAF4BE0 ccl::kernel_cpu_avx2_integrator_init_from_camera
blender.exe :0x00007FF7DC07C790 ccl::CPUKernelFunction<bool (__cdecl*)(ccl::KernelGlobals const * __ptr64,ccl::IntegratorState * __
blender.exe :0x00007FF7DC0843A0 ccl::PathTraceWorkCPU::render_samples_full_pipeline
blender.exe :0x00007FF7DC081240 <lambda_24c44d21903d6e59f90bf28d5cb6fde6>::operator()
blender.exe :0x00007FF7DC081F30 tbb::internal::parallel_for_body<<lambda_24c44d21903d6e59f90bf28d5cb6fde6>,__int64>::operator()
blender.exe :0x00007FF7DC084F60 tbb::interface9::internal::start_for<tbb::blocked_range<__int64>,tbb::internal::parallel_for_body<<
blender.exe :0x00007FF7DC07E820 tbb::interface9::internal::dynamic_grainsize_mode<tbb::interface9::internal::adaptive_mode<tbb::int
blender.exe :0x00007FF7DC07D3F0 tbb::interface9::internal::partition_type_base<tbb::interface9::internal::auto_partition_type>::exe
blender.exe :0x00007FF7DC083450 tbb::interface9::internal::start_for<tbb::blocked_range<__int64>,tbb::internal::parallel_for_body<<
tbb_debug.dll :0x00007FFA3636213F tbb::internal::concurrent_queue_base::~concurrent_queue_base
tbb_debug.dll :0x00007FFA3636213F tbb::internal::concurrent_queue_base::~concurrent_queue_base
tbb_debug.dll :0x00007FFA3636213F tbb::internal::concurrent_queue_base::~concurrent_queue_base
tbb_debug.dll :0x00007FFA3636213F tbb::internal::concurrent_queue_base::~concurrent_queue_base
tbb_debug.dll :0x00007FFA3636213F tbb::internal::concurrent_queue_base::~concurrent_queue_base
tbb_debug.dll :0x00007FFA3636213F tbb::internal::concurrent_queue_base::~concurrent_queue_base
ucrtbased.dll :0x00007FFA07C64B90 register_onexit_function
KERNEL32.DLL :0x00007FFA8AE97020 BaseThreadInitThunk
ntdll.dll :0x00007FFA8B922630 RtlUserThreadStart
1 Like
To be exact I’m getting this CyclesX crash, not whole BLender:
Invalid value in cuMemcpyDtoH_v2( (char *)mem.host_pointer + offset, (CUdeviceptr)mem.device_pointer + offset, size) (C:\Users\blender\git\blender-vexp\blender.git\intern\cycles\device\cuda\device_impl.cpp:852)
1 Like
This crash should be fixed in the next build.
4 Likes
I couldn’t reproduce a crash rendering an 5442x3628 image with OptiX + OpenImageDenoise. The error message does not say much. The full log when running with --debug-cycles might say more.
It may be running out of memory with the extra passes needed for denoising. If that’s the case then tiled rendering will help.
For SSS, I’ve changed the radius now so it’s more similar between the two modes:
https://developer.blender.org/rB0af1203f5df5e8a321ae3d175dffc3f36a08112b
It’s never going to be exact because the radius depends on the subsurface color also, so depending if you choose a darker or bright color it can still be different.
1 Like