Just updated the build. And this unpredictable problem seems to be gone! And the average render time is now roughly the same as the master on my side! (for those don’t know, I am using MX130 GPU, which is kind of the lower end, and Cycles X had been slower than master on my machine until now).
cycles-x - a65dff3d21c3
Gives odd white glitches and overexposure, ghosting. GPU mode ofc. CPU doesn’t produce such issues.
It happens if you render even same frame 3-6 times. even at the smallest resolutions and simplest scenes like cube + light + camera
Do you have Persistent Data enabled?
No, Persistent Data is disabled
Persistent Data also seems to be causing me loads of issues with layers rendering on top of one another. Was wondering why my renders weren’t working until I found this page. Turning off persistent data fixed this issue you describe for me. Thanks guys!!
Correction, I just realized i’m still having this issue after disabling persistent data.
I’m rendering an animation 5 cameras in multi-view. The first two cameras render perfect, but but the 3rd+ render with other previous layers showing the background. However, the first two cameras still render the output fine in the animation.
Okay so to recap:
Disabling persistent data fixes the multi-layering of different renders in Animations but not in multi-camera view.
Changing spatial splits, BVH time steps, and use hair BVH do not make a difference.
Are you sure about that?
Hi, for Linux yes but it seams latest build for Windows is 6 days old. 
I forgot where I got this information but I guess it was from maillist.
Cheers, mib
1 Like
I’ve tried building the cycles-x branch for windows using the on-site builder but it failed. When I checked the recent builds, I saw two more failed attempts to build the same version. All of those have the same ‘error’:
> ------------------------------------------------------------
>
> Error summary - [compile-code]
>
> ------------------------------------------------------------
>
> FAILED: source/blender/bmesh/CMakeFiles/bf_bmesh.dir/intern/bmesh_mesh_tessellate.c.obj
>
> C:\Users\blender\git\blender-vexp\blender.git\source\blender\bmesh\intern\bmesh_mesh_tessellate.c(158): error C2220: the following warning is treated as an error
>
> ninja: build stopped: subcommand failed.
>
> Command [pipenv] with arguments [run python C:\Users\blender\git\bdr-devops-core\cmd\build/worker/worker_compile.py -track-id vexp -branch cycles-x -build-configuration release -config-file-path C:\Users\blender\git\blender-vexp\blender.git\build_files\config\pipeline_config.json -needs-ninja] failed with exit code [1]
stdio.txt (249.5 KB)
I guess this is the reason why windows build hasn’t been updated yet.
Please fix the Windows branch, seams like the new bmesh_mesh_tessellate broke something
The Windows build problem might get fixed as soon as they update Cycles X to the latest revision of master (which it is not yet to the point of that happening on a regular basis).
As frustrating as it may be for Windows users to (seemingly) get sent to the back of the bus again, the devs. technically are not obligated to do anything until they open the bug tracker for reports…
1 Like
Just tested the latest builds a959da981785 and ce865d3f721f:
Some additional notes: Denoising during render works fine (both OptiX and OIDN), but the viewport denoising is kind of broken for me. OptiX crashes Blender, while OIDN make the scene overexposed if you have ‘adaptive sampling’ enabled, but works great without it. One more thing that I’ve noticed in the last few builds: I’ve experienced huge performance drop with enabled denoising when I had the ‘world’ in the viewport. When you ‘look’ at the scene geometry/models, performance is great. But when you have the world (empty space around your scene / HDRI) in the viewport - performance goes down like crazy. In other words: Viewport performance w. denoising is great only when the ‘world’ obscured by geometry.
2 Likes
With last version on WIndows 10 / RTX 3070: Have very overexposed scene with ODIN, but no crashes with OptiX or ODIN. Adaptive sampling with ODIN is the culpit, which is very sad because using it normally cuts 20-35% off my renders.
1 Like
With Jun 22 Win version now ODIN always leads to massively overexposed renders even without adaptive sampling.
1 Like
Latest Jun 23 update, ODIN still overexposed with adaptive sampling but the issues gone when unchecking adaptive sampling, using denoiser from compositor giving bad quality image but there is no issues when using denoiser from render properties. Viewport Optix denoiser crashing blender when using 1 start sample, but the issues gone when using 2 start sample or above.
Hi, as there was no commit for a week and the developer don´t fix bugs at this stage it does not make sense to post this over and over.
To get informed what happen in the branch register to the BF-commiters mail list.
You get OIDN to work with a regular compositor node set.
Cheers, mib
Recently we’ve had a small discussion about the shadow catcher in Cycles-X over in the “Let’s (finally) fix the ShadowCatcher” thread and we have some feedback for it.
At the moment it’s really difficult to use the shadow catcher to add CG objects to real life reflections and probably refractions. This is because you’re replacing pixels from real world footage with pixels from your CG scene via multiplication in the compositor. As such, the values in the shadow catcher pass can get quite “extreme”. The issue with this is that if your shadow catcher object is even just a little bit different from the real world, the values produced in the shadow catcher pass end up quite a way off from what they’re supposed to be. And as a result, the final result after compositing the shadow catcher into your scene can have very noticeable artifacts.
Take for example this scene:
There’s a reflective surface. and a background reflected in that surface. I now wish to add a red sphere to the scene. Adding the sphere is easy, but adding the reflections with the shadow catcher can be difficult. This is the expected result:
And these are bad results produced by the shadow catcher simply by having the shadow catcher object representing the water be slightly different from the “real world water”:
In our discussion over on the shadow catcher thread I came to the conclusion that having glossy reflections (and probably refractions) included in a render pass the user can just alpha over the real life footage would probably be best as it resolves the major issues we have with the shadow catcher.
However, I’m not entirely sure how feasible that approach is in terms of performance or whether or not it will continue to produce accurate results. Maybe there’s some other way to setup it up?
That is beyond what the shadow catcher was designed to do, though it would be a good improvement to try to support this.
Currently, it compensates for differences at the first bounce. To composite this kind of reflection in general you’d need to do an alpha over after the first bounce. That can work for surfaces that are 100% reflective/refractive and sharp, and would not work so well for darker/colored surfaces with roughness. There’s a continuum here.
A separate reflection pass may be good to support as well, though again with global illumination there’s a continuum between shadows and reflections, they’re not categorized so easily.
2 Likes
Having used other rendering systems, the shadowcatcher pass is usually split into several elements instead of a all-in-one solution like the current combined pass.
That way it is much easier to multiply and combine the shadow element with an exisiting shadow in the plate and then add the light/reflection/caustics layer on top.
I hope this can be added at some point.
5 Likes