Fellow Kerbonaut rextablesuggested on Forum two approaches to enhance the DarkenSky:
1) A multilayered Skybox with objects distributed per layer depending on their relative brightness. Three or four layers would probably do. Skydimming is then applied to each layer thus making the dimmest stars and objects disappear first and the brightest last by differing amounts as light levels increase and decrease in the players FOV. While I reckon this would be the ideal approach (short of rendering the entire fkin universe in 3D :sticktongue:) It would require a lot of photoshop work to create the texture files, not to mention the requirement of making the current skybox system able to handle multiple layers. This will also be incompatible with all other skyboxes... which would be somewhat antisocial and limit user uptake.
(this guy is nuts!!! :D I like it, but he's still nuts!!!)
2) The judicious application of filtering/blending/feathering in edition to or instead of overall gamma and/or opacity (as per currently in DEO). In other words, if dimming could be applied to the skybox on a per-pixel basis rather than globally, a slightly more 'realistic' dimming effect could be achieved. This would be a little more CPU intensive but no more so than applying a blend layer in photoshop because the KSP skybox is just a static image. This approach would also be compatible with existing skyboxes provided some tweakable parameters were accessible to dial in correct values to cope with varying RGB ranges. The stock skybox background is actually quite grey. Currently I'm using Rareden's skybox which has a far greater range of RGB values than stock. So as a user in switching between these two skyboxes, I need to be able to change some parameters to cope with these variations if you see what I mean.
This one is more feasible, but way more CPU intensive than the current approach, that just uses already existent features of KSP itself (the thing is pretty simpler, in the very end).
I think there's a third option:
3) Injecting a new layer immediately over the Sky box and create a transparency mask created from the histogram of the Skybox (to have a "luminosity map" to initialise the map - more pixels lightened together would have a opacity less aggressive than a group of fewer pixels - and this is made only once). This mask would so be combined with another one, a opacity map created from the current player's view perspective using the light emitters and current body, and none of these maps have to be in the same resolution of the SkyBox itself, what would save some memory and CPU juice while calculating the the final opacity mask. This would allow the same effect on item (2), but way more CPU effective.
The hard part of the thing is that is to justify the effort. The current approach is way minimalistic but yet effective ("good enough") - it uses two parameters already present on the SkyBox object, the maxGalaxyColor and the glareFadeLimit (this one not used, apparently some feature planned but not implemented - and it may help on a 4th way of implementing the stunt).
In a way or another, I need to watch some 4k videos where this phenomena is depicted before choosing an approach - Nature doesn't follows logic, after all. :)
Fellow Kerbonaut rextable suggested on Forum two approaches to enhance the DarkenSky:
(this guy is nuts!!! :D I like it, but he's still nuts!!!)
This one is more feasible, but way more CPU intensive than the current approach, that just uses already existent features of KSP itself (the thing is pretty simpler, in the very end).
I think there's a third option:
3) Injecting a new layer immediately over the Sky box and create a transparency mask created from the histogram of the Skybox (to have a "luminosity map" to initialise the map - more pixels lightened together would have a opacity less aggressive than a group of fewer pixels - and this is made only once). This mask would so be combined with another one, a opacity map created from the current player's view perspective using the light emitters and current body, and none of these maps have to be in the same resolution of the SkyBox itself, what would save some memory and CPU juice while calculating the the final opacity mask. This would allow the same effect on item (2), but way more CPU effective.
The hard part of the thing is that is to justify the effort. The current approach is way minimalistic but yet effective ("good enough") - it uses two parameters already present on the SkyBox object, the
maxGalaxyColorand theglareFadeLimit(this one not used, apparently some feature planned but not implemented - and it may help on a 4th way of implementing the stunt).In a way or another, I need to watch some 4k videos where this phenomena is depicted before choosing an approach - Nature doesn't follows logic, after all. :)