Cycles feedback

[slowburn]

What stream?
Tiled rendering is mainly for reducing memory usage for very large renders, I think. And it should be optional.

[JohnDow]

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).

[Alaska]

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.

[PaoloFurani]

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 backtrace

[ThomasDinges]

Do 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.

[PaoloFurani]

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

[RiccardoBancone]

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.

[Alaska]

@RiccardoBancone

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 feedback - #502 by Enzo-Roa

[RiccardoBancone]

Thanks! If you are referring to this:

@Enzo-Roa

This tutorial can help a lot. In short you don’t need a map to modulate the sss scale or sss radius, you just have to choose a good value for both and the albedo inversion takes care of the rest.

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:

@Eary

I need to multiply the radius by about 15 to achieve the previous result, it is almost like the unit of the radius distance is changed to a smaller unit so the numbers need to be larger to maintain the same actual value.

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:

@Enzo-Roa

I hope you can understand me.
For all your sss materials (randomwal = “RW” or randomwalk fixed radius = “RWFR”) you still need to set sss radius and sss scale. The sss scale should be set based on what your eye feels looks good, for the RGB radius you can look up some values ​​on the internet, control it artistically or use your base color(for some materials). For skin I use (0.37, 0.14, 0.07) in the sss radius (based on Arnold wiki). The main difference(artistically) between the two methods (RW and RWFR) is what happens when you increase the scale value. For example:

As you can see in the image when I increase my sss scale from 0.02 to 0.04 and 0.06 in RW, the sss appearance in general does not increase linearly over the entire surface (this happens because there is something modulating my radius)and it can become a little less intuitive. Clarifying: In the pricipledbsdf node the sss slider control the mix between base color and at the same time it’s use to scale RGB radius,
RGB radius are distance units and sss IOR is only used by RW from my understand

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.

[vangel]

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.

[ThomasDinges]

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

[vangel]

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)

[brecht]

@PaoloFurani

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

This crash should be fixed in the next build.

[brecht]

@vangel

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)

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.

[brecht]

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.

[RiccardoBancone]

Thanks @brecht ! I’ll test that ASAP!

[JohnDow]

You might find it interesting: Real-time neural radiance caching for path tracing

[BD3D]

Hey Cycles folks

Old cycles had a really annoying update problem
when we change properties that did have absolutely no impact on the scene,
cycles kept being refreshed

Not sure why cycles think it needs to refresh if the scene has not been affected at first place

Can someone confirm this is still an issue in Cycles X?

#Creating a simple prop, that do not do anything but keep refreshing cycles for some reasons
import bpy 
bpy.types.Object.iticklecycles = bpy.props.BoolProperty()
bpy.context.object.iticklecycles = True

[JohnDow]

‘iticklecycles’ does tickle Cycles X and triggers update.

[Eary]

@brecht

For SSS, I’ve changed the radius now so it’s more similar between the two modes:

Just tried it out, the default sss color of RGB [0.8, 0.8, 0.8] does look similar now.

@brecht

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.

Yeah I know this know this is probably by design, but how different it is when using a color other than the 0.8 triplet, just feel so strange to me: