Yep, for anything non-metal 1-kd seems to make sense.
I've done quite a few tests at my end now using my polariser out on wet roads, dry roads, and general materials and 1-kd seems to give the right result!
In Racer specular == diffuse curve values. I believe I asked that specifically of Ruud at the time because specular are borne from the diffuse intensity.
However on reflection it's perhaps not ideal because as we get more diffused specular (softer reflections), we reflect not just the sun itself (which is white), but also the large orange bloom around it from the suns scattering with the atmosphere especially at dusk/dawn!
I'm not sure what the best solution is. If you take photos at dawn/dusk when the sky is orange, the main 'diffuse' still looks white on a white object, but reflections that are diffused (glancing reflection on brick walls or asphalt for example) are clearly influenced by the orange in the sky as much as the white sun spot.
Perhaps 1-kd will fix that a little bit without many other changes, but there is probably some strong maths underneath this that is important and without understanding the shaders Ruud has programmed I don't think it's my place to tinker too much here as I might get the right result for the wrong reasons or vice versa!
As per the curves, the ones I hosted a long time back for sunny/overcast were specifically set for the given Lat/Long and date/time, and they used IES values directly from the architectural lighting analysis part of 3DS Max, so I expect they are quite 'ok'
They seem to work nicely in Racer.
But that is the issue, they are tied to a specific date/time/lat/long. As soon as we move a tiny bit then sunrise/sunset change in the time axis, and then the sun height may change and get too intense at midday etc.
Obviously the extreme example is a polar location where it can stay daytime, but only just, for many months... obviously a set of TOD curves wouldn't work there at all!
So really TOD curves are useless unless you adhere to the authors lag/long/date/time etc... deviate and it breaks in a cascade effect through all your other settings. Trying to set up shaders/effects on 'bad' tracks is just a nightmare as you don't know what is reacting right or not.
What I think is a really valuable exercise and one I need to undertake, is to take actual photos and generate HDR's, and then work out how to get the KLux values read off them. I assume a properly calibrated camera/hdr build in photoshop is accurately metered so perhaps there is a way to do it there.
Then in theory you can 'copy' the scene as you see it into Racer, and then check kLux intensities till they match!
But you also raise an interesting question about white balance. IRL colour balance is amazingly wide, but we obviously flatten this with our TOD curves somewhat.
The mie/ray sky on the other hand doesn't white balance itself and can appear as a very strong blue colour without the sun, yet with our balanced TOD curves the impact of the deep blue sky isn't apparent in the ambient impact on materials.
Ie, set sunny=0 and the sky is a deep blue, but then check a matte white object and it looks light grey, not deep blue.
Another argument imo for coherency between the values. Imo that should be done by having the live envmap, or a version of it, poll the scene every 50 frames or so and determine the appropriate diffuse/ambient/specular values to use to light the scene. That way as the TOD changes and the sun sets, then the diffuse/ambient values 'auto' set themselves through to black as the sun finally goes below the horizon.
If the day is cloudy then the diffuse is automatically lower and the ambient setting higher.
You could even detect dynamic range (look for the maximum contrast?) and use the shadow filtering to soften or sharpen the shadows on hazy or very clear days.
This works and we use it all the time in arch vis and other renderings, even for VFX, by using environment probes to create the appropriate scene lighting. We generate our own scene environment in HDR with the mie/ray sky so it seems crazy not to use the values it generates, they will surely then create diff/amb values that match accurately the sky
The only one factor I can't think how we would set is the sun intensity value which seems to scale the overall sky brightness. I guess this is one case where just getting data at certain lat/long/dates and conditions is essential and then build up a table, and match it in Racer...
I'm guessing it's just proportional to sun elevation.
It's also easy to check intensity with an SLR. Iirc they meter for grey point at 2 stops down from white.
So you meter into the blue of the sky and add exposure comp to + 2, and then use those camera settings to calculate out the Klux.
Ooor, you can just adjust after doing the calc.
There was a nice little app on the iPhone that did this, you could even take a photo with the stats and add the compensation on too, so it had a picture showing what it looked like and also the kLux value!!!
Stupid thing was people were using it to measure incident light kLux rather than reflected, so they REMOVED the functionality. Duhhh... some people actually wanted to use it for reflected light intensity! (probably graphics people
)
So I'm back to SLR and taking notes and doing calculations but it's good as I have a really high quality reference picture too (and if you do the old polariser trick too a nice reference of the spec map or 1-kd map you want to have!)
Thanks
Dave