Can we NOT have stars during daylight?

[Jack Mcslay]

18 minutes ago, PDCWolf said:

Except hardcore simulation would be something like principia, whilst some recognizable visual effects are present on almost every single modern videogame you could possibly name. Heck, unity sells all the effects on it's store and so does Unreal, so you can even get a basic form of them on most super low budget indies.

Except what you're suggesting is bad game design. Please watch this excerpt (skip to 6:37 if the video starts from the beginning)

Just because you can do something does not mean you should.  Some of the coolest shots in KSP are nearby planets with the clearly visible galactic ring around it.  It would be boneheaded to spend time and resources to make a game look worse just because it's realistic when full realism isn't the goal of the game in first place.

 

Quote

Also, again, it's not "dimming stars near celestial bodies", it's big light make little light disappear, like when you drive on a road with the sun in front and can't see, or look at a full moon and have to look away and wait for your eyes to adapt again to see the dimmer stars.

I was being technical. A game engine does not know what big light and little light is, it only knows light values so you're instructing the game to make stars dimmer.

[t_v]

I would like to second this opinion. The discussion has turned from whether the stars would dim with bright light to whether the stars should dim with bright light. These are two different questions, and as it has been pointed out, KSP is not intended to be fully realistic, and does not even try to achieve maximum realism. Where the line should be drawn on realism is where it improves the experience of players, and this is different for different people. For me at least I love myself some nice starry skies, but this would not apply for you. So, it should not be the default but it should be an option. 

Edited November 10, 2021 by t_v

[PDCWolf]

1 hour ago, Jack Mcslay said:

Except what you're suggesting is bad game design.

I was being technical. A game engine does not know what big light and little light is, it only knows light values so you're instructing the game to make stars dimmer.

Realism is not bad game design, specially on a "simulcade". On top of this, your video refers to mechanical gameplay decisions, not visual, which are two very different aspects, specially once you include artistic view as part of the second. At the moment, it is not clear (since the lighting on screenshots sucks on most cases) whether they've arrived to this stage by "artistic choice" or just because they haven't considered this particular phenomenon. 

1 hour ago, t_v said:

I would like to second this opinion. The discussion has turned from whether the stars would dim with bright light to whether the stars should dim with bright light. This are two questions, as it has been pointed out that KSP is not intended to be fully realistic, and does not even try to achieve maximum realism. Where the line should be drawn on realism is where it improves the experience of players, and this is different for different people. For me at least I love myself some nice starry skies, but this would not apply for you. So, it should not be the default but it should be an option. 

This discussion is: "Stars dim in real life if there's a stronger source of light in your view, and I can prove it, can we have that in the game", and you can refer to the first post for the initial statement, and subsequent posts for the proof. People have tried to peg a myriad misconceptions and assumptions in an attempt to "defend" their personal tastes or their misconceptions/ignorance about how stuff actually works to this discussion.

As to shove the "KSP is not a simulator" (or "this is too realistic for KSP") argument away, something that has had to be done time and time again since the first public versions of KSP1, the KSP2 development team has demonstrated their focus on realism through atmosphere visuals like sun scattering, realistic interplanetary lighting like eclipses, different lighting from different stars, engine exhaust lighting, reflections and shading of parts, all that work for water shading, etc. So, don't come at me saying this particular effect falls outside how realistic an image they're trying to achieve, because they've clearly gone further distances already working to bring in on other realistic aspects in lighting tech.

 

 

[Jack Mcslay]

46 minutes ago, PDCWolf said:

On top of this, your video refers to mechanical gameplay decisions, not visual, which are two very different aspects

Now you're grasping at straws. The requirements for the art design follows the same thought process as the game design.  Games that do a good job with their art design become recognized for their visuals, while games that focus on realistic visuals will eventually end up looking dated. This is why Mortal Kombat 1-3 aged poorly but not Street Fighter II. Consider this scene from a space movie also with a loose sense of realism

Now imagine if they implemented it. Those shots with nearby celestial bodies would look very dull and look more like a budget 60's movie. This is art fundamentals, good art is one such that impresses the viewer, not one that goes for visual accuracy.

43 minutes ago, PDCWolf said:

the KSP2 development team has demonstrated their focus on realism

Then why does the game allow painting your ship any color other than silver or white?

[PDCWolf]

51 minutes ago, Jack Mcslay said:

Now you're grasping at straws. The requirements for the art design follows the same thought process as the game design.  Games that do a good job with their art design become recognized for their visuals, while games that focus on realistic visuals will eventually end up looking dated. This is why Mortal Kombat 1-3 aged poorly but not Street Fighter II.

Only grasping at straws if you ignore every other bit of argument in the entire thread. Not to mention your gross overgeneralization of where realistic vs artistic (which is also a very intellectually dishonest fallacy to compare) end up. As for the MK/SF comparison, all the games you named are dead and look dated. 

Quote

Now imagine if they implemented it. Those shots with nearby celestial bodies would look very dull and look more like a budget 60's movie. This is art fundamentals, good art is one such that impresses the viewer, not one that goes for visual accuracy.

Funny you'd say that when modern day space epics have gone for a realistic look because that's exactly what sets them apart from simple hollywood flicks. 

Spoiler

 

 

Quote

Then why does the game allow painting your ship any color other than silver or white?

Because we've had spaceships and rockets in a lot of colors. And we have the capability of painting them on any color, it's just cheaper to not paint them, or useful to paint them in reflective colors, or to easily visualize rotation.

Spoiler

 

 

 

 

 

Edited November 10, 2021 by PDCWolf

[OHara]

On 11/3/2021 at 5:09 PM, SOXBLOX said:

I see many stars in that one. There's the Belt of Orion at the uppermost left edge of the outer halo.

I used the computer-program orrery Celestia to find what was behind Saturn on that date, from Cassini's vantage point in Saturn's shadow from Sol.  Saturn would have been in front of Capricorn, so rather than the belt of Orion, those are the three (dimmer) stars just north of δ Capricornus.  

==

Just before this discussion split off, I recommended the KSP1 mod Distant Object Enhancement mostly for its ability to show our potential-destination planets and stars brightly enough that we can find them against the skybox.  Seeing KSP2's new visit-able stars during the journey, getting brighter as we approach, would be nice to have in KSP2 if it is feasible.

If you treat the brightness of planets consistently, knowing that you can see Mars as bright as stars when it is still far enough away to be an unresolved sub-pixel blur, then logically it would be brighter than the stars when you are orbiting over its day side.   But personally I would prefer to see stars when in orbit around Duna over having that level of consistency in a game.  I can imagine we might get both, because when I work the numbers, the brightest stars are within a factor of 100 the brightness of sunlit planets, so KSP2 rendering scenes with a compression of the dynamic range might work nicely.

Bright stars like Aldebaran are dimmer than the Moon's sunlit side (actually, the blurry image of Aldebaran seen with the resolution of human eyes is dimmer) but brighter than the dark side of the moon and humans perceive the whole scene at once, even though the sunlit side is overly bright washed-out when seen by dark adapted eye.  If I were in orbit of the moon, and wanted to see Aldeberan, I would have to shield my eyes from the moon surface for some time.  Sometimes I catch myself covering KSP1's sunflare with my hand, but it doesn't work.

[SOXBLOX]

3 hours ago, OHara said:

I used the computer-program orrery Celestia to find what was behind Saturn on that date, from Cassini's vantage point in Saturn's shadow from Sol.  Saturn would have been in front of Capricorn, so rather than the belt of Orion, those are the three (dimmer) stars just north of δ Capricornus.  

Very interesting. Thank you for pointing that out. Funny, I assumed they would have to be bright stars to show in those conditions. Seems like this confirms that, with the right settings, much fainter stars than even I thought possible are visible.

Better leave fainter stars in the skybox, then.

[Ahres]

On 11/9/2021 at 4:54 PM, shdwlrd said:

@Ahres I've used DOE in the past, primarily for the telescope mod I use to use. I've have forgotten about it since it was incompatible for so long.

To be honest, I've never noticed that effect. I'm too busy either watching the navball or waiting for the "warp to" here to finish up. I'm never really paying attention to what is happening with the skybox. 

Fair enough. I appreciate the added perspective. For me it's a big detail, but I need to remember it may not be for others. I'm the type of player that likes to take a moment to stop and smell the roses. When using a lot of visual mods I'll happily take a few minutes to stop playing and take in the view, thereby noticing if the skybox is how I'd expect it to look if I were actually there.

[PDCWolf]

14 hours ago, SOXBLOX said:

Very interesting. Thank you for pointing that out. Funny, I assumed they would have to be bright stars to show in those conditions. Seems like this confirms that, with the right settings, much fainter stars than even I thought possible are visible.

Better leave fainter stars in the skybox, then.

That's quite the jump.

This is Saturn's dark side with some refracted light (like it happens to our moon during eclipses), and that's an enhanced image, I must remind you that THIS is the real image (as per this source https://photojournal.jpl.nasa.gov/catalog/PIA08329 ) Here they show the original image in which you can't see stars, then along they show the enhanced version (the one @OHara uses for his post) where you can see some stars.

 

[SOXBLOX]

@PDCWolf, we already cleared this up. Your wording in your first posts made it sound like you thought no stars were visible if you stand on the day side of a planet. I pointed out that you can see them again if you cover the sun with your hand and your eyes dark-adapt. You agreed. There is no argument anymore.

[PDCWolf]

3 minutes ago, SOXBLOX said:

@PDCWolf, we already cleared this up. Your wording in your first posts made it sound like you thought no stars were visible if you stand on the day side of a planet. I pointed out that you can see them again if you cover the sun with your hand and your eyes dark-adapt. You agreed. There is no argument anymore.

Which is nothing related to what you were talking about in your last post, where you jumped to a conclusion based on a misidentified source (enhanced image), I wanted to clear that up.

Plus, to be clear, you have to shield yourself from all light that might reach your eyes, not just the sun, which I did point out back then too.

[MechBFP]

Kerbals have better eyes.

[PDCWolf]

1 hour ago, MechBFP said:

Kerbals have better eyes.

Not if they're... eyes as we know them. They might have better low light vision, but their eyes would still submit to the same processes in ours. What would be required is "HDR" eyes that can selectively tone up and down exposure on a per-receptor basis, and some heavy brain processing power.

[Jack Mcslay]

On 11/10/2021 at 7:35 PM, PDCWolf said:

Only grasping at straws if you ignore every other bit of argument in the entire thread.

What other argument? The only argument is that you desperately want the game visuals to be far more dull just for a minuscule increase in realism that was complained by virtually nobody in over 10 years of KSP

On 11/10/2021 at 7:35 PM, PDCWolf said:

Funny you'd say that when modern day space epics have gone for a realistic look because that's exactly what sets them apart from simple hollywood flicks. 

The Expanse disagrees with you

 

 

Edited November 20, 2021 by Jack Mcslay

[PDCWolf]

21 hours ago, Jack Mcslay said:

What other argument? The only argument is that you desperately want the game visuals to be far more dull just for a minuscule increase in realism that was complained by virtually nobody in over 10 years of KSP

The Expanse disagrees with you

Gravity:

Spoiler

 

First Man:

Spoiler

 

Quote

What other argument? The only argument is that you desperately want the game visuals to be far more dull just for a minuscule increase in realism that was complained by virtually nobody in over 10 years of KSP

Yeah, that's why DOE has so little downloads, and so do almost all other visual mods that make things right. 

As for evidence and argumentation on why respecting this in KSP2 is the right way to go, it's all over the thread, and provided not only by me. 

[Lisias]

30 minutes ago, PDCWolf said:

As for evidence and argumentation on why respecting this in KSP2 is the right way to go, it's all over the thread, and provided not only by me. 

it's not unanimous.

Elite Dangerous and No Man's Sky don't do that, and they are incredibly successful games nevertheless. 

Spoiler

Search for the scenes on space 

There's nothing wrong on having the feature,  but there's nothing wrong on not having it neither.

In the end, it will be a business decision - adding the feature will depend if the project is on tracks and have space for adding one more feature without risking starting a Feature Creep Syndrome (or a  Second System Effect.)

 

[PDCWolf]

3 minutes ago, Lisias said:

it's not unanimous.

Elite Dangerous and No Man's Sky don't do that, and they are incredibly successful games nevertheless. 

  Reveal hidden contents

Search for the scenes on space 

There's nothing wrong on having the feature,  but there's nothing wrong on not having it neither.

In the end, it will be a business decision - adding the feature will depend if the project is on tracks and have space for adding one more feature without risking starting a Feature Creep Syndrome (or a  Second System Effect.)

 

I don't think anyone along the entire thread has treated the feature as make or break, but rather a very obvious, easy to implement, missed opportunity when going for realism. Neither has the claim for the feature been unanimous, otherwise there'd be no pages of discussion.

[OHara]

KSP1 has the feature of dimming the skybox when the sun is near the centre of the window.  (Balancing brightness for what is in the centre of the view, rather than the entire view, is a nice idea.) KSP1's designers chose to only slightly dim the skybox.

KSP1 dims the skybox the same amount whether we are looking at the sun from inside Moho's orbit, or outside Eeloo's.   Distant Object Enhancement, also, dims the skybox the same amount whether we have Moho's lit surface, or Eeloo's, in view.   (@PDCWolf do any 'other visual mods that make things right' account for distance to the Sun? )

I suspect KSP2 will consider distance to the sun, because we have at least two suns, and sometimes one will be 'the sun' sometimes the other.   

Edited November 21, 2021 by OHara
pics

[PDCWolf]

2 minutes ago, OHara said:

KSP1 has the feature of dimming the skybox when the sun is near the centre of the window.  (Balancing brightness for what is in the centre of the view, rather than the entire view, is a nice idea.) KSP1's designers chose to only slightly dim the skybox.

KSP1 dims the skybox the same amount whether we are looking at the sun from inside Moho's orbit, or outside Eeloo's.   Distant Object Enhancement, also, dims the skybox the same amount whether we have Moho's lit surface, or Eeloo's, in view.   (@PDCWolf do any 'other visual mods that make things right' account for distance to the Sun? )

I suspect KSP2 will consider distance to the sun, because we have at least two suns, and sometimes one will be 'the sun' sometimes the other.   

I'd say, based on the pale blue dot image (below) that even when further away than Pluto, the sun still overpowers most stuff. I'll also base myself on the balanced image of Pluto (also below), that when that far away from the sun, this phenomena still applies. However, no, I don't think they consider it, BUT considering the solar system in KSP1 is magnitudes smaller than our own, I'd think there shouldn't be much of a difference.

Full Pale Blue Dot composite: https://photojournal.jpl.nasa.gov/catalog/PIA00450 (Sun still overpowers all, explained in text)

Pluto from the front: https://photojournal.jpl.nasa.gov/catalog/PIA20291 

Pluto from the back, even the haze overpowers stars: (and the exposure is blown up, look at that banding on the atmosphere): https://photojournal.jpl.nasa.gov/catalog/PIA20727 

[OHara]

2 hours ago, PDCWolf said:

However, no, I don't think they consider it [surface brightness dimming with distance from the sun], BUT considering the solar system in KSP1 is magnitudes smaller than our own, I'd think there shouldn't be much of a difference.

Well, KSP1 has the mechanism for reduced solar-panel production with distance from the sun, so I would not be surprised if a modder considered it for relative brightness of sunlit planetary surfaces.

The smaller scale of KSP reduces the distance needed to see a significant change in sunlit brightness, but the effect is still there.   KSP has a dimmer sun so that the 10×-closer Kerbin gets about the same illumination as does Earth, and KSP's Jool gets 25× less output from solar panels, similar to the situation at Jupiter.

Are there other mods that address this topic, besides distant-object enhancement, that you mentioned above?

Edited November 21, 2021 by OHara
It turns out (following links two posts below) that Kopernicus has a mechanism to decrease sunlight with distance from the star, which makes sense to support systems with two stars.

[Lisias]

24 minutes ago, PDCWolf said:

I don't think anyone along the entire thread has treated the feature as make or break, but rather a very obvious, easy to implement, missed opportunity when going for realism. Neither has the claim for the feature been unanimous, otherwise there'd be no pages of discussion.

The error of the whole discussion is assuming this is easy to implement. We don't have the slightest clue about how the current development process are behaving, if they didn't already reached some "do not exceed threshold". As the GPU's VRAM - remember, we will face some 2 years of terrible shortage of electronics, including GPU - there're people buying prebuilt computers just to grab the GPU and then selling the rest on ebay. Most new systems will use APUs for graphics, as it appears.

Given the current status quo, one possible (new and recent) non functional requirement for the project is to do not exceed 2GB of RAM for the minimum viable product to be shipped, POINT (it's what I would do at least), and so some things would need to be prioritised .

Most people do not realise it, but you need images specially tailored for doing the job as you are requesting, and these images use more VRAM than "normal" ones. Exactly what's a premium nowadays - there're people buying GTX 1030 (a crap with 2GB VRAM) three times the price I bought my RX460 with 4GB VRAM 2 years ago around here.

On the other hand, there's also the cheap and dirty solutions that changes the skybox using the CPU (saving the GPU from the task), but by then, you start to bottleneck the CPU, using some juice that could be used to enhance the FPS.

And, all of this, assuming they didn't already implemented the whole stunt, rendering us splitting hairs .

 

[PDCWolf]

31 minutes ago, OHara said:

Well, KSP1 has the mechanism for reduced solar-panel production with distance from the sun, so I would not be surprised if a modder considered it for relative brightness of sunlit planetary surfaces.

The smaller scale of KSP reduces the distance needed to see a significant change in sunlit brightness, but the effect is still there.   KSP has a dimmer sun so that the 10×-closer Kerbin gets about the same illumination as does Earth, and KSP's Jool gets 25× less output from solar panels, similar to the situation at Jupiter.

Are there other mods that address this topic, besides distant-object enhancement, that you mentioned above?

Output from solar panels is programmatically changed with a mathematical formula, not by relative brightness, apples to oranges. Brightness doesn't seem to decrease, or increase, with distance, as suggested by this being a requested feature:

23 minutes ago, Lisias said:

The error of the whole discussion is assuming this is easy to implement. We don't have the slightest clue about how the current development process are behaving, if they didn't already reached some "do not exceed threshold". As the GPU's VRAM - remember, we will face some 2 years of terrible shortage of electronics, including GPU - there're people buying prebuilt computers just to grab the GPU and then selling the rest on ebay. Most new systems will use APUs for graphics, as it appears.

Given the current status quo, one possible (new and recent) non functional requirement for the project is to do not exceed 2GB of RAM for the minimum viable product to be shipped, POINT (it's what I would do at least), and so some things would need to be prioritised .

Most people do not realise it, but you need images specially tailored for doing the job as you are requesting, and these images use more VRAM than "normal" ones. Exactly what's a premium nowadays - there're people buying GTX 1030 (a crap with 2GB VRAM) three times the price I bought my RX460 with 4GB VRAM 2 years ago around here.

On the other hand, there's also the cheap and dirty solutions that changes the skybox using the CPU (saving the GPU from the task), but by then, you start to bottleneck the CPU, using some juice that could be used to enhance the FPS.

And, all of this, assuming they didn't already implemented the whole stunt, rendering us splitting hairs .

 

The code DOE uses for it's basic implementation is freely available to be performance tested by whoever whishes to challenge the claim in actual measurable terms, both in performance and implementation time: https://github.com/TheDarkBadger/DistantObject/blob/master/Source-Code/DarkenSky.cs 

The images are not specially tailored, as there's no "images".  The skybox is actuated on based on simple RGB manipulation.

[Lisias]

2 hours ago, PDCWolf said:

The code DOE uses for it's basic implementation is freely available to be performance tested by whoever whishes to challenge the claim in actual measurable terms, both in performance and implementation time: https://github.com/TheDarkBadger/DistantObject/blob/master/Source-Code/DarkenSky.cs 

The images are not specially tailored, as there's no "images".  The skybox is actuated on based on simple RGB manipulation.

Sorry, dude, you fail to understand how these things work.

RGB manipulation on the skybox involves duplicating a base image and applying changes on it, pixel by pixel, for every frame. So you need to have both images on the VRAM (and so the GPU can do the job, at expenses of duplicating the skybox footprint in memory), or you have the base image on CPU's memory, makes it apply the change, and then 'upload' the result into the VRAM, so the GPU can apply it - and this transition is way more expensive than having the GPU using the VRAM exclusively, even nowadays using PCIEx16 buses.

I suggest you read the code yourself - it uses something already existent on the codebase, the GalaxyCubeControl, and unless you are engaged in Non Forum Compliant activities (see item 9), you don't have grounds to do such affirmation.

I also suggest you follow an ongoing (besides slow as hell) discussion about how to enhance the feature on DOE.

Edited November 21, 2021 by Lisias
Tyop!

[PDCWolf]

13 minutes ago, Lisias said:

Sorry, dude, you fail to understand how these things work.

RGB manipulation on the skybox involves duplicating a base image and applying changes on it, pixel by pixel, for every frame. So you need to have both images on the VRAM (and so the GPU can do the job, at expenses of duplicating the skybox footprint in memory), or you have the base image on CPU's memory, makes it apply the change, and then 'upload' the result into the VRAM, so the GPU can apply it - and this transition is way more expensive than having the GPU using the VRAM exclusively, even nowadays using PCIEx16 buses.

I suggest you read the code yourself - it uses something already existent on the codebase, the GalaxyCubeControl, and unless you are engaged in Non Forum Compliant activities (see item 9), you don't have grounds to do such affirmation.

I also suggest you follow an ongoing (besides slow as hell) discussion about how to enhance the feature on DOE.

You can both know the size of the skybox images (this is pretty much publicly accesible lmao) AND infer what GalaxyCubeControl does (specially thanks to the API docs & many other modders using it) without violating item 9.

Now, you're suggesting DOE uses hacky code, and you'd know since you maintain it, yet use that same allegedly hacky code to argue that you'd require double the resources just to dim the skybox. Since we'd be dealing with a stock implementation, going as deep as shaders themselves rather than duplication and operation, we could do away with that argument easily. You can't have both sides.

[Lisias]

52 minutes ago, PDCWolf said:

You can both know the size of the skybox images (this is pretty much publicly accesible lmao) AND infer what GalaxyCubeControl does (specially thanks to the API docs & many other modders using it) without violating item 9.

And that's what I did. I switched the skybox to one with way more resolution and tested the thing on my oldest MacCrap, that have only 384MB of VRAM (no to mention a crappy Intel HD3000 as GPU). You can't ask for a better rig for easily test performance, sir, every extra MB can make the textures being fetched from the CPU's RAM, plummeting the performance.

And some other interesting effects.

 

52 minutes ago, PDCWolf said:

Now, you're suggesting DOE uses hacky code, and you'd know since you maintain it, yet use that same allegedly hacky code to argue that you'd require double the resources just to dim the skybox. Since we'd be dealing with a stock implementation, going as deep as shaders themselves rather than duplication and operation, we could do away with that argument easily. You can't have both sides.

Read the rules again. I'm allowed to hack KSP, as long I stay away from private thingies and do not reverse engineer the thing. And I didn't did any of them.

And I'm not the one claiming how the GalaxyCubeControl works. I'm just telling you how I think it works based on my Clean Room tests made on weaker machines, where such behaviours are way easily spotted and measured.

Of course, I may be wrong about your claiming. Please pinpoint where in the KSP API Docs are the information needed to know exactly how the GalaxyCubeControl works.  

Edited November 21, 2021 by Lisias
Pics or didn't happened! :)