Jump to content


  • Posts

  • Joined

  • Last visited


58 Excellent

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. That's really cool info! KSP2 is being developed in Unity right, so those settings should be editable with mods, if we're not happy with them. I wonder if it can recreate the actual brightness range needed for completely realistic stars though. What I am about to write is probably wrong in many ways. If I understand correctly, each frame is calculated in high-dynamic-range HDR mode, which has the max range of brightness values. This HDR image is calculated in 16 bit, which means each pixel can have brightness values between 1 and 2^16 = 16500. This is transformed to a low-dynamic-range (LDR) image to show on the screen, which basically cuts off the lowest and brightest values (and does some squishing & log transformation). The trick to simulated eye adaptation is determining where it should take this slice of the HDR's brightness values. The LDR needs 255 different brightness values, the amount of brightness values of a computer screen. If it has less than 255 brightness values banding artifacts occurs, there are jumps between the different brightness values. So what's shown on screen can be a slice of the calculated brightness values: 255/16500 = 1.54% the brightness values of the HDR. (This is optimistic because of the log transform: more detail is needed for the darker values of the LDR than the brighter values -> For the LDR you actually need a bigger slice of the HDR values or artifacts will occur.) Our eyes can see 24 stops brightness difference at any one time, that means the brightest thing you can differentiate is 2^24 = 16 million times as bright as the darkest value you can differentiate. We want to be able to see sunspots and other cool details when doing a flyby over the sun (as opposed to the sun always being overexposed, even when it fills the screen), and we want to be able to see the milkyway/ the dimmest visible star. I read the dimmest star we can see with our eyes is 6 trillion times dimmer than the sun. So we need to calculate brightness values for stuff 6 trillion times brighter than the darkest thing. Then select a slice of 16 million big out of those 6 trillion values, because that's the range we can see at any one time. That slice is only 0.00027% of the calculated values. This is a way smaller portion than the optimistic 1.54% slice we could select without artifacts out of our 16bit HDR image. My Conclusion: We cannot have completely realistic lighting range in game, a 16 bit HDR image does not offer enough detail. I don't think they can switch to higher bit HDR calculation, that may not be supported, would be slower and require more memory. Like the unity manual explains: "in any given moment of time, the [human] eye can only sense a contrast ratio of roughly one millionth of the total range. What enables the wider reach is that the eye adapts its definition of what is black." My calculations implied we want the range at any given time to be one in six million of the total range (not far off! (and I wanted to enable sunglasses for when close to the sun basically, extending the range further than our eyes can)). They do not explain what the maximum range of their HDR/ simulated eye adaptation is.
  2. So, no examples of games that do have correct exposure adjustments.
  3. This is the difficult balance the devs have to find. Fighting with light exposure controls like in space engine would be stupid when you're also having difficulty actually controlling a spaceship. No they don't I think? Do you have an example? Space engineers and Elite dangerous try and fail. Those are pretty big titles. Space engineers seriously adjusts to become darker when you enter dark areas, so, wrong way around. Elite dangerous is pretty static, has stupid things like stars actually becoming brighter when entering a thin atmosphere. Universe Sandbox, 'Children Of A Death Earth', Battlefront II, star trek online, X4-Foundation, and 'In the black' (from impeller studios) don't even try, they just have static exposure. Games on planets can cheat the lighting easier. It's harder in space because then you can actually have the dim and bright objects in view at the same time. Only the most expensive games of the last few years seem to do it well: Star Citizen and Microsoft FlightSim 2020 (but that's on planet so maybe cheating). And Space Engine.
  4. This is a programmatically implemented limitation, and I believe it is easier to not implement it than to bother doing what KSP seems to do It is definitely easier to just fade the skybox texture in and out like KSP DOE does and keep all other objects the same. I could code that myself. It is really hard to give all objects an accurate luminosity and adjust exposure for everything, making some objects over or completely under exposed. I have no idea where to even start if I had to make that. Space Engine is the Only program that I know that does that correctly.
  5. You are right those are not very representative. These were the pictures where I had edited the skybox to black. They all happen to be with zoom, because with zoom the bright skybox looks the worst. The low quality stars also look terrible indeed. It's totally undoable to do stars with a skybox texture if you're going to zoom. But at least space engine shows us that you can render thousands of individual stars, those remain point-like. I think that was with skybox dimming. But it's unedited. Yes the moon should look super bright in these pictures. In KSP2 we'll have moonshine so that will already be a lot more realistic. My dream feature would be that they implement realistic brightness, with background star brightness adjustable (set to realistic normally). And also a dynamic range slider, so you can see how it would look on a smartphone or our own eyes. It would make sense to have a dynamic range even higher than our eyes, because in reality when you look at something your eyes adjust, but the game does not know where you are looking on the screen. In reality the galaxy is just so dim that you need too much exposure increase to do it in a easily playable fashion.
  6. Hey, just joining in the discussion here with a big post, forgive me. Perfect that you guys are using space engine, which shows that a realtime video game can implement realistic brightness of objects (in the latest version, not the betas). I would really love it if KSP2 implemented something like this. However. My opinion: If sunlit objects/ the sun keep the same exposure, while only the skybox dims, then that is really distracting and useless. The skybox should dim to prevent the actual sunlit objects/ the sun from being overexposed. PROBLEM. 1. Hard to program realistic brightness of all objects (not only skybox dimming). 2. In space engine the automatic exposure adjustment is often not good enough, planets are either too bright, or they stay to dim. This is because the light differences are so extreme, and it's hard to determine what should be correctly exposed for comfortable viewing. It's hard to guess what the player wants to be correctly exposed. This is why I am always fiddling with the camera exposure in Space Engine. Still love it more than HDR view option though. SOLUTION. In KSP it is easier to guess what the player would want to have exposed: Planets/ spacecraft. So perhaps it should lock to a constant exposure (depending on distance from the sun). Like in KSP1 basically. But with the skybox looking totally black. Only when no sunlit objects are in view (nightside of planets (otherwise spacecraft is sunlit), interstellar space during transits, looking out windows), then exposure should increase to show the stars and galaxy. This should also make ship lights and engines etc brighter. REWARD. - If you see the stars and milky way all the time like in KSP 1, then is not special anymore, and it diminishes the planets visually. - If you only see the stars when you are in darkness, that's like an epic moment, entering a different environment. - Real engine brightness. Ever noticed in spaceX night launches, how bright the first stage gets lit up by ignition of second stage? Would be awesome to see in KSP, but not during the day. - It's realistic. KSP is a valuable education tool. In my experience people often wonder about whether you can see stars in space, there are lots of misconceptions. These misconceptions give more ground for conspiracy theories like faked moon landing. If lighting just happens correctly in game, that improves people understanding. I disagree with the opinion that the best looking shots are the ones where stars are visible. Finally I get to show more of my pictures . The worst case: Totally unrealistic lighting. The galaxy outshines the sunlit earth. Unmodded KSP1. Much better: Black space, nicely lit planet and spacecraft. On the nightside the stars may sparkle. Would this image be improved with stars? Especially in darkness the galaxy can give nice moments: Finally, some screenshots from space engine that showcase how hard it is to see stars. Rocinante at Mars. Overexposed Donnager and Rocinante at Mars. Still no stars! Rocinante in Mars' shadow. Keep in mind! The simulated camera in Space Engine has a specific dynamic range, like every camera/ eye has. The simulated camera in space engine attempts to be like an electronic camera. Our eyes have a better dynamic range, and can also adjust a bit locally, that never gets simulated. So maybe, in the overexposed Donnager shot, a person Would see stars, though your eyes/brain do not allow over-exposure for long.
  7. Perhaps in KSP2 you can also reshape control surfaces to any size you want. Then if you attach them sideways there are like the starship fins. We saw there will be procedural wings in the latest video: https://youtu.be/5CNwB8mmntg?t=231
  8. Those new circular solar panels look cool! If they produce 8 charge/second they are Exactly what I proposed in 2020 !
  9. Hey I even shared the youtube link
  10. For those who missed the show and tell link: https://www.youtube.com/watch?v=6W1RRCjEX8o&ab_channel=KerbalSpaceProgram I love it, it looks more like our moon. And I like the contrast of the dark lakes and the white ejecta. Maybe it's just a bit too shiny, not dusty enough.
  11. Yes it's the lighting, the rocket was in full sunlight, but earth wasn't in the shot so the camera exposure was high. Secretly all rocket launches shed a lot of ice.
  12. I would like to set the angle and position of part connection by typing them. KSP has gone this way for part properties; in the past it was only possible to set the properties via sliders, now it is possible to switch to typing numbers directly. This old way is still the only way for part orientations and position during vehicle construction. Some examples where it would be helpful to type the orientation (either global orientation or relative to the parent part): - Slightly inclining wings is helpful, but setting an angle is quite difficult. It's either too fine, so it becomes impossible to apply the same rotation to multiple parts, or the steps are too big. - It is quite important that landing gear is straight, but for some parts this is very difficult because the attachments happen at an angle. Switching the orientation tool to global and setting the orientation to 0 ° would make this very easy. - obsessive desire for certain angles becomes easy to build. - Imagine creating a 90° turn in 5 parts, at the moment that is very difficult. But if you can type the orientation you can just calculate the angle (18°), type it in and it's done. Rotation creates gaps which need to be removed by moving the part. If you figure out how to reposition a part, just look at the local position of the part compared to the parent part, and apply the same position to the other parts! No fiddling for every part needed anymore. - Parts attached to big wing parts will not attach straight. When making skylon-like planes this makes it very difficult to attach the engines to the wings. Many people instead attach the engines to the fuselage and move them outward to the wingtips. I want to attach them to the wings so they can break and overstress more realistically! Example of what I thought of: Typing fairing sizes (section diameter, section length) would also be cool? Would require a delete and add section button. Does anyone know if there is a mod that does this? What do you think about the idea?
  13. I completed my biggest space station that is inspired by the ISS. A bit late to the party. It has an aimable telescope and atenna. Docking some capsules. Sunset on the station. Starship returning to the surface. It has hinged back flaps to control the angle of attack on reentry, and to allow for a fast flip landing. I can only land it in slow motion (0.5x speed), but in that case it is pretty reliable!
  14. That's awesome! and terrible . Would love it if KSP could do that without separate maneuver nodes. We have mods like trajectories right, they iteratively calculate the changing orbit with aero drag. And the space combat simulator 'Children of a death earth' also takes into account burn time. In that game you can actually set up year long ion burns from Ceres to Mars for example. What I meant with the suicide oberth burn is what Hazardish does on 8:26 on the video: Wind the orbit up to a high apoapsis, low periapsis. Then before the final ejection burn when at apoapsis, lowering your periapsis below the surface. This would be suicide if your engine doesn't start again. When almost arriving at periapsis (and death) start the engine at the right time, pointing prograde, this raises the periapsis. When arriving at periapsis it has been just raised above the surface, so you are taking full advantage of the oberth effect, you are burning prograde and you can give a farewell high-five to people on the surface :). But I like the oberth and almost hitting the surface! Hm that sounds interesting. Yes you are right, the problem is the last ejection burn. For realism sake I don't want to make 50 year long manned missions with many gravity assists. I've created some missions in which I did more than 15 burns at periapsis to increase apoapsis before the final ejection burn. With an acceleration of 0.07G the ejection burn is still difficult. Yes I plan the ejection maneuver days in advance, then start burning at that maneuver node many times so the orbit has a very high apoapsis when that planned maneuver occurs. That still sounds pretty good! Yes I should write the results down instead of guessing it 10 times in a row. It does seem like that, but I don't think so. Because at every moment in the burn you are pointing prograde, so at every moment all of the DV is being used to increase your speed. If you burn prograde for 1 second to get a nice moon transfer, and then your orbit curves halfway around before you encounter the moon, that isn't undoing your work.
  15. Okay thanks! That worst case is when you have to burn across half an orbit I assume. 41% difference sounds like a lot for some missions. Perhaps in KSP 2 we will be able to do this computation, since low thrust high ISP engines get more support.
  • Create New...