I disagree with that. From what I have heard, when 2.81 came out, most people around me was celebrating now they can show their client a lower sampled but still clean render for their preview, and therefore it saves time for many of us.
5 Likes
Talkin about OIDN, I have a scene with foliage where the darken is much worse than in this example. But the setup is the same.
the .blend file below
https://drive.google.com/file/d/1U3_TjSgbCAvUVXKPuIV4S3WR3MgPypKX/view?usp=sharing
I can confirm it only happens in Cycles X
I put it in simple words: before you have an option to choose AI denoising (which has better results in low sample rendering) and NLM denoising (which has better results in final rendering).
Without NLM you have a one option less. It’s not a progress if we abandon feature which gives better results - you can’t deny it if you look and examples posted by my and others.
If NLM restoring is not so problematic it should be back. If OIDN surpass in future NLM in all cases (performance and preserving details) then no one would have a doubts.
@brecht Hello Brecht, i was wondering if there is a specific reason to implement delta tracking for volume rendering instead of decomposition tracking as demonstrated in this paper? It results in a better picture and requires substantially less lookups then delta tracking does.
1 Like
@brecht Some one had posted this in Right Click Select … u guys have probably come across it
Specular Manifold Sampling for Rendering High-Frequency Caustics and Glints
Does the barbershop scene have volumetrics enabled in master? Think it should also be removed to be a fair comparison.
Otherwise if it was removed, that speedup is extreme. from 109 seconds per frame to 15. That’s more than 7 times faster.
Really very good job. Also getting rid of tiles is welcome. Cycles is getting real stronk.
1 Like
Just for a feedback to let you know about other GPUS, I think even the bad GPUS benefit so much from cycles X.
In my case, GTX960m was almost 4 times faster for my personal scene .
Also, last improvements since 23 April , made 6-7 seconds improvement on my GTX960m, which is low but at least its nice to see it still improves even little on bad GPUs.
Cycles: 9:40 min
CyclesX-23April:2:40
CyclesX-5May: 2:33 min
(For CUDA)
1 Like
I’m referring to a class of algorithms more than a specific one. “A null-scattering path integral formulation of light transport” and “Product Importance Sampling of the Volume Rendering Equation using Virtual Density Segments” improve on the paper you linked, those are the ones I’m looking at most closely.
They were removed from the test scene, we check render output to ensure it’s comparable.
4 Likes
BUG: Getting flickering lights in animations rendered with Optix with persistent data turned on over batch render. The first frame is good, all subsequent frames miss all lights., only background HDRI + light from it works. Animations rendered from Blender UI with persistend data works good.
Please could we have AO, bevel nodes and Volumes rendering working as fast as possible? I’m using CyclesX now for production (it ain’t crazy if it works) and those three features of the 2.92 Cycles would make me use CyclesX 100% over Cycles in 2.92/3.
hey @brecht and @sergey, I’m pretty sure you already know this paper but, just in case: https://cs.dartmouth.edu/~wjarosz/publications/bitterli20spatiotemporal.html
For efficient direct sampling of many (maaany) lights, as far as I understand.
1 Like
AO and bevel will be back soon, volumes will take a while since we are implementing them differently.
Check the limitations section, it only works for a single bounce of light. A method like " Bayesian online regression for adaptive direct illumination sampling" would be more practical.
1 Like
Different topic I think, you can take a look at these threads:
3 Likes
I have updated my test results with some new entries…
3600X / 1660GTX (466.11) / 100 Samples / OIDN / 1920x1080
GPU only (time in seconds:):
E-Cycles (2.92) / Tiles x240A / CUDA: 54.15
E-Cycles (2.92) / Tiles x240A / OptiX: 49.05
Cycles (2.92) / Tiles x240 / CUDA: 62.75
Cycles (2.92) / Tiles x240 / OptiX: 50.76
Cycles (2.93) (96abe5ebbc55) / Tiles x240 / CUDA: 61.96
Cycles (2.93) (96abe5ebbc55) / Tiles x240 / OptiX: 49.39
Cycles (3.0) (d08cc63e2f98) / Tiles x240 / CUDA: 61.96
Cycles (3.0) (d08cc63e2f98) / Tiles x240 / OptiX: 49.56
Cyclex X (1dea1d93d39a) CUDA: 31.64
Cyclex X (1dea1d93d39a) OptiX: 32.60
Cyclex X (43789b764d9a) CUDA: 28.81
Cyclex X (43789b764d9a) OptiX: 29.98
Cyclex X (a176118b287f) CUDA: 24.31
Cyclex X (a176118b287f) OptiX: 25.12
Cyclex X (c77529091f8d) CUDA: 24.32
Cyclex X (c77529091f8d) OptiX: 24.80
GPU results (chart):
5 Likes
@brecht and @sergey Not sure if this is the place bug reports should be made for the cycles-x branch, but I noticed something about the initial implementation of the new shadow catcher (https://developer.blender.org/rBc77529091f8d658f7bf5590d136a2c19c3c02559)
When a object with an emission material is added to the scene, it can produce some “weird” results with the shadow catcher. Here’s a split screen showing the difference between what the shadow catcher produces (left) and what the result should look like (right):
Here’s the .blend file: https://drive.google.com/file/d/1RgTqr7dwM0QJwM_diF8iu9jVvHKxhMoS/view?usp=sharing
It’s possible I just got something wrong or there’s a issue with my build of Blender (as I built the Cycles-X branch myself). But if it isn’t, I hope this information helps.
It also seems like the shadow catcher is darker than expected with the objects with emissive materials? Maybe the shadows from emmisive surfaces are behaving like “negative” lights. And that could cause the darkering and the purple tint? Not sure.
We’re aware mesh emission has issues still with the shadow catcher, it’s currently handled partially as a real object already in the footage and partially as synthetic object. It needs to be one or the other based on the shadow catcher setting.
Light objects are currently always assumed to be real objects, but maybe will also need a way to be marked as synthetic.
The issue with emissive meshes should be fixed now.
4 Likes
Both are needed:
Case A: A footage of a night street with street lamps. The street lamps are present in the footage already and their illumination on the objects in the footage is already baked in the footage. Placing stand in lights for those lapms is still necessary, so that they illuminate the new CG objects added to the scene. They will add their light contribution to just the synthetic, added objects and make the areas of the shadow catcher block out geometry darker to generate shadows. So their contribution to the shadow catcher blockout geometry will be subtractive, but they will add no light energy to shadow catcher blockout geometry.
Case B: A footage of a night street where a synthetic CG car is driving thought it with headlights on. Unlike the case A, here the headlights need to add their light energy both on the other synthetic CG objects as well as shadow catcher blockout geometry. Unlike case A, their shadow contribution on the shadow catcher blockout geometry is not subtractive, but only occludes the additive part of the light, making the color in the shadows unchanged compared to original.
1 Like
The new shadow catcher is already much better then the previous but I hope the new system also allows for seperate shadow, glossy and illumination passes. The combined pass will not work in some cases.
1 Like
Testing with a new build of Cycles-X it seems to be fixed, thank you. But another bug I didn’t notice before still remains.
EDIT: THIS IS A NON-ISSUE. THE SCENE I WAS USING WASN’T SETUP PROPERLY.
If the light emitting mesh is set to be a shadow catcher, then the shadow catcher produces weird results:
Here’s a .blend file:
I’m not sure how this should technically work, but I personally believe that a light emitting mesh should behave like other light objects in Blender when it has the “shadow catcher” option enabled. That is it’s contribution to the scene should only be through lighting up CG objects and indirect light on the shadow catcher.