kedrednael

Using scatterrer, KSP 1 has planet casting shadows on other planets. On the Kerbin ground, the eclipse colors the sky beautifully, with the shadow of the mun casting visibly through the air. On the Mun, Kerbin eclipsing the kerbol turns the light red. That is way better than just dimming the light. Is the method used in this devpost going to have to be replaced completely? Or is it actually needed when casting the shadows of planets, because of the way shadows are rendered in game? I mean, is it secretly also implemented by scatterer in KSP 1? Raw screenshot from KSP 1. Kerbin eclipsing the sun on the mun. Even though the Kerbin sky doesn't light up, the light on the mun behaves as if it does, which is really nice & spooky. Edited in photoshop. All I could hope is that KSP2 looks like that. Laythe casting a shadow onto Jool. I have blackracks true volumetric cloud mod as well. Those are the best clouds in any game! The mun's shadow on Kerbin, while coasting past the mun for a gravity assist towards minmus Have fun at the eclipse!!!

Yeah it does sound like a lot of work. But I was just shocked how SCANSAT got implemented in KSP2 already. That's even complicated than these graphs, though quite similar to program I imagine (location unlocks part of graph).

I also desired the science in KSP 2 to be more like you describe. I thought SCANSAT mod was a beautiful example of where science should go. Suddenly and naturally some specific polar orbits with certain periods are necessary. That is cool emergent gameplay, with relevant data! And it still allows for kerbalish science message too. One thing I'd love for example is if you have a pressure sensor, you can log the pressure for the altitude you are at. This builds up the graph of atmospheric pressure while you descent or ascent with the device. So if you choose to land on Eve highlands for example, you have not collected the pressure for lower altitudes, this very naturally gives the desire to go to the lowest place possible to find out the pressure there and collect all the science. Perhaps a seperate science message for different altitudes can be made up.

Here is reentry seen from a little distance away. I think that's the closest to the normal KSP perspective we can get. So the video is slightly underexposed for the flames. I don't know if there is a lamp or the jet is really bright. The very horizontal lines in the flames are because of the rolling shutter effect. In this video from fastest spaceX fairing reentry you the flames at the far end of the fairing are probably like 10 meters away from the camera, since the fairing is 13 meters long. I think if the reentry looks realistic from inside the vehicle, and from far away, it's probably really realistic from the normal 3rd person KSP perspective too.

It's looking so much better!

I don't trust the very low brightness of Europa's surface. Jupiter is pretty big in this image, it should cast quite some light onto Europe's surface. - Space Engine's 'realistic' camera seems to model camera-like dynamic range. Our eyes are better, and are more what KSP is going for, which makes sense. - We know the brightness of planets in Space Engine can be adjust with the 'real planet brightness' setting, and the 'planet shine' setting (whose exact name I forgot). Perhaps it's a bit off: It's not raytraced graphics. Even if it is correct in Space Engine, I think Jool is larger in the sky in KSP, so it is shining more light onto Laythe.

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.

So, no examples of games that do have correct exposure adjustments.

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.

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.

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.

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.

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

Those new circular solar panels look cool! If they produce 8 charge/second they are Exactly what I proposed in 2020 !

Hey I even shared the youtube link

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.

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.

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?

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!

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.

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.

Hi, I was wondering what the most efficient method for low TWR, high DV ejection burns is. I thought pointing prograde is always best. But if you point prograde long before you are at periapsis the periapsis rises, so you lose DV because you can't use the oberth effect as much. To mitigate that problem, you can lower your periapsis to below the surface/ atmosphere, rising just high enough when you're eventually at periapsis. But when burning the direction changes most in the beginning. Quickly the orbit becomes straight. So it's hard to estimate in which direction you'll eject exactly. Sometimes this even means you can't plan your orbit raising burns with the maneuver node system, because your periapsis moves to a point earlier in your obit/ the orbit points outward more than planned. Some people (like turbopumped) do the suicide oberth burn. This seems like the best idea ever. But other people use their hard earned fuel to burn pointing at the maneuver node marker. This seems to waste fuel because you are not pointing prograde, not all the fuel is used to increase your speed. Is it done this way only because it's easier to execute and plan the maneuver? Not everybody has the patience to retry their super long ejection burn 10 times?! Or does it just not matter that much?

Finally my largest station with artificial gravity is in orbit. Launching it was quite difficult! BTW the large rotors need a lower minimum RPM than 5. We may also need a 2.5 meter rotor. So many ways in which it can crash.. Sometimes the kraken still attacks when it's in orbit. But not often.

Incredible content sounds very good! I wasn't expecting the suggestions here to actually get implemented (in 1.11), I was just suggesting things, as is the subject of this subforum.

The ability to set engines as RCS is a great idea! I want G-force / max G-force memory, suicide burn indicator & time to surface/target impact. Suicide burn indicator to target and minimum separation to target would also be funny. Also current biome indicator would be nice, now we just have to retry the science experiments all the time, hoping you entered a new biome.