I’m not sure of what “optimism” you are even talking about, Composer.
My optimism. As in, I want it to be a possibility to happen, but I worry RTGI might be a factor, based on how the current systems work (if they're similar to Original Sin 2). I'm not too familiar with how you implement RT-features into an engine at a software level though. I'm not a tools engineer. I know how OS2 works and speculate if BG3 is using similar tech, and how RTGI works, but not how one would combine the two, in a way that would be compatible with how you'd approach making a day/night cycle for that environment, again assuming the systems are at all similar.
Like you, I really prefer "living, breathing" worlds rather than scene-based, more static worlds. From your description of the DOS2 design ( presumably from the tools they released ), Larian's engine is more scene-oriented. The simplest form of D/N cycle discussed earlier in the thread where you simply cut-scene from day to night and back again ( like BG2, for example ) would require implementation of rudimentary time-keeping in the engine, plus a night-time version of all outdoor above-ground map content ( assuming indoor and underground are unchanged ).
I can't judge how much extra work this would be as we have no idea of the total content in the game. But, on top of this change to the basic map content, there would need to be consideration of other asset duplication. Actor behaviour should/might be different between day and night, and dialog may need additional branches. The "knock-on" effects could be significant and potentially costly, and is probably the "complexity" Larian refer to. It would definitely have been better to design D/N in early!
As for implementing Ray-Traced Global IlIumination, I doubt that D/N cycle would affect it or be affected by it. Calculation of global illumination at any arbitrary point in a game scene is ( to the best of my knowledge ) usually a discrete calculation that can be replaced by an alternative discrete calculation.
Aside: For background, early 3D rendering on weak hardware just used a constant value for the "ambient" light in a scene to represent global illumination; this could vary with time of day, but not position within the world geometry. More recent renderers have used a variety of "occlusion" calculations to multiply the constant value for "ambient" light with a "percentage value" derived from examining how the geometry surrounding an arbitrary point blocks incoming light ( the various "Ambient Occlusion" settings you see in games, for example ).
Ray-Traced Global Illumination ( not the same as fully ray-traced rendering ) improves this by calculating the real amount of light from each light source that local geometry reflects
towards an arbitrary point, rather than the amount "ambient" light that is blocked.
