Watt is the standard SI unit for radiant flux. See the table on:
Lumen is a photometric unit, not a radiometric. That’s the difference that Troy was trying to point out earlier.
2 Likes
yes thats right,however in other render engines, like vray or corona you can select the unit conversation to your like.
In IES files usualy the light intensitys are as lumens listed .
1 Like
I was asked to give my opinion on this topic, and I am tempted to not give an answer at all. This appears to be a very heated debate, and I’ve been long enough on the internet to have my instincts tell me to stay out of this…
I agree with @brecht that we can’t just take a subset of features and put them in approximate real world intensities while at the same time leaving others unchanged. Doing this would be the opposite of an improvement - it would be like mixing mixing imperial and metric units.
If you want to go to physically “correct” system, you need to start with the basics and it starts with what may be @troy_s’ favourite question: What is a pixel? What should a pixel value of, say (0.75, 0.75, 0.75) in an EXR file represent? How should your computer monitor display such a pixel? What should it mean when you take an image texture of said value (0.75, 0.75, 0.75) and apply it to a diffuse surface shader? Only then can you start deriving an actually plausible and cohesive “physical” system that includes lights, materials and a camera model of your choosing (what is ISO 100 in a render engine?).
Otherwise you’re just picking values out of thin air and pretending they’re correct. I don’t need a virtual exposure triangle that unnecessarily connects motion blur to image brightness when I could simply use a direct exposure dial instead. You may think having everything simulate the real world is a blessing, but wait until you have an art director look at your perfectly lit scene and say “Everything’s perfect, but can we have a little bit more motion blur over here?”
Building a modern render engine entirely around film camera controls is, in my very personal opinion, building the proverbial “better horse” (except that you’re leaving out all the fun parts, such as push and cross processing and similar techniques that got lost when digital cameras took over).
5 Likes
Seems like we are going with hardcoded colors suggested by Brecht in the end… Uff… 
despite the majority of the community choosing the opposite…
No no,don’t get me wrong.The idea is just to labe it with the unit used,if Watt is the right choice in this case then be it so.
The thing is from time to time,the questions came up,such as " what is the strength of the sun " or “what unit is it useing” and so on.Label everthing should make it clear.
1 Like
Then why do we do that already? Why are the light units in watts and not some generic unit? Now we have light sources in watts but emission in materials in same units, just unlabeled. Yes, we should not take a subset of features and put them in approximate real world intensities, but we are already doing that in Blender. Sure doing it properly would mean some big, complex design tasks, but those often usually just end up written down in half finished state and then neglected for couple of years cause no one wants to take it on.
4 Likes
For moments I really feel we most users and developers (plus Troy) are not in the same debate. Cycles (an even EEVEE) are right now physically correct renderers internally, when it comes to light transport, right? Who is asking for changing this? I think no one. The only thing we need is a converter for lamps, at a UI level, between radiometric units and photometric, I don’t care how innacurate it is, just put a warning in the description of the enum when going from watts to lumens or candelas. Converting between them is perfectly possble given the characteristics of the lamp as far as know, maybe I’m just dumb. Anyway this is present in other engines for years and that’s the reason we want it in Blender.
I don’t get it. I have to cite V-ray. There, I used to manage each element of the exposure triangle separately, so I could set a low shutter speed for more motion blur, even in ranges outside most cameras capabilities, and I don’t think the engine were doing nasty things internally because of it. Controlling exposure with a camera object is an extension of the current global exposure control, more accessible and understandable. If you want, keep separated the elements of the triangle and the global exposure control like it is now, but place a global exposure control inside the camera and end with the mess of todays Blender when it comes to seting up exposure.
No one is requesting even changing the default exposure in Blender, just changing the time of day for the corrected Nishita sky would be enough for all of us, begginers or experienced users without further changing of internals or default values so no back compatibility is lost.
I think I share the same vision of many, maybe I’m wrong or all of us are wrong, or many render engines out there are wrong, but the current lighting workflow in Blender just don’t feel right.
2 Likes
Improved documentation and labels, that I’m 100% on board with. Having all of that written down will also help us making sure that future development doesn’t break anything.
2 Likes
I don’t want to have a say in this. Choosing defaults is a UX decision, not engineering.
For an engineer, there is only one sun in our solar system and we wouldn’t need a parameter if this is the only thin go we ever wanted to render. Artists may however want to build fantasy universes instead.
The ultimate question is however - will it behave as the user expects? Right now, any blender light you add to the default scene will neither over or under expose. If this new light overexposes by several stops, will users expect this behavior or will they think it’s a bug?
I don’t see my self as a user - my answer shouldn’t count.
I see where this is coming from, but IMHO it is very misleading. When you present something as “physical camera”, it better be one and both aperture and shutter speed influence the exposure. If they don’t, then give it a different name.
They are. We may call it “physically based”, but for a large part it’s still just smoke and mirrors. Many default shaders wouldn’t pass a furnace test.
The industry is moving in the right direction though, and things are improving.
But again, this is just my personal opinion and I do not think it should count.
ISO in an ideal camera is simply a brightness multiplier. Adding more motion blur isn’t a problem now and would be no more of a problem with a physical camera.
I agree that the ‘right’ way to solve this is from square one, but that’s simply not going to happen. Every time I’ve seen attempts to ‘redo something from square one and do it right’ things either fall apart and don’t come to completion, or they build a slightly different but still similarly broken system. That’s just a fact of software development.
Incremental improvement is a proven way to make progress towards an ideal, and is often the only one which actually results in positive progress. Right now we’re all in a loop of ‘it’s broken but fixing this will cause other issues so I’ll just make this broken in a similar way to the rest of the system’, which is extremely damaging to the productivity and long-term success of the engine IMO.
Again, I think there are multiple suitable solutions to this problem right now many compromises which I’d be happy to use for now without wider changes to the system, but I disagree with the absolutist view that everything must be done right before making it in to master. Clearly that’s not the case.
9 Likes
Anyway, they just work out of the box, and established the current workflows years ago. And they are enough physically correct for me when they allow mixing of CG elements with real life footage fairly easily, for instance. Anyway, we are not talking about future, but about catching up with current workflows before looking forward, and about making life easier for artists without breaking much what we have.
That’s the Strength value of the Background Shader. It could behave as a sky texture multiplier, but it’s not so immediate to use even in the example you provided. We’re debating for defaults for new users: multipling and dividing two sliders of two different nodes will sound cumbersome I guess.
If a slider is “unnecessary UI complication”, this is “unnecessary UX complication” 
Let alone the fact that sky texture can be mixed with other stuff (cloud textures?) that might not have to be multiplied
Nice point. I’ve been thinking from the beginning of this debate, that a physical camera (i.e. with all the basic settings you find in a classic pro camera) would have solved any issue, but freedom is the key.
So, the only chance is to optionally rely on addons like Photographer
1 Like
Just for the record in case others don’t know where this comes from: in “other” renderers, in the physical camera you have an option so that aperture and shutter speed influence only depth of field and motion blur without affecting exposure, and this is disabled by default. And nobody goes crazy about it, everybody understand that is there for having the ability to setting up lighting and effects fastest without worrying about their inner interactions. Advantages of simulations over reality. Anyway I were not talking about that, only about the posibility of integrating all controls in a new camera, and don’t have everything spread across several UI panels when it comes to configuring exposure, with its related limitations (same exposure and blurs for every camera)
2 Likes
If they do i would be super happy to teach them why and how to properly use it.
Even providing exhaustive documentation about that, it would be a pleasure.
Totally agree.
That’s why it would be better to have the accurate sky lighting values by default and not some arbitrarily chosen ones.
I don’t think everything must be done in one step, but there should be a clearly defined goals to which the individual steps lead. Just taking one feature in a new direction and not even knowing what to do with the others will make that one feature stick out like a sore thumb. Even if it is technically only one that’s correct, to users it might seem like the only one that’s broken.
2 Likes
Users want to know about photography, they want to be educated, that’s why they always end up relying on “physical this add-on, physical this other add-on” and introducing a single sky doing that seems a fairly reasonable little but profitable solution.
1 Like
And it is unlike any camera that ever existed in the physical world - and it’s good that way. Making it explicitly not behave like a real camera is the way to go IMHO.
Now, once you’ve taken both shutter and aperture out of the picture, you’ll see that exposure isn’t even a property of the camera. That real cameras have to determine the exposure parameters before the shot is taken is only due to the the limited dynamic range of film or sensors. In the renderer, dynamic range is more or less unlimited - you can control exposure entirely after image was taken, in your virtual darkroom. It makes not much sense to me to put an exposure control on a virtual camera other than catering to the 1% of photographers (yes, I’m including casual photography) these days who don’t shoot on smartphones. Everyone else will first take the picture, then adjust the exposure.
Replicating the camera controls of a 1970s SLR is, IMHO looking backwards and not forwards. I wouldn’t be surprised if electronic shutters of the future can read a continuous data stream from the sensor, turning “shutter speed” into a pure software post processing step.
Still 90% of the community prefers to have a bright sky by default anyway, here is the evidence, and even after their choice we are still debating?
won’t repeat the huge amount of proof that studios who are serious about color accuracy need accurate lighting and camera controls.
I wouldn’t have participated if you hadn’t explicitly asked for my opinion. But as I said - I’m not the one who’s going to end up using it, you shouldn’t be listening to me.
1 Like