Optimistically they shouldn’t impact too much, since the patches are already coded and long-time tested by the most adventurous users. Hope I’m not wrong
what is the reason they don’t enable optix for GTX cards in official builds?
Prior to the OptiX denoiser there wasn’t much reason to have it. It’s more limited in features than the CUDA backend and isn’t significantly faster unless your card has hardware RT units. So that’s why the OptiX backend as whole was restricted to RTX cards. Of course, now the OptiX denoiser being part of the OptiX backend changes that situation, but no one has bothered to flip the switch yet.
Optix denoiser is the fastest of those available for Blender, therefore the best option for viewport denoising. With Bone-Studio build on my GTX 960, Optix denoiser takes only a fraction of a second to finish at 1920x1080. I hope that soon it will be officially added for non-RTX cards (I think it is supported starting from 900 series)
I’d love to request two new defaults for the Principled BSDF:
Default to Multiscatter GGX.
As far as I know Multiscatter GGX is more physically accurate than GGX, so why not set it as the default?
Default to Random Walk SSS.
Random Walk is a more effective SSS algorithm than Christensen-Burley, so why should users have to switch every time they use SSS?
This would save users four clicks every single time a new Cycles material is created.
Well, it also slows down rendering. But that is true that, nowadays, denoisers are game-changers.
New stuff is often seen as an experimental feature that will produce bugs and complaints.
So, most recent addition is rarely default.
If nobody has a complaint about that, that could be an accepted change.
I think the difference between GGX and multi scatter is minimal in a real world scene and multi scatter takes more time. So the majority of objects are good using GGX and only those where multi scatter matters should be manually switched.
Random walk gives visually different results and depending on what I want to achieve I choose. And I believe random walk is noisier so again more expensive. So the defaults make sense to me-you get quick results and if you aren’t satisfied you change it at the cost of longer render time.
Both Multiscatter GGX and Random Walk SSS were implemented a few years ago already, and I don’t think the difference between the GGX and SSS methods is that much slower, but do correct me if I’m really wrong there.
Also, every year the average hardware power of Blender users increases, so defaults don’t have to always remain the fastest method, in my humble opinion.
I completely disagree. A minor benefit to realism that a vast majority of users won’t notice in the face of numerous (unfounded) complaints about speed and forum posts showing users running Blender on machines barely compatible with Eevee’s lax requirements.
Better that node default parameters become part of a user config than unnecessary weight on low end users.
Yes. But that does not change the fact that they are still most recently added methods.
I was just explaining how it happened. That was not a point against the change of defaults.
It is true. But maybe that is a little early to assume that corresponds to majority of users able to handle the methods.
10 years old hardware are supported.
Optix denoiser was just added to 2.82 for viewport. And the current respond to that, is a request to be able to use OpenImageDenoise instead.
In Houdini all of the drop down menu start with the fastest algorithm to the slowest one, more logical for the users imo.
Btw not everyone wants realism in their renders, the default SSS algo gives a FAST ‘stylish’ look if you crank it up
I think main reasons are;
Random walk do not work with unclosed meshes… Human head for exaple if you have hole for eyes…
Muliscatter can kill render combined with motion blur or DOF. I had a scene with water splash where MGGX was 2000 times slower then GGX…
is there anything being done to get IES lamp in EEVEE ?
can’t wait to get fast render in EEVEE with IES lamp
would save me a lot of time
As far as I’m aware there isn’t a way at the moment. I suppose you could always set up a few lights to mimic the look of IES lights and then bring them into your scenes.
I got some IES curve and difficult to mimic it
so much easier to have the IES algo
I mean it is already in cycles it would help to complete it for EEVEE
and much faster render
if you have a link where we can add comment let me know
we need this in EEVEE
More shading nodes added to 2.83 …
It completely changes once refraction enters the picture though, rough glass using normal GGX for instance is far darker than the same material using multiscatter GGX.
When it comes to noise issues, there is an old patch on the developer site (from Lukas) that would actually go a long way to resolving it, but it never had a formal review.
I agree that generally speaking, the defaults should err to the side of rendering faster.
GGX multiscatter doesn’t seem to increase render time that much in my testing, especially not when it doesn’t have much of an effect. If roughness is low, then the render times are almost identical. I’m not sure what @docent had going on with his 2000x time increase with Mggx, but I was only ever able to get a 2x render time with 10000 frosted glass spheres and 128 bounces, even with motion blur.
The amount of light lost in a frosted glass situation is quite noticeable, as is the render time, but for the general case, it doesn’t increase render time that much.
I don’t really have a conclusion, I think both sides have merit, I just wanted to do some testing on my own.
The only way I see someone getting a slowdown that severe is if they simply changed the reflection model while the shader already has a workaround for GGX energy loss (which could lead to rays gaining energy).
When switching to GGX multiscatter, you need to remove any tricks you did in an attempt to reduce the amount of darkening as a result of having rough GGX.
OK, I admit you’ve got a point there. But with the recent AI denoising options, rendering speed is less dependent on hardware power.