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.
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.
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”.
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
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?
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.
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’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.
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.
I don’t think anyone here requests any advanced radiometry simulation. Here’s a practical example of what I believe most people want:
If you have a photograph of a white room with wooden floor and one window, with there being perfectly sunny day at 2PM outside, and a 60 watt light bulb inside, then if you model this room in Blender, set up materials of at least similar albedo, set up physical sky with matching time of day and north direction, place camera at the similar place and place in 60 watt point light, you want to get not really identical, but at least similar results. Especially when it comes to ratio between that exterior day light and the interior light bulb.
If you have physical sky that’s under exposed by several stops by default, then this “W” here:
stops meaning anything, and will actually serve as a trap for new users, who will really think they are inputting a value of total radiance in watts and then wonder why their 60 watt light bulbs looks like 1200 watt nuclear explosion when they are using supposedly physically based sky model.
So let’s say you want your sun to stay the same and have sky 4x brighter than it should be. Very easy, just reduce sun intensity to 0.25 and then increase the entire background strength to 4. This will multiply that sun intensity back to 1.0 but sky will now be 4x brigther.
Otherwise you’d end up have just one more random “multiplier of multiplier”. The simple 2 parameter control of one parameter being ratio between sun and sky intensity (the sun intensity parameter), and the other being the actual brightness of the sun/sky system (the background strength parameter).
The units should be in lumen or lux, that is lumen per square meter.Watt means nothing if you think about a LED lamp with 5 watts can be bright as a usual 60watt lamp.
Well, it can mean the radiance of theoretical light source of 100% efficiency. That being said, don’t tell that to me, I did not decide the watts to be the unit My point was just that since Blender at least pretends to care about light units, then they should mean at least something. But if we then make decisions like underexposing physical sky model so that complete noobs are not confused by white screen when they first use it, then these units lose their meaning altogether
My point was just that since Blender at least pretends to care about light units, then they should mean at least something. But if we then make decisions like underexposing physical sky model so that complete noobs are not confused by white screen when they first use it, then these units lose their meaning altogether 
I would say just go for it,make everything physical correct.The intensitys,the units and everything thats related to this.