Large(ish) memory commits in some instances can quickly overwrite all remaining disk space
I'm asking that physics simulation and scene respect the frame rate beyond the the draw rate for viewport rendering.
@Clément Foucault (fclem) any ideas?
I dont have SLI enabled but it could be an issue with my GPUs.
Could there be something else besides SLI that causes this issue?
That .dll forces blender to use software rendering. So the issue is with your GPU drivers it seems.
Are you running in SLI? If so, does it help if you turn off SLI? (Remove the .dll before testing again of course).
Thank you, now it actually renders Eevee.
But now its very very slow and laggy. The background is also still black.
And the blender instance crashes after a while.
Do you know why this could be?
You have only posted a description of the error not any steps to reproduce.
I do not have the drawing glitches. Only the color difference. I guess that the color difference if because of not color management. If you set the color managment display device to None it nearly matches the colors. So I'm guessing this is the reason for it.
We indeed follow the monitor V-Sync, by design.
Most likely a VSync issue, especially if it's exactly 120Hz. Try disabling it in the Nvidia control panel.
But also: What playback sync do you have set?
Wed, Feb 20
I'm going to assume this all these recent macOS bugs are about the same issue.
Ok then, If there's nothing to be done about it.
The noise is smaller than the size of a pixel in the cubemap, and thus the small noise disappears in the downscale process while the few ones that appear look big because that's how big the pixels are. It's like downsampling a picture of stars in photoshop, that's what happens, and no filtering algorithm would solve that 100%. It's definitely NOT procedural textures changing scale, because then it would change scale even with big textures like in the imaged I used above
Moire effect doesn't explain this:
What you see is a combination of a moire effect, due to small scale of the texture and the low cubemap resolution. Another way of putting it, the texture is so small than when it's captured on the cubemap filtered at a lower res, it just happens to look like a large scale version of the same texture, an optical illusion. But if you use any other procedural texture, or the texture at a larger size, you see that lowres cubemaps don't change their scale. Like in this image with the lowest cubemap resolution possible.
Ok, thanks for testing, will consider this resolved for now then. Transparent shadows indeed are tricky for realtime rendering.
I'm not sure what is meant by BSDF shaders. Diffuse and glossy are BSDFs too, in fact only BSDFs can be affected by shadows.
I don't get it. I can mix base color maps, metallic maps, roughness maps and normal maps using mix RGB nodes and screen space reflection works just fine. Why is mixing shaders any different?
Tue, Feb 19
Okay, talked to Clément and this is working by design. Although mixing RGB is fine, there is no way to reasonably mix SSR data.
So I can get the transparency to work by changing the object blending mode, but the shadow does not appear to properly represent objects with transparency - however I assume this is standard/expected with eevee presently.
The issue is on the ssr_data calculated in bsdf_common_lib.glsl:closure_mix().
This happens with BSDF Shaders
This mostly happen with BSDF Surface / Shaders
I just noticed, that even when you mix two separate identical shaders there's still a difference in brightness. You can see that in the video in 00:25 on the lower right corner of the box, there's a slight variation in brightness.
I had the same problem last week. One of my files cashed at random while rendering in cycles. I tried rendering on CPU only but it crashed too. It was impossible to reproduce. Then with an older Beta version of Blender 2.8 it rendered.
I will have a look on it. I have to render a lot in the next weeks, maybe I can reproduce the problem or it is solved already.
I'm rendering in Cycles and it does regularly crash in the first 50 frames. Although I did start at frame 16 and made it all the way through 160 once. Once. *sigh*