Good point, curious to know if there are any plans for that implementation already.
Meanwhile, in your opinion what do you think we should opt for? arbitrarily down-exposed or sky with no hacks (that appears bright at default Blender exposure value) ?
Just a heads up, having a physically based sky lighting would be beneficial for a lot of things, consistency in particular, as you can see in this video:
And by the way the poll results show evidence that people prefer physical rather than good looking at default https://www.strawpoll.me/20587754
On top of that many suggested to go with the Sun Elevation 0 compromise.
2 Likes
Thank you for pointing this out, @troy_s. There are only a few ways to have an absolutely correct HDRI, and they all pretty much require adjusting in-engine compared to reference photos along with plates taken alongside the HDRI, colorchecker charts, and/or using photometric values obtained at the time of shooting the HDRI.
Getting photometric values out of Blender for double checking is difficult. The kinda-hacky way is to take the scene-linear RGB values, get the luminance from the RGB values, multiply that by 683, and then multiply the whole shebang by pi to get lux - but as @troy_s mentions above with the ISO stuff, it’s all a bit hocus-pocus magic.
Regarding UE4’s physical sky implementation - by default it is not absolutely correct, but scales to be correct with whatever intensity the sun is set at. It has nothing to do with auto-exposure. If you place the new UE4 sky in a scene with a sun with below-physical values, the sky will match that relatively dim sun, and likewise if you set the sun at a realistic value, the sky will scale up appropriately.
By default, UE4 exposure range doesn’t even go high enough to cover a physical sky - that has to be enabled under “extend luminance range” under project settings. My point isn’t to necessarily take sides with this info, I’m just establishing the context that, no, UE4 is not physically absolutely correct by default.
2 Likes
To just take this one step further for the benefit of the community and to disambiguate what it takes to have an accurate HDRI, here is how you would do it using UE4 (which has photometric-friendly tools available).
First off, you have to shoot the HDRI yourself. In addition to whatever method you’re using to get the HDRI, you need a plate with a macbeth chart that you also have a digital synthetic copy of. On top of that, it wouldn’t hurt to have a middle-grey ball (the expensive kind with an actual known value of “middle grey” that can be verified reasonably into an RGB equivalent).
After you shoot the HDRI, you need to do an incident light check with a light meter giving you lux of a surface you can recreate in UE4 - whether that’s a diffuse middle grey card or a piece of white paper or whatever. You then also need to do some spot checks of the sky, giving you luminance (cd/m^2 or nit if you like) over a few sample points - let’s say a dozen spot checks of the sky at various points.
Create and white balance the HDRI based on whatever methodology you want.
In UE4, you apply the HDRI and have a digital recreation of whatever object you did an incident check against. Up the HDRI intensity until you get the same lux coming off that bad boy. At the same time, you can also take a lower mip of the HDRI (to get a blurred, and thus averaged, result) and start doing luminance checks of the sky and see how the match up to your real-life luminance spot checks. If you can get the lux and cd/m^2 to match with your reference, you’re finally good to go.
It’s basically impossible to just take any old EXR that somebody claims is “correct” and trust it.
3 Likes
No one wants photometric in a physically plausible light transport system. It doesn’t work.
1 Like
As a lighting artist working in the entertainment industry, I strongly disagree with that statement. Who is “no one” in this case if not professionals like me?
To expound further, is the purpose of the render engine to serve humans or to be completely correct in an idyllic white tower? If it is indeed built for humans, it would be helpful to cooperate a bit and work with tools that lighting artists have to use in the real world, which are primarily photometric-based measurement devices.
In a previous post I linked a huge number of modern render engines, both offline and real-time, implementing photometric features. To make a ridiculous statement like “no one wants this” strikes me as bizarre and unnecessarily dismissive.
Lastly, everything in render engines is not representative of reality to some degree, whether it’s the fact that we’re limited to geometric optics, BxDFs that only coursely simulate microgeometry and transmission, or what have you. Let’s not draw arbitrary lines in the sand of what is sane to approximate and what isn’t.
2 Likes
It was dismissive; photometric light values don’t have a place in a light transport engine.
They can be auxiliary information, but even then, given the swaths of confusion over the basics of colourimetry and radiometry, it is likely diminishing returns.
1 Like
You’re not being very convincing if your only messages consist of things like “no, this won’t work” and “it doesn’t seem useful” despite the literal mountain of evidence of momentum within the industry seemingly against you. I guess I’ll just leave it at that because you don’t seem to be willing to budge from your stance.
By the way, have you called Weta yet to tell them that using photometric quantities in a light transport system “doesn’t work”? https://jo.dreggn.org/home/2018_manuka.pdf
Allow me to quote the relevant part for you:
Photometry.We make use of colour management throughout the pipeline, employing photometric quantities [USAS and ASME 1967]to support more intuitive user interfaces for lighters: this enables them to change the colour of a light without affecting perceived brightness, for instance.
I suppose the lighting team at Weta doesn’t qualify as “anybody” in the statement that “nobody wants photometric units”.
1 Like
I still did not get answer to this. Is there any reason to keep old Preetham/Hosek model now that we have a new one? The Preetham/Hosek model was never finished and never in any usable state. It was not possible to utilize it to get any meaningful results. There was no justification to have it in Blender even before we had an alternative, let alone now that we do…
The Preetham model seems fine to be kept along others, I love to have a whole collection of old and new skies. And anyway since Hosek and Preetham share the same code I wouldn’t bother much about it.
I use Maya with Vray at work and the way its handled there is that a vraylightmtl shader (emission shader in the blender world) has a checkbox called “Compensate camera exposure” which allows that shader in the background change its intensity so that the values mapped to it from the texture input will always be the same in the final render. therefore ignoring any guesswork for motiongraphics. if you want to work with proper units so that when you change the exposure it gets lighter/darker you just turn it off and plug in a proper value into the intensity instead of 1
7 Likes
This seems like an elegant solution to the ‘two competing goals’ problem. Thanks for bringing it up.
2 Likes
RECAP
I still prefer this solution, but for sure neither hardcoded values nor extra UI mess.
That being said, i’ve contacted Ton and he said to get the whole Cycles team in touch for the decision.
So, @lukasstockner97, @sergey, @StefanW I’m mentioning all of you as members of the Cycles module to know your opinion about the topic.
Why would having physical sky lighting in Cycles be beneficial?
and because according to statistics the community prefers physical over hardcoded.
Why would having hardcoded sky lighting in Cycles be beneficial?
(which doesn’t make sense at all since, as seen in statistics, people prefer to be educated to use the Exposure value of the scene to get consistent results and as stated by a random user post below)
Corona, Vray, etc… The most used renderers out there all behave in the same way. If you deploy their physically based sky model set up to around noon at the default exposure level of 0 you will get pitch white image. That has not stopped people from using it.
I have to say again that you are trying to invent problems where there are none. I could point at dozens of completely fubar feature designs in Blender, which are so incredibly damn confusing to use out of the box, and which no one wants to fix, that having to lower exposure before using physical sky model is a child’s play compared to that.
It’s more than safe to assume that by the time user even arrives to the part of Blender where they’d be attempting to set up the sky model, they would have already proven they are more than capable of figuring out how to lower exposure.
I mean how does something as minor as default exposure compare to way more difficult issues like reloading image textures constantly changing input color spaces back to sRGB. If you don’t even count on users being able to lower exposure, how can you count on them to be able to set all the image texture inputs for PBR materials with right color space and then constantly, compulsively keep remembering to fix the image color space when reloading images? That’s been a difficult task even for me, as an expert user.
Here you are trying to invent problems for a new feature while there are existing, much more destructive and dangerous problems all over Blender to fix. We are here discussing about how default Sky exposure change would make Sky more convenient to use with shader nodes, yet here I am still finding normal maps and roughness in random materials loaded as sRGB because Blender keeps throwing sticks under my feet.
If that is not an usability issue, then how can this one be?
11 Likes
Agree that Cycles should not be afraid to give physically-accurate lights to users, and furthermore agree with above points that Blender should really be integrating a physically-accurate camera, so that users aren’t using some arbitrary exposure value not tied to anything. It will be an approximation, like so many other parts of rendering, and one that aids people involved in production lighting as opposed to scientific research (Mitsuba, etc.) which is not the market for Cycles.
4 Likes
I don’t believe you read what I posted the way I was intending it to be read.
Photometric units have no place in a light transport model. They don’t work. And I assure you that nowhere in Manuka’s internal actual working rendering space, are any photometric values. It’s radiometric all the way down to the spectral layer.
User interfaces and other presentations? Go nuts, but be warned that basic colourimetry is, as I already stated, subject to vast swaths of confusion. I mean, as a simple example, try to ask a majority of people what “watts” means in the Blender interface. Trying to actually manage photometrics in terms of a presented user interface versus what is happening in the actual light transport model is nearly impossible at the current level of Blender, let alone the more complex layers that can stack up. And that’s assuming all of the code contributors are on the same proverbial page, which as we can see rather clearly from this thread, is not the case.
I hope that clears up the vantage.
3 Likes
Yeah, makes sense to set golden hour as default, as it is favorite time of day for cinematographers
I’m starting to think a strength slider on the sky node might be a good thing to have, and would solve this problem. The reason for this is being able to put the sky through node groups (essentially compositing a sky out of multiple elements) and being able to control just the sky brightness without affecting the other elements of the background. I feel the default strength should be physically accurate, and would be left alone most of the time, but it would be a nice thing to have when you need it.
2 Likes
I was trying if a color mix node set at multiply >1 would do the same job of a slider (which I don’t like so much) and found out that in the current sky node if multiplied by, say, 10 the sun is very dim and gets washed out, even setting also to 10 the “Sun intensity” parameter.
Is this expected?
On a second thought: we already have a slider for the sun intensity, we can live with a second one for Skydome intensity I think.
Provided that their use is intended for lowering the default correct (superbright) value.
Speaking of defaults, I also wish to point again what @Jason_C said here:
Golden hour would be fine. Afterall, pursuing realism out-of-the-box, you really don’t want to show newbies an odd, uncommon, and overall bad illumination like the sun at the zenith.
2 Likes