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.
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.
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.
Different topic I think, you can take a look at these threads:
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):
@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.
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.
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.
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.
You have to disable camera ray visibility if you want it to behave like a light. But that’s not something you want for all shadow catcher objects. Other than that it looks correct to me?
Yes, sorry, the render results is correct. I forgot some stuff to do with colour math and the test in the blend file wasn’t a proper test.
I tested it again today after updating the build. I give up. Now I am more inclined to believe that Cycles X is just not optimized for my lower end GPU (MX130), I hope it will be at some point, but for now I give up.
Here is my test, because of previous feedback about the light bounces not high enough, I changed all in Light Path settings to 128. I render twice for each (Var. 1 and Var. 2), the results for the two times are close, so I am only uploading the faster of the two
Another “bug” I’ve found and was wonder if anyone else was experiencing was this:
When OptiX denoising is enabled in the viewport and the input paths are set to “Color+Albedo+Normal” and you look at the sun in the “Sky texture” node attached to the world shader, it produces a black square.
This also occurs if you have a object that is exceptionally bright (E.G. an emission shader set to strength of 100000). The OptiX denoiser in the viewport also seems to have other artifacts with the input path set to “Color+Albedo+Normal” . This is all in comparison to Blender master. Here’s a few screenshots:
Note: I thought this was a bug with my builds of Blender. But it also affects the build from https://builder.blender.org/download/branches/ so it’s not just my build of the Cycles-X branch. Blender master also does not have any issues. Both the Cycles-X branch and master builds done by myself used OptiX 7.2.
Operating system: Linux-5.10.0-6-amd64-x86_64-with-glibc2.31 64 Bits
Graphics card: NVIDIA GeForce RTX 3070 Driver version 465.27 (Also occurred on 460.XX)
Interesting, reminds me of an “optix denoiser exposure bug” i reported way back, that has been marked as “Known Issue”. Let me find the link
https://developer.blender.org/T77552
I thought it only happens with low exposure value in the color management panel. But in your case it seems to be also the case for bright objects, interesting
Thinking back on it now, it’s possibly related to that. Part of the speedup for Cycles-X comes from changes that that seem to affect the scheduling of work for the GPU. But the MX130 might either be too slow or have too few shader modules to work well with the new scheduling and as a result may run slower.
Disclaimer: This is just speculation on my part. Do NOT take any of it as fact.
