I thought they could be. I know you can have a PPV in a Blueprint in the public build, but at my last job I set up a BP to find all volumes with a tag, then set new PPV settings with a trigger. Downside is that if you haven’t placed volumes in your buildings yet, you will need to and you’d have to tag them. But maybe you can procedurally place it based on size of the rooms or something and you can set the tags at once if you have multiple selected.
Hi! They actually can!
I’m sorry as this is gonna be a bit off topic, but i wanted to share how we do these for our interiors.
So to put a post-process inside of a blueprint you must have a BoxComponent (that serves as a bound for your volume) and then attach PostProcessComponent to it. We have a system where artists make prefabs in separate levels and just copy PPVolume with correct settings. Then our in-house tool merges these into blueprints and copies PostProcessComponent from a volume, and BoxComponent is made from code using size of the original volume. In some cases we do it proceduraly just like @rosegoldslugs said.
From what i’ve learned, you could actually code a data asset that would contain post process settings and then make a custom component to assign these from ContentBrowser. Should be quite easy if you have someone who can code.
nice, this alone works!
I don’t get why you need all of this though 
but yeah okay, we can go back on topic now!
I set the direct light to 80 000 and skylight to 5 000.
Shutter speed 125, ISO 100, Aperure 11
But now the Sun on HDR skybox and shiny surfaces in general appears black.Did I miss something? I though I did similar setup as others here.
You should “apply pre-exposure” to your scene in the project settings. Just also be aware enabling that will break the Pixel Inspector.
4.20 has been out for a good while now and there’s still no official response to the original issue of this thread. Proper physical light values would greatly improve our workflow and teamwork across projects, but as they’re currently implemented it’s not improving our workflows and are generally causing more confusion for our artists.
I agree with everyone’s grudge about the physical world lighting system in UE4 being a bit cumbersome. Because when I use light in programs such as V-ray + 3D Max and I’ve set my Camera’s Aperture, ISO, Shutter Speed, and lights to real-world settings (a real Cannon Camera and 75W light bulbs), It looks 99% accurate.
But trying to set up an identical setup settings inside UE4, is far more problematic. Nothing looks right. Not sure what Im missing. The Aperture (F-Stop) in UE4 almost appears to be useless. Far from the results I get from a realworld camera.
I hope this system gets addressed or at least clearer documentations.
And yes, I’ve read this documentation - Auto Exposure (Eye Adaptation) | Unreal Engine Documentation
Planning to fix physical lighting for 4.21?
If I remember correctly, Epic said they were preparing for E3 and would get back to us soon after. Now it’s after Siggraph, still no official response 
I have to admit that I am quite hyped for some of the new stuff, but pls guys, don’t forget to fix or at least talk to us about some of the old baggage we need to tackle! 
Cheers!
Is it likely that Epic will give us some idea on the state of Physical Lights, seems to be complete radio silence, I have gone right through this thread and am still confused on why my lighting just doesn’t look right.
The confusion for me is how to correctly set the PPV autoexposure (or even the manual camera settings) as none of the settings make sense. Are the settings in Auto-exposure supposed to be EV values and F-Stops on the manual settings for the camera seem really wrong still (even on 4.20.2).
It is very disappointing even to the point that for a recent minor project we went to latest version of unity with HDSRP (yes we realise it is still preview but worked well). At least there the settings all seemed to work as expected.
Come on Epic, please help us out here, I dead-set do not want to do anymore work with a competing product when we have so much time invested with UE4.
Really makes it difficult to stick with UE4 when Epic constantly misses the mark on the fundamentals. What’s the point of using physical light values if I can’t properly set the exposure?
I honestly can’t emphasize how *basic *this is, and yet it’s looking like this will be another feature update left to rot half-completed. I can’t believe how much radio silence there’s been on this issue
For auto-exposure, I suggest using the Basic Exposure, not the Histogram, because it provides a more reliable result imo. Basing exposure on a histogram is alright, if everything is correct, but in most production environments there’s always some outliers like emissives that are way too bright and a few pixels will throw off the entire histogram.
Plus, combined with the Pre-Exposure and the new feature of a constant calibration factor, Basic Auto Exposure will always try to adjust for a particular gray like cameras do. It defaults to 16, but you can change it to 12 or 18, or whatever you want.
Just set the max exposure value to something like 10,000 to accommodate the higher range in physical units and that’s it.
But if you’re looking for a way to set a min/max EV, I don’t think there is a way right now.
Still no answer?
I agree with @Sickmoocow this is super basic stuff.
Light = what we see inside the engine.
We ended up doing the last job on unity 2018. We simply can’t afford to take the radio silence from epic’s side on this topic.
@Kalvothe any news on this?
Hey everyone,
Apologies for the delay. I don’t have an “official” response yet to all the concerns in this thread but know that we’re carrying on some active conversations right now with some of the engineers and are looking at how we can address this in our Documentation.
We’re evaluating how we can best approach this to make the most of the new physical lighting units. Whether that is through examples in the doc, an example map, or something else is still to be determined, but we’re actively looking at improving this. Also, in 4.21 we’ll enable pre-exposure by default, which should help lessen confusion. There is also some setup between the physical lighting units and post process that we want to address to better tie these together and provide detailed example setups as a starting point.
We’ll be evaluating notes from our engineers along with reviewing concerns in this (lengthy) thread. I don’t currently have an ETA for the changes to be implemented in the documentation but hopefully around the 4.21 release timeframe or shortly thereafter.
If anyone has any thoughts or suggestions (that haven’t already been mentioned), please feel free to post them here as we start to look at this over the next week or so.
I noticed that with Pre-Exposure enabled in the current build, the Pixel Inspector doesn’t show the same values as with it disabled. Will this be fixed at the same time? When using physical units, I’ve had to work with it disabled, get my HDR Luminance values to be around the correct cd/m²/nits, then enable it again afterwards. Not a fun process since it has to keep recompiling shaders each time 
Thanks for the heads up though! Looking forward to what you guys do to make it more intuitive.
It’s not a process I’m fully aware of at the moment, which is why I had mentioned this not being an “official” statement from our engineers. 
The shader recompile was something that was mentioned by one of the engineers, but workflows and processes are something that Sam and I are planning to look at how best to document them along with some of the best practices to make things easier. We understand there is a lot of confusion (even on my part since I’ve not really used the new settings as extensively as you all have!), so we need to take the time and do the docs right on this part.
WRT Pre-Exposure values, I’ll bring that up to the engineers.
Thanks!
Nice to see you here Hobson! Finally!
About suggestions, I think that “draw a square and get the median HDR values from a selection of the sky” that Daedalus proposed in his video could be a useful addition to the pixel inspector, to get values from a surface area, not a specific pixel.
Hey [USER=“4894”] Hobson[/USER] ,
thank you so much for the response!
I think the most important thing for us users is consistency…and thats why its sometimes tricky with the engineer way as you can see with, for example, the auto exposure feature (which is quite unintuitive to use for now).
Personally, I think the two most important steps for now are:
- Make auto exposure use fstops and iso etc. like the camera does so they are in sync and make sense
- Enable a measuring viewmode that allows measuring the values across a certain screen area and not just pixels (whatever implementation would do)
This way 2 big problems would already be solved as you a) have consistency between the modes and b) you can measure and verify values on screen and make sure everything works nicely together
Those are…of course just my 2 cents!
Cheers,
Daedalus
Just wanted to give an update here that 4.21 is going to include some improvements requested here to hopefully reduce confusion and make things that much easier to use. You should be able to check them out in the 4.21 previews when they start soon!
Hopefully, I’ll be able to provide updates to the documentation before 4.21 release, if not, it’ll be shortly after! The release notes for 4.21 will have a lot of this information as well (in more detail)!
To give you an idea here is a short list of what’s been improved or added:
- Improvements for how we display Light Units and Light Intensities for Point, Spot, and Rect lights.
- Directional Lights now have Lux units
- Sky Lights now have cd/m2.
- Added Pre-Exposure support for the Pixel Inspector
- Added new Project Settings to increase auto-exposure luminance range.
- Updates for HDR visualization tools
Note that this is just a highlighted list and there are more details and context to a lot of these than provided here. The engineers have reviewed this thread and added these based on a lot of the detailed feedback here! There are still some areas that still require work to be done in terms of units (such as Lightmass Environment Intensity and Exponential Fog Scatter Color) that we’ll address in a future release.
Once previews and the final release are out, please let us know what you think!
This is great news! Thanks [USER=“4894”] Hobson[/USER]
Could you please give any update on aligning auto exposure to the camera values? This should be a simple fix as the values and settings already exist. I would argue that this is way more important than physicalizing the units of fog inscattering
Thanks and cheers!