[KSP >= 1.3.1] Distant Object Enhancement (DOE) /L - Under new Management - 2.2.0.2 - 2024-0803

[Lisias]

As from 2021-0930 and under @TheDarkBadger agreement, I'm the New Management forDOE. From now on, it's all officially my fault! (again)

In a Hurry:

• Current Release:  2.2.0.2 for KSP >= 1.3.1 (2024-0803)
  • Works from KSP 1.3.1 to 1.12.5.
    • really!  
  • IMPORTANT
    • read this post before updating!
      • Announce for 2.1.0.0.
      • (2.1.1.1 to 2.1.1.4 were experimental releases)
      • Announce for 2.1.1.5.
      • Announce for 2.1.1.6.
      • Announce for 2.1.1.7.
      • Announce for 2.1.1.8.
      • Announce for 2.1.1.9.
      • Announce for 2.1.1.10 (Experimental).
      • Announce for 2.1.1.11.
      • Announce for 2.1.1.11r2.
      • Announce for 2.1.1.12.
      • Announce for 2.1.1.13.
      • Announce for 2.1.1.14.
      • 2.1.1.15 wasn't announced.
      • Announce for 2.1.1.6.
      • Announce for 2.2.0.0.
      • 2.2.0.1 was withdrawn.
  • Downloads
    • on GitHub (and KSP-AVC users).
    • on CurseForge .
    • on SpaceDock .

Spoiler

• Older threads on Forum:
  • Previous, by TheDarkBadger
  • Previous' Previous, by MOARdV
  • The First One, by Rubber Ducky
• Project:
  • Source: on GitHub
    • From 2.1.1.x and newer, DOE/L is DOUBLE LICENSED:
      • SKL1.0 License
      • and GPLv2 too 
      • and the user is allowed to choose the license that best suits his needs:
        • The SKL grants you essential rights for binary use and redistribution. Non revokable but restricted for use and redistribution.
        • GPLv2 grants you additional rights when applicable.
    • Older versions, from 2.0.3.0 and older, are available under:
      • CC-BY 4.0i
  • Change Log.
  • Known Issues Mandatory Reading
  • Issue Tracking (You can check what I'm doing here!)

Description:

Distant Object Enhancement /L  is a visual enhancement mod that makes objects realistically visible over large distances.

BASIC FEATURES

• Flare effects for planets and nearby satellites, properly calculated by size, distances, phase angle, etc.
• Flare effects are colored for each planet, which makes for easy identification.
• On-rails vessels up to 750km away are visually rendered (no intensive physics calculations necessary)
• Background stars dim when looking at the bright surface of a nearby planet, just like in real life!
• If you have blizzy78's Toolbar plugin, a settings window is available with several options to improve performance or tweak visuals.
• Full compatibility with custom planet mods -- with flare color definitions included for Real Solar System, PlanetFactory, and Alternis Kerbol.

 

 

It is the follow up from TheDarkBadger's Distant Object Enhancement Continued, that by itself  is the follow up of MOARdV's Distant Object Enhancement bis, which is the follow up of Rubber Ducky's Distant Object Enhancement.   Support: I need help in order to proper help you.  Open the spoiler for instructions about how to get support: Spoiler Please provide: A concise, textual description of the problem Mentioning the KSP version and the TweakScale version involved A screenshot of the problem When applicable, the .craft file with a vessel that have the problem When asked, the KSP.log and output_txt log from Unity. See this article for instructions. The Player.log changed location: On MacOS For KSP < 1.8, they are on ~/Library/Logs/Unity On KSP >=1.8, you will find the Player.log on ~/Library/Logs/Squad/KSP/ On Windows On KSP >=1.8, you will find the Player.log on C:\Users\<USERNAME>\AppData\LocalLow\Squad\KSP\ On Linux On KSP >=1.8, you will find the Player.log on ~/.config/unity3d/Squad/KSP/ Publish the files on DropBox, Google Drive or similar, and post the link so we can inspect it. DO NOT paste the log on Forum, this causes a lot of problems and it's useless, as Forum also truncate the file It's ok to paste small excerpts to pinpoint something, but we still need the full KSP.log and Player.log in order to help you/ Do not use pastebin, gist or similars. They have a pretty small cap on the file size, and will truncate the log rendering yet more useless Imgur is a good choice for publishing screenshots when needed. Using the Issue Tracker is highly encouraged, as GitHub provides services that make everything above easier. You can open an issue there, and call me here pinpointing there to be sure to get my attention. Thank you.

Edited August 3 by Lisias
Release 2.2.0.2 in on the wild! All your Distribution Channels are belong to us!

[Lisias]

ANNOUNCE

Release 2.1.0.0 is available for downloading, with the following changes:

• Preliminary version under Lisias' Management
• No new features or bugfixes. Yet.

See  for the links.

— — — — —

This Release will be published using the following Schedule:

• GitHub. Right Now.
• CurseForge. Right Now.
• SpaceDock. Right Now.

The rationale for the scheduling is to avoid confusion by publishing things into the Mainstream without proper announcements.

Edited October 8, 2021 by Lisias
Distribution Channels are up to date.

[Lisias]

NOTAM

The first session of hard coding is finished - I have extracted the "Mesh Engine" into a reusable component, and now DistantObject is not only easily extensible (i.e., you can add support for new Modules without recompiling the thing!), but also reusable on 3rd parties add'ons.

Additionally, KSP down to 1.4.5 is guaranteed to work now - so it will run fine from 1.4.5 to the latest 1.12.2 .

Support for KSP 1.3.x is feasible, I need to solve one small API glitch. Once I tackle this down, we will have full support from 1.3.0 to 1.12.2 (I may try 1.2.2 just for fun if I find time!!).

The next step is to work out support for ReStock. Preliminary researches suggest that, well, ReStock does not uses anything "fancy" - it merely add many MODEL sections, each one with the mesh for a part of the part (pun not intended!). So, by example, ReStock can reuse the top and the bottom parts of a fuel tank into another one with the same bulkhead, but taller.

The implementation appears to be straightforward.

Spoiler

Stay tuned, an Experimental Release is on the works!

— — POST EDIT — — 

Yep, it was simple like that. KSP 1.12.2 with ReStock is working now:

ReStock, however, is pretty heavy on my machine. The performance was abysmal. I think I'm abusing the VRAM of my GPU, perhaps I should activate the MIPMAP for these textures?

In a way or another, a Experimental Release is being cooked.

Edited October 1, 2021 by Lisias
tyops… always tyops...

[Lisias]

ANNOUNCE

Release 2.1.1.0 EXPERIMENTAL is available for downloading, with the following changes:

• Über refactoring
  • Creating a shareable MeshEngine
  • Decoupling PartModule details from the Engine
    • Now it can be extended by creating new DLLs, instead of recompiling the thing!
• Adding (preliminary) support for ReStock
  • To tell you the true, just a more thoughtfully implementation of Stock MODEL sections.
• Official support from KSP 1.4.5 to 1.12.2

Downloads exclusively on the GITHUB (pre) release page. The OP (and the master branch on GitHub) will not be updated.

Your Attention please!!

THIS IS AN EXPERIMENTAL RELEASE. Besides nothing serious is expected (as this thingy does not changes anything on Parts, Crafts or Savegames - it's a visual only plugin), really serious performance issues were detected on weaker rigs when ReStock is installed.

Proceed with discretion (and care), do not use this on valuable savegames - you know, sheet happens.  

Please remember to completely delete the GameData/DistanceObject folder before updating!!!

— — — — —

This Release will be published using the following Schedule:

• GitHub. Right Now.
• CurseForge. Will not be updated, this is an experimental release.
• SpaceDock. Will not be updated, this is an experimental release.

 

Edited October 1, 2021 by Lisias
missed a warning.

[Lisias]

ANNOUNCE

Release 2.1.1.1 EXPERIMENTAL is available for downloading, with the following changes:

• Huge performance improvements!

Downloads exclusively on the GITHUB (pre) release page. The OP (and the master branch on GitHub) will not be updated.

Your Attention please!!

THIS IS AN EXPERIMENTAL RELEASE. Besides nothing serious is expected (as this thingy does not changes anything on Parts, Crafts or Savegames - it's a visual only plugin), really serious performance issues were detected on weaker rigs when ReStock is installed.

Proceed with discretion (and care), do not use this on valuable savegames - you know, sheet happens.  

Please remember to completely delete the GameData/DistanceObject folder before updating!!!

— — — — —

This Release will be published using the following Schedule:

• GitHub. Right Now.
• CurseForge. Will not be updated, this is an experimental release.
• SpaceDock. Will not be updated, this is an experimental release.

[Lisias]

ANNOUNCE

Release 2.1.1.2 EXPERIMENTAL is available for downloading, with the following changes:

• Preventing some borderline situations to throw Exceptions on the MeshEngine
• Some more performance fixes
• Small mistakes corrected

Downloads exclusively on the GITHUB (pre) release page. The OP (and the master branch on GitHub) will not be updated.

Your Attention please!!

THIS IS AN EXPERIMENTAL RELEASE.

Besides nothing serious being expected (as this thingy does not changes anything on Parts, Crafts or Savegames - it's a visual only plugin), not all features are working as I would like.

Proceed with discretion (and care), do not use this on valuable savegames - you know, sheet happens.  

Please remember to completely delete the GameData/DistanceObject folder before updating!!!

— — — — —

This Release will be published using the following Schedule:

• GitHub. Right Now.
• CurseForge. Will not be updated, this is an experimental release.
• SpaceDock. Will not be updated, this is an experimental release.

[Lisias]

News from the Front

This is where we are now:

• Most (if not all) Stock parts works.
• At least some parts from ReStock works.
• A few parts of FireSpitter and/or KAX do not works.
• As the distance from the viewer grows, the precision in which the meshes are drawn plummets dramatically - it's entertaining sometimes.
• Performance is better, even by using ReStock on my puny MacPotato  
  • Apparently things start to drag their feet on my machine when the PQS kicks in - there's something on drawing the terrain on a higher level of quality that renders my rig on its knees.
• I think I introduced some hiccups when the viewable crafts enters into the viable zone (as I destroy everything when they are leaving the viable zone to save memory - you know, some people have a lot of crafts around)
  • If this starts to get annoying to you, you may want to Render only the Targeted Craft.
  • I think there's a way to minimise this at expense of delaying the visualisation of the craft, but I will run away on this to fight it another day.  
• Using the Stock SAS to stabilise a Satellite equiped with a Tarsier Telescope is a challenge.

The only thing that it's bothering me now is the parts not being rendered. I failed to understand why at this moment.

The ReStock's Stayputnik is one of these parts that are not rendered, besides the Stock one renders fine. Curiously, some FS and KAX parts didn't rendered neither.

So I instrumented the code to tattle the offending parts by name on initialisation, and, by my surprise, with this code active some of the missing parts started to show (as KAX) while others that were showing fine didn't. 

So I'm considering that perhaps this is not an error on the code itself (neither the parts), but on how to instance Meshes to be used - I may be failing to do something needed to make fetching the meshes from the GameDatabase reliable (or perhaps blowing up my VRAM capacity?). In a way or another, the last Experimental release is the best I can offer by now, and I considering releasing it on the mainstream next week.

Currently, I'm working on understanding some current deployment decisions to allow a seamless transition on CKAN - I don't know (yet) what's the CKAN's "filter" thingy currently used by DOE, and I'm afraid of breaking something if I change it before doing it. I have some different ideas on how to support different planet packs, so I plan to phase out the "filter" thingy as long as I learn how to prevent breaking things on the wild by removing it.

Cheers!

 

Edited October 2, 2021 by Lisias
tyops! Surprised?

[Lisias]

ANNOUNCE

Release 2.1.1.3 EXPERIMENTAL is available for downloading, with the following changes:

• New Render Mode to allow smooth transitions at the cost of memory.
  • Vessels are not removed from the cache, unless destroyed
  • May use a lot of memory!
• Option to show the names of all visible bodies
  • Use <ALT> while RightClicking the mouse.

This is the last feature release - from now on, just bug fixes (if any - famous last words! ).

If no bug report is filed, this is what will be the next release to be published on the mainstream next week, including SpaceDock and CurseForge!

Downloads exclusively on the GITHUB (pre) release page. The OP (and the master branch on GitHub) will not be updated.

Your Attention please!!

THIS IS AN EXPERIMENTAL RELEASE. Being a visual only plugin, no nasty effects are expected, and the current features are working fine (most of the time!  ).

However, keep proper backups when using this, sheet happens after all!  

— — — — —

This Release will be published using the following Schedule:

• GitHub. Right Now.
• CurseForge. Will not be updated, this is an experimental release.
• SpaceDock. Will not be updated, this is an experimental release.

Edited October 4, 2021 by Lisias
Famous last words! :D

[Lisias]

ANNOUNCE

Yeah, yeah, I know I said 2.1.1.3 was the last. I lied.

Release 2.1.1.4 EXPERIMENTAL is available for downloading, with the following changes:

• Some adjustments while handling the vessel's Life Cycle on VesselDraw.
• CPU savings on DarkenSky and FlareDraw.
• Another huge performance enhancement on VesselDraw!

If no bug report is filed, this is what will be the next release to be published on the mainstream next week, including SpaceDock and CurseForge!

Downloads exclusively on the GITHUB (pre) release page. The OP (and the master branch on GitHub) will not be updated.

Your Attention please!!

This experimental release is essentially a Release Candidate. I think I finally nailed it.

However, keep proper backups when using this, sheet happens after all!  

— — — — —

This Release will be published using the following Schedule:

• GitHub. Right Now.
• CurseForge. Will not be updated, this is an experimental release.
• SpaceDock. Will not be updated, this is an experimental release.

Edited October 3, 2021 by Lisias
Pics, or it didn't happened!

[zer0Kerbal]

glad you adopted this! thank you!

[Spaceman.Spiff]

Amazing! So happy that this mod is getting the love it deserves!

[rextable]

Glad to see Mr Lisias is maintaining/updating this mod :-)

I don't suppoooooooose..... while you're making improvements to the mod good sir, you might consider looking at a couple of longstanding minor shortcomings would you?

(1) Flares don't play nicely with Scatterer atmospheres. I don't know if it's a blending or layering thing or what. The 'problem' is particularly noticeable when orbiting Jool. cilestial body flares look very weird as they rise and set through the scatterer atmosphere. Try it - you'll see what I mean. It's a very minor thing but it'd be great if was sorted out. I did mention this to Blackrack long ago but his give-a-s@%t-o-meter didn't even twitch . It might be something that you can address.

(2) Finesse of the skydimming feature.  I luuuve this feature! However it would be great to have some more control other than just the skybox maximum brightness. Maybe a sensitivity and/or radius + feather controls??? This is  only really required when Scatterer is installed because it makes celestial bodies with atmospheres and Kerbol appear much brighter to the player. The brightness added by Scatterer (and be extension Sunflares of Maar) is seen by the player but presumably not by the skydimming algorithm. This very noticeable when orbiting Kerbin. Kerbol can be fully on screen and the skybox will still be visible. It's only when you aim the camera directly at Kerbol that the skybox dims completely. This same phenomena occurs with any atmospheric body that isn't dead center of the screen (while in high orbit or during transfer).  As already stated, with the Stock Kerbol, this phenomena is far less pronounced. It's only when Scatterer + Sunflares of Maar are installed that is becomes a noticeable shortcoming. If there was radius and feather controls for how sky dimming algorithm interprets bright object on the screen, players (with their infinitely varied mod installs, tastes and preferences) could tailor when and by how much the skybox is dimmed to their liking.   

 

If you have the time and are so inclined to investigate these things, I for one would be most appreciative of it 

[Lisias]

On 10/4/2021 at 7:29 AM, rextable said:

Glad to see Mr Lisias is maintaining/updating this mod :-)

I don't suppoooooooose..... while you're making improvements to the mod good sir, you might consider looking at a couple of longstanding minor shortcomings would you?

[…]

If you have the time and are so inclined to investigate these things, I for one would be most appreciative of it 

THIS is what I'm talking about!

Thanks for the feedback! I can't say when I will try to tackle these down (and once I try it, if I will be able to effectively fix it), but I will not forget your suggestions: https://github.com/net-lisias-ksp/DistantObject/issues

Right now, I'm inclined to close this development cycle and make a release, as I already have a nice feature set to be published - and I have some others urging issues on TweakScale I want to tackled down yet this week.

But I can assure you I will go back to DOE soon enough - I have some interesting ideas to implement too, and they are itching on my brain on sleep time…  

Cheers!

Edited October 5, 2021 by Lisias
of cousre, a tyop!

[rextable]

17 hours ago, Lisias said:

THIS is what I'm talking about!

Thanks for the feedback! I can't say when I will try to tackled these down (and once I try it, if I will be able to effectively fix it), but I will not forget your suggestions: https://github.com/net-lisias-ksp/DistantObject/issues

Right now, I'm inclined to close this development cycle and make a release, as I already have a nice feature set to be published - and I have some others urging issues on TweakScale I want to tackled down yet this week.

But I can assure you I will go back to DOE soon enough - I have some interesting ideas to implement too, and they are itching on my brain on sleep time…  

Cheers!

Ha. And there I thought I was being too demanding. I'm glad you met my ideas with enthusiasm. The issues I mentioned really are very minor though, so please don't loose sleep over it . Yes - go for the release - I look forward to testing it 

[rextable]

Dude I just had a fanciful idea! It's probably well beyond the scope of simply modifying DOE but I thought I'd mention it anyway. Ya never know - it might inspire you.

It occurred to me that currently, DOE dims the entire skybox uniformly and it does so by changing the gamma or opacity values... right? Meaning that all objects on the skybox textures - regardless of their perceived brightness -  are dimmed informally. The result being that the brightest/largest objects appear dark grey rather than shrinking to tiny points before disappearing entirely. 

In the real world, other stars, nebula and galaxies (or parts thereof) are brighter than others and so some stars would remain visible longer than others as light levels in the FOV increase. Look up at the night sky from a city and one might see the Orion constellation. Look up from a field in the countryside and you'll see Orion and the Milky Way galaxy. Look up from atop a mountain in Chile and you will see Orion, the Milky Way galaxy and much else besides.... You get my point. 

The long and the short of it is: everything on the skybox texture is dimmed by the same amount, everywhere! 

Possible Methods to improve this could be....????

(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 ) 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.

The following option would be more doable.... I reckon .

(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.

 

.......

 

Anyway.... probably pie-in-the-sky fanciful nonsense but there it is. Feel free to ignore me :-) 

 

 

::::::::::::::::::::::::EDIT:::::::::::::::::::::::

If by some incredible miracle you were inspired to tinker with this, I'd love to help you test and can bring my not inconsiderable photoshop skills (from having been a professional photographer IRL) to bare if needed. 

Edited October 5, 2021 by rextable

[Lisias]

17 hours ago, rextable said:

Anyway.... probably pie-in-the-sky fanciful nonsense but there it is. Feel free to ignore me :-) 

I tried.  https://github.com/net-lisias-ksp/DistantObject/issues/7

But now I have a problem: I have other tasks and duties, and diverting man-hours from these tasks to it now sounds counter-productive on the big picture.

The nasty motherf…. uh… the project manager in me tells me to carry on these other tasks, as they are way more needed than this one.  

And there're also the bugs. Just fixed another one on an add'on I was using while testing this one..  - bug fixing always come first, as these ones propagates as rabbits on the code as time goes by.  

Kerbal proposes, Kraken disposes...

Edited October 6, 2021 by Lisias
Hit "save" too soon.

[rextable]

10 hours ago, Lisias said:

I tried.  https://github.com/net-lisias-ksp/DistantObject/issues/7

But now I have a problem: I have other tasks and duties, and diverting man-hours from these tasks to it now sounds counter-productive on the big picture.

The nasty motherf…. uh… the project manager in me tells me to carry on these other tasks, as they are way more needed than this one.  

And there're also the bugs. Just fixed another one on an add'on I was using while testing this one..  - bug fixing always come first, as these ones propagates as rabbits on the code as time goes by.  

Kerbal proposes, Kraken disposes...

Hairymuff :-) 

re your guithub comments: I agree the current method looks pretty good most of the time and is "good enough." I've got all the graphics mods in the universe (including DOE)  going on my latest playthrough and I keep marveling at how great the game can look. As for the effort required to improve DEO's skydimming; it comes down to whether you think it'd be an enjoyable project or not.  Only you can answer that question.

......

Oooooh.... .... I Just had a brainwave about a 4th possible way:   What about the existing DOE flares???? They're already integrated to respond to skydimming aren't they? Couldn't you create a handful of ghost flares and dot them around the sky to simulate nearby stars? you wouldn't need that many, nor would it matter if they didn't match the exact location of pixels on any one skybox. This method would save having to create an entirely new system from scratch. you just have to repurpose an existing one.  . It wouldn't 'fix' the shortcomings of the existing skybox dimming but it might mitigate them.  

[Lisias]

2 hours ago, rextable said:

it comes down to whether you think it'd be an enjoyable project or not.  Only you can answer that question.

It will be interesting for sure. But being enjoyable is not enough, I need to have time available in order to enjoy doing this code without harming the other projects, as the consequences would be more than unpleasant.

As the bug I just caught on that add'on I mentioned. Had someone already fixed it, I would not have to do it myself now. And so I would have more time available for doing enjoyable stuff.

“Freedom " (and this includes freedom in Software) " is not an individual effort. Yours comes only when you grant others theirs.” - Aragonés, Sergio.

 

2 hours ago, rextable said:

Oooooh.... .... I Just had a brainwave about a 4th possible way:   What about the existing DOE flares???? They're already integrated to respond to skydimming aren't they? Couldn't you create a handful of ghost flares and dot them around the sky to simulate nearby stars? you wouldn't need that many, nor would it matter if they didn't match the exact location of pixels on any one skybox. This method would save having to create an entirely new system from scratch. you just have to repurpose an existing one.  . It wouldn't 'fix' the shortcomings of the existing skybox dimming but it might mitigate them.  

That would create a new problem harder to cope with - currently, the flares are being visible trough atmospheres, and doing that would multiply the problem by thousands. Right now it's just an small annoyance, and the incidence of this problem is low enough to allow me to delay tackling down this one for some time. But in order to pursue this 4th idea, I would need to fix this one first, or I will create a (now very annoying) old new problem..

Not to mention that handling hundreds of additional flares is more GPU intensive than just dimming (or masking) the SkyBox.

[jefferyharrell]

What you really need is a high-dynamic-range skybox. But I can't imagine a way to implement that.

[rextable]

1 hour ago, jefferyharrell said:

What you really need is a high-dynamic-range skybox. But I can't imagine a way to implement that.

By 'high dynamic range' you mean greater than 0 - 255 as per RGB? The trouble is that the real life starry sky isn't exactly high dynamic range. Mostly it's dark and, really dark .  I know the stock skybox is really grey. Have you looked at Rareden's Real Skybox? It is properly dark - as in RGB values of 0,0,0, -  and the stars very bright. It's the closest thing - readymade - that you're looking for. Without DEO it looks ridiculous cuz the stars are waaaaay to bright, but with DEO's maximum brightness set to about 20 it looks very not-too-bad indeed. 

Edited October 6, 2021 by rextable

[jefferyharrell]

6 minutes ago, rextable said:

By 'high dynamic range' you mean greater than 0 - 255 as per RGB?

Yeah. HDR images can have pixels that are brighter than the maximum brightness of SDR images. Like if 255 in 8-bit RGB corresponds to 1.0 in 32-bit float, you can have pixels with values above 1.0 — 2.0, 10.0, whatever. That means if you take an HDR image and bring the exposure down (as per sky dimming) the brighter-than-bright pixels will stay bright as the rest of the image darkens. But I don't even know if KSP supports HDR skyboxes. If it were possible somebody probably would've done it by now.

[rextable]

4 hours ago, jefferyharrell said:

Yeah. HDR images can have pixels that are brighter than the maximum brightness of SDR images. Like if 255 in 8-bit RGB corresponds to 1.0 in 32-bit float, you can have pixels with values above 1.0 — 2.0, 10.0, whatever. That means if you take an HDR image and bring the exposure down (as per sky dimming) the brighter-than-bright pixels will stay bright as the rest of the image darkens. But I don't even know if KSP supports HDR skyboxes. If it were possible somebody probably would've done it by now.

I reckon It's safe to assume KSP does not support HDR anything.  Yes - a 32bit pipeline would be the 'ideal' solution. But we're talking about modding someone else's mod of a 12 year old game .... and Lisius's sanity should probably at least be considered . I reckon a lot can be achieved in the 8bit realm.  I'm talking about modest improvement, not glorious perfection here .

Edited October 6, 2021 by rextable

[Lisias]

12 hours ago, jefferyharrell said:

What you really need is a high-dynamic-range skybox. But I can't imagine a way to implement that.

I do by using a "weight" mask - a grayscale bitmap where each pixel would be used to sum the weight of the respective pixel on the skybox - essentially:

 skybox[x,y] = max(255, dim_factor[x,y] * skybox_source[x,y] + weight_map[x,y])

But I think the same result would be accomplished easier with my "3rd option" above. An opacity map, at a lower resolution to save memory and CPU/GPU juice, being drawn one layer above the skybox. Without light sources hindering the sight, this layer would have a 100% transparency, and the transparency would be decreased as the skybox need to be darken.

The nice thing about this solution is that you can precalculate this shadowing_mask using the original skybox and weighting the mask using the brightness of the source pixels of a respective shadowing_pixel. It's like transforming a hires 1 bit image into a lores 4 or 8 bits grayscale - the number of lit pixels on a 4x4 (1 to 4 bits) or 8x8 (1 to 8 bits) box will give you the value of the grayscale. Then negate the value of that pixel for the mask.

This shadow_mask, once it starts to be applied, will fade the skybox but not uniformly.  Clusters of lit pixels on the skybox will fade slower than small groups of lit pixels due the shadow_map.

Additionally, you can brute force regions of the shadow_map were you want the influence of the brightness of the sun and from the body you are orbiting, so the fade is more aggressive as large portions of the body is on the line of view (or when the star in visible). But that would be a bit computing intensive because you would need to recompute this brute force approach for every frame (and use some trigonometry and projections), being the reason the shadow_map must be on a lower resolution than the skybox (but not to extend in which people would perceive it).

I think this can be easily prototyped using Python, numpy and Pillow - way faster to check the visual outcome than rebooting KSP all the time.

 

11 hours ago, rextable said:

Have you looked at Rareden's Real Skybox? It is properly dark - as in RGB values of 0,0,0, -  and the stars very bright. It's the closest thing - readymade - that you're looking for. Without DEO it looks ridiculous cuz the stars are waaaaay to bright, but with DEO's maximum brightness set to about 20 it looks very not-too-bad indeed. 

I didn't knew about it. Dude, what a show my skybox became! Excellent tip!

 

8 hours ago, rextable said:

I reckon It's safe to assume KSP does not support HDR anything.  Yes - a 32bit pipeline would be the 'ideal' solution. 

Since 5.4 Unity has support for HDR. So it's feasible, but this would probably need to reimplement the GalaxyCubeControl. What perhaps would not be that hard, but replacing the stock one without breaking everything may be a bit harder.

But there's a draw back on this approach: I would need someone to rework the skybox. My approach above would reuse whatever is the skybox in use at the moment, and this is way more flexible IMHO.

 

8 hours ago, rextable said:

But we're talking about modding someone else's mod of a 12 year old game .... 

Modding an 12 years old game, IMHO, is where the fun really is! KSP2 (by example) will not need such a stunt, so if you want to sink your teeth on the matter, going back to older games is the way to go.  

 

8 hours ago, rextable said:

and Lisius's sanity should probably at least be considered .

There's none left.  (I'm the TweakScale guy, remember? That one that made KSP-Recall too!)

 

8 hours ago, rextable said:

I reckon a lot can be achieved in the 8bit realm.  I'm talking about modest improvement, not glorious perfection here .

As a matter of fact, it may be even more fun doing things the 8 bit way. The feeling of accomplishment is bigger - doing the same thing everybody else already made is the best learning tool available, no doubt, as the feeling of being able to do it is nice.

But the feeling of accomplishment really kicks when you score a stunt that nobody did before, like this:

Spoiler

I'm from that days. I got one of these machines - you don't have the slightest clue about the feeling of finding a FTP site where someone had uploaded some .VOC files (8 bit mono sound format used by MS-DOS programs supporting SoundBlaster) sampled from Star Trek (I still remember it!).

And now some crazy dude says me that my machine of that era could do it!!  )

That said, unfortunately R.L sucks (and it sucks hard). Toying with this will be enjoyable, no doubt - but I will probably try it only on holidays or vacations or something.  

 

Edited October 7, 2021 by Lisias
Hit Save too soon.

[rextable]

4 hours ago, Lisias said:

 

  Hide contents

 

 

 

That video looks like something out of a Voidz music video .

 

 

[rextable]

5 hours ago, Lisias said:

Since 5.4 Unity has support for HDR. So it's feasible, but this would probably need to reimplement the GalaxyCubeControl. What perhaps would not be that hard, but replacing the stock one without breaking everything may be a bit harder.

But there's a draw back on this approach: I would need someone to rework the skybox. My approach above would reuse whatever is the skybox in use at the moment, and this is way more flexible IMHO.

Okay. I found what appears to a high dynamic range star over at NASA. If you visit the page, scroll down, you'll see various different projections in various different resolutions - all the way up to.... 20K? They're in EXR format which CS6 or newer versions of Adobe softwarez can handle, although there is a free plugin with more control called ProEXR by FNord.

The trouble with these maps is they're not quite ready for use right off the bat - they need to be re-projected. My skill set starts and ends with portrait/documentary photography and the associated processing workflow. There's not much cause for spherical projection conversion in that arena . Does anyone know how to do this?  

 

 

Edited October 7, 2021 by rextable