Hi everybody, excuse my inexperience on here but I’ve been testing all three recent version but I’ve found only in 3.1.0 while rendering using system settings CUDA with both my AMD processor and NVidia graphics card selected for Cycles rendering I get a (top) half scrambled picture, but if I select only one at a time (graphics or processor) then it renders fine. It works as it should in the earlier version 3.0.0 and 2.93.6.
This sounds like a bug and should be reported. To report a bug, select from the top of Blender Help -> Report a bug and fill out the form.
Excellent thanks Alaska
1 Like
I have had this happen to me yesterday - completely out of nowhere. Suddenly none of the Cycles-x releases rendered correctly on Cuda (gtx 1060). In the top third of any render all the triangles were messed up. Optix worked fine, stable Blender with Cuda too. It dissapeared after updating the nvidia driver. I am curious what it was though because I hadn’t really changed anything other than running the newest alpha.
When viewport rendering to find the best noise level for the final render, you often find that the noise level was inadequate so you need to lower it a bit. The problem is that Blender will restart the render from the beginning, leading to unnecessary waiting times.
I’d suggest either or Both of the below:
A) Resume rendering rather than restarting when user changes noise level.
B) User sets the noise level extremely low so that it will render until manually stopped. Then show the current (lowest) noise level of the pixels that have not yet met the noise level requirements. This could be shown as a toggleable heat map (lowest incomplete to highest noise levels) + text info overlay next to the sample in the top left.
1 Like
Something like what you have described has been reported here and has been fixed. ⚓ T93283 top third of defuault cube render not rendering properly
A new version of Blender from the build bot will be available soon with the fix.
Good news the new version “blender-3.1.0-alpha+master.d1a4e043bdb0-windows.amd64-release” has fixed the issue. thanks again Alaska for all your help, and the Dev’s who work so hard to provide a great piece of software.
I very much like the new noise-based threshold system in cycles-x, but I’ve found I lose quite a bit of time tinkering with the “noise” and “max samples” values, trying to optimize my render’s time and noise. I think a lot of it could be mitigated if cycles gave the user some feedback on the noise levels of the finished image, or – better even – in real-time as the image gets rendered.
The two (related) questions I find myself asking time and again, and would like cycles to help me answer are:
a) Did my render finish because the noise levels were met, or was it because the samples number was reached? The answer, naturally, changes from pixel to pixel.
b) Which parts of my render are most problematic, noise-wise?
Ideally, cycles would display a coloured overlay indicating the noise levels of each part of the image , that gets updated as the render progresses, along with a legend. I don’t know how feasible this would be, but since cycles must calculate noise levels for adaptive sampling to work, I hope this is not too unrealistic?
4 Likes
I’m testing viewport performance in yesterday’s 3.0 build (with my gtx 1080)
My verdict: It’s so much better looking but - surprisingly - it feels much slower than in 2.93 which I use as a benchmark.
I’m not sure how should I write about this because my results are controversial.
(if this was discussed already then sorry and please point me to any relevant info)
So - on one hand - at the same sample count (let’s say 25) 3.0 generates waaaay better looking results (no matter if Noise Threshold is ON or OFF)
In fact it generates better looking results at FIVE samples than 2.93 generated at TWO HUNDRED.
So this is crazy good, right?
No, because getting to that 25 or even 5 samples are muuuuuuuuuuuccchhh slower than it was in 2.93
So I’m getting huge and beautiful incremental updates in the viewport render but I’m getting them super choppy and slow.
After I wrote all this down I realized I still can’t describe it well enough so here’s a video of it.
2.93 vs 3.0 (with and without Noise Threshold ON but it doesn’t make much difference)
So is it me haven’t gotten used to this new method or does this viewport behavior feel worse to others too? Is it choppy or I perceive it as choppy? And does the semantics matter if it feels slower? 
1 Like
Blender/Cycles offers some tools that can help with this. Here are two:
- Debug Samples Count pass.
- Show Active Pixels (Viewport only?)
To access the “Debug Sample Count Pass” you can select it from here for viewport rendering:
For final renders you must enable the pass in the “View layer properties” and select it as your active layer in the render window.
With the debug sample count pass, you will get something that looks like this:
Darker pixels means that pixel stopped at a low sample count. Brighter pixels means that pixel stopped at a higher sample count with 1,1,1 white meaning the pixel stopped at the Max Samples parameter.
The “Show Active Pixel for the viewport” feature shows a red overlay ontop of pixels that are currently being sampled. Theoretically with adaptive sampling on in the viewport it will start off fully red (as every pixel is actively being sampled) then over time focus on areas with noise. You can enable it following these steps:
- Select from the top of Blender
Edit -> Preferences - In the
Interfacetab of thePreferenceswindow enable the optionDeveloper Extras - In the
Experimentaltab of thePreferenceswindows enable the optionCycles Debug - In viewport rendering mode with
Adaptive Samplingon you can enable this option to get the overlay:
4 Likes
This doesn’t look right. I’ve never seen Cycles-x render a cube so slowly, even with a complex material. It almost looks like you enabled OIDN instead of optix for the viewport denoising by mistake. If older 3.0 builds are faster then you should make a bug report. You could also share the scene here, I could check if it happens on my machine as well.
1 Like
That’s fantastic, thank you kindly for your detailed answer! I’ve tested them and they work very well. Is it not possible to have the active pixels shown in final renders?
I don’t think it’s possible with how the system is setup currently. It can probably be programmed in, but I’m not a Blender developer and don’t have enough knowledge to know how to do this.
Thank you!
It’s basically the default scene with the cube having a default Glass BSDF on it.
Still, here it is:
I’m curious if this is only my machine or not…
Also I have a few 3.0 builds so I checked:
The last one where it wasn’t slow was from the end of August. But the quality of it was not any better than in 2.93 so there must have been significant changes since then.
My next build is from one month later, the end of September… that shows this choppiness already.
And finally I checked the RC too. It’s the same.
One interesting thing I noticed in all the above: I don’t see sample 2,3,4 - the counter jumps from 1 to 5 (after many seconds)
The slow down you’re experiencing probably has something to do with Cycles-X
Cycles-X, was introduced into Blender 3.0 near the end of September. This is the reason why you’re not seeing the slow down with 3.0 in August or the 2.93 release candidate as neither of them have the Cycles-X changes.
As another user has pointed out, you might have OIDN enabled in Blender 3.0 and OptiX in Blender 2.93 which could be making this comparison unfair.
The file you provided has denoising set to automatic which should pick “OptiX” based on your GPU, but maybe it’s not be doing that if your GPU drivers are outdated. Try updating your GPU drivers to see if it helps: Download Drivers | NVIDIA
1 Like
Is there any possibility (settings file) to force Blender to always use OptiX even the command line blender?
We are rendering Blender CyclesX over Deadline and all workstations use OptiX (3080TI / 3090 cards) locally but over Deadline some (2 of 5) fallback to CPU instead of Optix. Blender 3.0 from 29 Nov.
You can override the rendering device from the command line. See: Command Line Rendering — Blender Manual
I’ve just installed the November 30th Blender 3.1 alpha, and the new SSS anisotropy and IOR seem to be removed, is that correct? I assume it’s temporary, but I wanted to use it. Should I install 3.0 beta for that?
Just found the same thing. I think it’s an oversight.
EDIT: It was an oversight 
rB247f37f7652c
1 Like
Anisotropy is still there if you use the standalone SSS node. In fact, the Principled Shader node in general needs a complete rework if its focus is to be changed from artist directability to realism (since the latter was not a priority by those who developed it initially for Disney).
2 Likes