@brecht I don’t know if anybody has mentioned that before, but there are some issues when you set tiles for rendering and denoise while rendering instead of compositor. The denoiser denoises every tile individually rather as a whole pic, which results in visible seams around the tiles. Should be better with higher samples, but I think this issue could easily be fixed if you render all tiles and as a last step denoise the entire pic.
Cycles X Viewport with denoiser on is substantially more choppy with 2 3090s enabled vs 1. Perfectly smooth with denoiser off.
Here .blend - abc_vertex_colors_bug.blend - Google Drive
Bug appears only in cycles-x. In master everything ok.
Is there pause for Rendering for 3.0 planed? would be sooo cool.
It is planned … not yet implemented. You can check the status here: ⚓ T87839 Cycles X - New Features and Changes
Someone got the same problem with samples in cycles-x experimantal CPU, when typing in a number of samples, save the file & reopen to find the sample count multiplied by itself.
For example I set it to 81 samples and after reopen the file it’s 6561 samples.
Thats with all cycles-x versions since 15-09-2021. In master it working fine.
(In this versions there isn’t the option of ‘square samples’ anymore, so …???)
Also https://developer.blender.org/T87837 case is closed/solved. Now it has to be fine tuned,…a lot !
But when looking at todays build, there are some new graphical glitches etc.
Strange issue with dof. Reflection is blurry when dof is activated, but only happens to objects that are far from the reflection.
This should be fixed in the next build (though files previously opened with cycles-x and saved would still have the same issue).
Thanks, but we need the r25.abc file as well to test this.
1 Like
That’s happening in real life too.
3 Likes
@brecht is AO back in the world properties tab (additive light, non fastgi) with merge cyclesX in master??
This is very important for some workflows… and Fast Gi can’t replace it, cause we don’t have additive environment light just with fastgi.
AO in World Properties works like a global ambient light, reducing noise and getting some ‘extras light bounces’, adjusting correct AO distance and factor you can get very clean and fast lighting with 2 or 3 gi bounces, keeping nice color bleeding… some times better than increase gi bounces.
2 Likes
Alright, I tested another scene with mirror, where camera is focusing to mirror. When the dof is intense, then the reflection gets more blurry.
Also this is the source file
https://drive.google.com/file/d/1pfpPFID2PLlYP0uBQQUZGHZd0LTDQp7N/view?usp=sharing
I know that.
My question was if it is going to be in 3.0 because the merge was.
And would the development of cyclesX go further for 3.0? Ore is the rest in 3.1?
Yes, exactly. That’s how it works in real world. If you have a camera where you can specify fixed focus distance, and you specify the focus distance to let’s say 50 centimeters, then if you take a picture of a non reflective surface 50 cm from the camera, it will be perfectly in focus, but if you put the same camera with same focal distance 50 cm from the front of a mirror, the reflection in the mirror is out of focus.
When you take a picture of an object reflected in a mirror, you are not taking a picture of the mirror surface, but of the light it reflects, so the focal distance is the distance from the camera objective to the mirror surface plus the distance from the mirror surface to the reflected object.
3 Likes
I really hope it’s not coming back. The way constant light AO was combined with the Fast GI was so confusing it just resulted in many people using the feature wrong. And it was a pain to constantly jump between two property panel places to even set it up correctly. AO, implemented in this way just straight up does not belong in modern PBR Path Tracers like Cycles.
That being said, if some people for some odd reasons need to have constant ambient light in their scenes, we should have a new Ambient Light type, which would also have occlusion distance parameter. Users could then simply add such light to the scene, instead it being a hardcoded property of the world panel.
1 Like
If you are using the Persistent Data option, memory is expected to remain increased.
If not, you have to be careful how to measure memory usage. There are different statistics (virtual, resident, shared). And processes and threads can hold onto memory for better performance, but still give it back after a time or when the operating system requests it. The details depend on the operating system.
We do denoise the entire image as the last step, and it seems to be working here in a simple test. There may be a bug in some situation where this fails.
Thanks for the explanation! it means a lot to me
1 Like
To be clear about what I’m seeing :
I load a typical scene into blender. It sits at X GB RAM.
I hit F12. The blender process jumps to ~2X GB RAM.
Post-render, the blender process is back at ~1.1X GB.
It’s the doubling during rendering that confuses me. It almost as though a full duplicate is being made for Cycles to work on. This is without persistent rendering, and the behavior is similar between 2.93.x and 3.0. I was hoping 3.0 might reduce this overhead somehow.
Oh, that is expected, Cycles has its own scene representation for rendering.
OK. Is there a possibility to perhaps free the non-render memory, or to stream data from the host process instead to Cycles? Doubling the footprint just seems quite unfortunate.
Maybe you can save memory with Command Line Rendering because when you do it that way the GUI doesn’t load just a console shows up and renders.