one more voice for including it in blender.
granted, it doesnt work for all scenes but i had one scene where the use of the scrambling distance feature cut the render time down to 10% whitout any visible artefacts (crystal/glass reflection/refraction stuff). real timesaver!
one more voice for including it in blender.
Yes, scrambling distance would be very great to have.
Maybe a bit hidden somewhere or inside an optimization panel, where all the options that save rendertimes but can affect the render quality can be found. I don’t really see the point of not having it, maybe @brecht can explain why ? I don’t think it’s a matter of preventing people to have bad renders when not used correctly.
Can someone compile the scrambling distance Branch?
What is scrambling distance?
(the patch is outdated, it does not work with the current master)
Here’s an up-to-date version of the patch: https://github.com/lukasstockner/blender/tree/scramblingdistance
But guys, please, calm down a bit. Me and the other Cycles devs aren’t complete idiots, if this patch was all happiness, sunshine and faster renderspeeds if would have been committed 2 years ago.
If you listen to anybody who really knows what they’re doing in terms of renderer development (for example at Siggraph just a week ago), you always hear the exact same thing: What a practical renderer needs is consistency and predictable and reliable results. This is why everybody moves to path tracing - you don’t need to tweak 100 different settings to make it work like you would need with stuff like irradiance caching, you just render until the noise is gone and that’s it.
And exactly there lies the problem with this patch - it completely breaks this fundamental property of path tracing. Every Cycles user is used to just rendering until the noise is gone because the underlying math guarantees that you’ll have the correct result then, but with scrambling distance < 1 that is no longer the case. Yes, the image will be noisefree - but you can also get that from Blender Internal or Eevee. The entire point of Cycles is to be a physically based renderer that gives you the right result.
The scrambling patch tricks you into thinking you have a clean image, but you don’t know for sure anymore - with a small scrambling distance, it is entirely possible that an entire room suddenly is 30% brighter because you moved a single lamp by one centimeter. Yes, seriously. Now imaging you’re rendering an animation with an animated lamp. This brings us back to the advantages of path tracing - you don’t get flickering, individual crappy frames in the middle of your animation or any of that stuff - if the render settings work for a few frames in the shot, they’ll work for all of it. Unless you reduce scrambling distance.
I hope this makes it a bit clearer why this patch is so problematic - it’s not just a neat trick like many other features, it completely sacrifices the design goals and fundamental advantages of a path tracer.
Also, just to make sure - yes, if you know what you’re doing, you can get good results with it (see e.g. everything Theory does). However, if you’re an artist hoping to use this feature, you’re not the one who has to handle the bug reports. Oh, and there will be bug reports - we had people reporting “bugs” because they mixed up left and right before and every few weeks there’s a bug that just says “it doesnt work” as the title and has the unmodified default template as the text. For another example, grab a few Cycles materials from Blendswap and check how many of them have two shader nodes plugged into a MixRGB node. The reality is that the people discussing experimental patches here are among the users with the most technical skills and many Cycles users just have no idea what it actually does under the hood. And that’s fine because, once again, you want to have a path tracing renderer so that they don’t have to.
And as a final note - please don’t turn this into another Lukas vs. the other devs thing, we had this a few years ago for D808 and even back then it was bullshit. Just to be completely clear, I 100% agree with the decision to not have this feature in official versions, not even as an experimental option.
It is interesting to observe over the last years (decades?) that software development orients itself more and more on the ‘average’ user. At some point in time all these were specialized complicated and not very accessible tools that you were expected to learn (read the manual for starters).
But now that everyone has a voice thanks to the internet, the reason not to implement things is to not confuse people who in turn would waste every ones time with their questions?
I would wish for 50 knobs, as i am doing this stuff since 20 years… And i am surely not alone.
Edit / Add: I think Unity does a good job of serving both ends of the spectrum
A question from someone who knows nothing about coding or compiling with a patch, would it be possible to make it an addon so only artists who are really committed to using it will install it?
Solution: Don’t accept bug reports. Do not include it in “Experimental” feature set, but do include it in an “Unsupported” feature set. Basically a summation of experimental and itself. Just tell people bug reports are not accepted if they have selected the “Unsupported” feature set.
Alternatively: You could also have a “Still Image” feature set down the road for things that do not work well between multiple frames. Not everyone is using cycles for animation.
Short answer is probably not. The add-ons are written in Python, while Cycles is C++. While you can create bridges between C++ and Python, it will likely not make sense because the change may affect a core part of Cycles, and Python is known to not be a runtime fast language. You don’t want to see your renders become 10x slower to add support for this.
However, if you want to add it, feel free to compile with the patch. Just don’t expect much support from the Cycles team.
Also, as a developer that works closely with artists in a studio, I know how it can seem like the dev team is not adding features because of arbitrary reasons. Usually the reasons are a lack of time and resources, or adding the feature will make things worse. We don’t like making things worse. Either way, have some trust in the team. You have some miracle workers doing magic.
So you guys will not Include a very usefull feature for many users because some people don’t know how to use it, what are the limitations and you will get bug reports? This is a very lazy excuse.
Well, no one said that it will magically work for every scene there is but it works wonders for some scenes so therefore i think it worthwhile adding. It IS an experimental feature, no? For what is that experimental option in cycles if not for something like that? It works for alot of people
It works 100% with animations. it works well enough for us to use it in 100% of our scenes…
Oh boy please , in one word the reason for not adding is path tracing. People are having good result with Eevee …
you dont know why RedShift became so popular among small studio & freelancer ? it’s easy to use, it’s super fast, and it’s beautiful, and when you set your GI to Irradiance cache, you can force ‘brute force’ to certain object if you need to, as simply as that. idk why you developers wants cycles to be unbiased, having some biased option would hurt no one, specially when the tool are already developed, you should let the artists decide what does & doesn’t work for them.
Christopher Nichols from chaos group here says that clamping makes a renderer biased
anyway, dont take my word to the first degree, you have a better perspective on all of this ^^
Hi lukas, I think this issue can be solved by making it a feature that isn’t exposed in blender’s UI at all by default (not even as an option under experimental features). In order to see it in the UI, we could have to launch blender with a command line argument in the same way we do for the debugging options.
That solution should be sufficiently technical enough to keep novices from using it, while allowing the more technical users to enjoy its benefits without having to compile a custom version of blender. That should be enough to keep the folks here from complaining about not having it.
yes, good solution… or python set property command… or hidden string render parameter like in mentalray. please, please Lukas, add this to master. Comercial works need fast responses and fast renders.
hidden string render parameter like in mentalray.
Oh god, I’m having flashbacks to Maya 2012.
Most of my work is still images.
Most of my animations are heavily stylized so physical correctness is not an issue.
As far as I tested this feature back in the days it was useful.
Although Cycles is physically correct people use all kind of hacks to get good results with optimal speed. (Clamping, Simplify, AO etc).
I think that biased solutions do have a place in blender.
On the other hand I’m not a fan of sacrificing software features in the name of user-friendliness. Software is a tool and it’s value must be based on it’s capabilities both for professionals and beginners.