HTOD 1.2.2 - using of Unity 2023.3 and old non-fixed bugs

[Mad Stuntman]

Considering 2023.3 will get tech release status soon, I'm sure you must keep attention on compatibility HTOD with 2023.3

Installation.

I got some errors related to changes in Physically Based Sky API in HDRP 17.0.1. I can't complain about these errors, it is my own problem related to using of Unity alpha version, but it's a friendly warning about possible future problems.

Assets\Procedural Worlds\HDRP Time Of Day\Scripts\Core\HDRPTimeOfDay.cs(1660,78): error CS1061: 'PhysicallyBasedSky' does not contain a definition for 'planetCenterPosition' and no accessible extension method 'planetCenterPosition' accepting a first argument of type 'PhysicallyBasedSky' could be found (are you missing a using directive or an assembly reference?)

Assets\Procedural Worlds\HDRP Time Of Day\Scripts\Core\HDRPTimeOfDayVolumetricCloudPreset.cs(45,47): error CS1061: 'VolumetricClouds' does not contain a definition for 'earthCurvature' and no accessible extension method 'earthCurvature' accepting a first argument of type 'VolumetricClouds' could be found (are you missing a using directive or an assembly reference?)

Assets\Procedural Worlds\HDRP Time Of Day\Scripts\Core\HDRPTimeOfDayVolumetricCloudPreset.cs(140,24): error CS1061: 'VolumetricClouds' does not contain a definition for 'earthCurvature' and no accessible extension method 'earthCurvature' accepting a first argument of type 'VolumetricClouds' could be found (are you missing a using directive or an assembly reference?

Assets\Procedural Worlds\HDRP Time Of Day\Scripts\Core\HDRPTimeOfDayVolumetricCloudPreset.cs(240,20): error CS1061: 'VolumetricClouds' does not contain a definition for 'earthCurvature' and no accessible extension method 'earthCurvature' accepting a first argument of type 'VolumetricClouds' could be found (are you missing a using directive or an assembly reference?)

Assets\Procedural Worlds\HDRP Time Of Day\Scripts\Core\HDRPTimeOfDayProfile.cs(2390,72): error CS1061: 'VolumetricClouds' does not contain a definition for 'localClouds' and no accessible extension method 'localClouds' accepting a first argument of type 'VolumetricClouds' could be found (are you missing a using directive or an assembly reference?)

Finally, I just commented these errors above to avoid compilation errors and continue tests.

Good (really, not) old bug with exposure

The only thing I'm care now is old exposure bug. If you have your own spotlights, point lights, or area lights, they become invisible in the night with their current normal values of emission. For make light emission visible, you need to multiply normal values on 1000. This isn't an acceptable solution because HTOD is a little part of the game and NOT A CORE ASSET. This bug was reported many times before, and you did nothing to make asset which costs 60 bucks work correct without breaking of normal workflow (normal emission values).

I really like how the other features works, but this bug doesn't allow me to use HTOD in my project because I have huge amount of additional lightings in night urban environment, and I'm not ready to change correct emission values in my prefabs.

[Peter]

Hi @Mad Stuntman, sorry about the delayed reply! 

Thanks for the heads-up about the current unity alpha. We usually take a look at the compatibility close to or after the full release of the new editor version - otherwise we need to "look into it" multiple times, and there have been cases where issues / errors were bugs in the unity alpha / beta rather than compatibility issues. 

Regarding the exposure issue: I assume you did install the latest HDRP TOD version 1.2.0? Because in there the default lighting setup has been overhauled so that the lumen values should be closer to their real-world counterpart. We added a flashlight in the demo scene at 1200 lumen (which is about something you would have on a small modern flashlight) that you can test:



(The screenshot was taken at a time of 0:00 with the "Darker Nights" option enabled.) You could now argue that this should be a bit brighter still because HDRPTOD also applies post processing and a lot of other effects, but this is far off from having to multiply with 1000 as it was before.

I have tried to take that same flashlight as a prefab and put it into a pitch black scene, without any other lighting, probes, etc. the light is indeed quite a bit brighter:



But this is with a moonlight of 1 lux as soon as I adjust the moonlight to 250 lux like in the demo scene it gets closer to that scene again:



I hope this visualizes a bit that this is not just a bug in the code where we need to fix a certain math error, but rather the perceived brightness of a light source is dependent on all the other factors in the scene. And we are not only trying to accomplish that the lumen values of the light sources are as close to real life as possible, but also that we got a nice artistical result as well where e.g. the scene does not get fully dark at night so that we can still see something for gameplay reasons.
Please also note that with the asset you can influence all relevant factors of the lighting setup yourself, e.g. if you think that the moon should not be as bright to have darker nights & brighter lights in return, you can adjust the intensity accordingly.

Here is a similar discussion from the unity forums without involving HDRP TOD that illustrates why this is so difficult to get right, especially the comments from unity staff are insightful.
https://forum.unity.com/threads/exposure-and-light-in-hdrp-how-to-manage-unreasonably-bright-and-dark-areas.1208596/

I hope that with the improvements of the latest versions you can get better results and you get an idea why this is not something that can be "fixed" easily, because any fix would impact other settings of the lighting setup that would then influence other users again. 

[Mad Stuntman]

Hello Peter! Thanks for your answer but unfortunately, I bored listen the same explains almost a year. So my answer will not be absolutely polite. Sorry in adavance...

I'm using the latest version 1.2.2, and I could believe all your explanations or read the answers of Unity employees to questions from people who do not understand how lighting works at all and explain the basics to them. 1200 lumen corresponds to a ceiling lamp, which is enough to illuminate a very large room, so the light source in the first screenshot is very dim.

In the second screenshot, the light source looks almost as it should. Moon emission typically ranges from 0.1 to 1 lux, where 1 lux is the illumination from a full moon in a cloudless sky. The value of 250 lux is a lot. The thermal temperature of the moon is 4100 Kelvin, not 6500. I guess that HTOD sacrificed realistic lighting for the sake of artistry, which led to side effects 🤨

This is not just my guess, because I have created my own lighting system, that does not have the disadvantages of HTOD. I have no side effects with any other lighting sources, no problem with realistic dark nights. There are also no issue with simplified calculations of the positions of celestial bodies. Some people may not have noticed, but your calculations of the sun position are valid only for LAT 0.00, LONG 0.00 in the UTC time zone. Therefore, regardless of the date and season, sunset is always around 6:20PM 😁

Overall, I understood your point, so thanks for the great weather particle systems and sounds. Unfortunately, this is all I can get from your asset in its current state. The video below shows how the moon looks at 1 lux and how a 1200 lumen light source looks with the same parameters as in your demo scene. As well as dark how nights looks like in areas far from cities, fulfilled of additional sources of ambient lighting. Despite the night looks pretty dark, you can see both the player and the environment quite well. All of the above is exactly what I expected to get from HTOD, but did not get.

https://www.youtube.com/watch?v=v12LtDAi224
• Location parameters: LAT 50.45466, LONG 30.52381 UTC +3.
• SSGI, SSR and SSAO are active. 
• Exposure set to Automatic Histogram with default parameters.