Graphics thread?

[TLTay]

There has been lots of awesome discussion on game play mechanics with many valid points raised, but I didn't see too much in the way of discussing visuals for KSP2. From what I've seen so far for early development, it looks really promising. A more realistic vibe than the original, which I personally like. It looks like some of the planets are really coming together nicely. 

I know KSP has people running everything from a 2080ti to integrated 'tato graphics and that supporting as many players as possible is very important, but we are on the verge of a new console generation which will include ray tracing and major improvements in graphical capabilities. It would be easy to have KSP2 get a yawn reception from gamers in '21 or '22 if they are used to a higher level of visual fidelity from AAA games for their new console. Given the space environment and high CPU usage often being the limiting factor, I think ray tracing could be super applicable to KSP2 and the visuals could really help sell the game. I think they said we would not get RT at launch, but I'm not sure if they meant never or just not yet? Please correct me if wrong. I'm not trying to be negative, I'm just very excited about the graphical improvements I've seen and have lofty hopes for the final product. 

On the more realistic hopes... Dust storms and weather with dynamic conditions would really add to immersion and challenge. Probably best to make KSC a fair weather zone for new players tho. With KSP, I think most players never made it very far from home, and I wonder how much of that had to do with lack of visual incentive to explore. Physics isn't changing between 2021 and 2031, so graphics may be one of the deciding factors with KSP2's lifespan reaching that of the original.

[Draco T stand-up guy]

4 minutes ago, TLTay said:

With KSP, I think most players never made it very far from home, and I wonder how much of that had to do with lack of visual incentive to explore.

For me it wasn't the visuals. There were multiple issues about getting beyond Minmus:

• My science tree was full and there was nothing more to research
• Going to Gilly was no different than going to Minmus
• There simply wasn't the proper tools in-game:
  • Transfer window planner
  • Some sort of mission planner that kept track of when to do things (Alarm clock) for different missions (always irritated me that the 'mission control building' was just another admin building)
• Too much boring time-skip

The visuals were fine although I'm certainly appreciative of better.

[PlutoISaPlanet]

The visuals of the game always felt depressing to me. I got to the mun, then minmus and I honestly felt a small feeling of accomplishment.

[OHara]

KSP2 is likely to appeal to people who don't play video games, and thus do not have a gaming console, because the interesting part of the game is different to other games.

I had to turn graphics up from the minimum to see shadows on the ground when landing, but otherwise have found the game playable and enjoyable for 5 years with near-minimum graphics. 

Generally I buy a computer every five years, use the newest one for work, and retire the old work computers for home.  KSP needed a graphics card so I play it on what is otherwise my 'work' computer.  A 4-core Intel i7-6500 at 2.5GHz and a Radeon R6 M360 is enough for ray-tracing as used in lens-design, CAD modeling, and the image processing that I do, ... but in KSP I have to swing the camera toward the sky to get full frame-rate (25fps for a green clock).

Gaming machines cost a lot more than KSP2's planned price.

[OOM]

I have zero expectations both in the visual part and in the realism of the new mechanics. But I really hope for modifications. They will make garbage worth a masterpiece as it was with the original KSP.

Take a screenshot of my post. But the graphics in KSP 2 will be at the "spectra" level for the original KSP. This is of course far from a beautiful AVP.

Edited July 13, 2020 by OOM

[K^2]

Yes, graphics in a game engine usually runs on its own thread. What do you mean, that's not what you've meant?  

I agree that KSP2 will have to push graphics a lot further than KSP, but I'm not sure ray tracing will help a whole lot, and I'm usually the guy who pushes for broader RT use. It just... Doesn't help you render a planet, unless you throw a LOT of RT power at it. Talking about all the things Ray Tracing can do and how much of it you can support on next-gen is a complicated topic. Especially, because specs aren't public yet, so even things I know I can't discuss.

But in broad terms, the hardware isn't quite there yet to just straight up ray-trace the entire scene and completely abandon conventional rendering. You need very complex BVH and a lot of rays to achieve that, and even 2080Ti just can't in realistic scenarios. Instead, what you normally do is render scene as normal, and then use RT to improve lighting or reflections. Again, speaking very broadly, you can improve reflections, global illumination, and shadows. This can be absolutely phenomenal for creating atmosphere in some games, but KSP2 doesn't have scenes where it pays off.

Lets break it down a bit. I would broadly break down the components of the scenes into 3 categories. Planets that you're on the surface of or in low flight over, including terrain, sky, and weather rendering as applicable; planets that you're in proximity of, such as when you're in orbit; and your actual craft. You can have all 3. If you're flying over Lathe, you obviously have your craft, the terrain of Lathe bellow you, the sky above, and possibly, Jool occupying a solid chunk of it. All of these have to be handled differently.

Lets start with planets you are orbiting. Can you improve these with RT? Maybe, but it doesn't seem cost-effective. The only fancy things that can be going on are things like crater shadows and atmospheric scattering. You can try to get that with RT, but you'll need a ton of rays to get good resolution out of it without noise. It's way, way easier to just write custom shaders for these things. You can get absolutely amazing looking planets with conventional shaders if people writing them understand light theory and scattering processes. If you don't, they won't write a good ray tracer, either, so all around, you're better off with conventional shaders.

The planets you're in flight over are more interesting. Here, shadows really can be improved, especially, once you take global illumination into account. You can get better time of day and weather visuals for sure. But RT is still an expensive way to get these. And while it can pay off in very complex scenes, like if you're in a town or a canyon, where there are a lot of shadows from all kinds of vertical objects, you don't get much of that in KSP. The scenes we do get are pretty natural, and you can get very good look out of them by using prebaked lights. Can you get better quality with RT? On a powerful PC, yeah. On console hardware? I'm honestly not sure. But what you'll get won't be worth the effort. So conventional lighting still wins.

That leaves the craft. This is the only part of the scene that might actually benefit from RT if it's done right. Baking light probes for your craft doesn't really work because there is staging, moving parts, and occasionally things explode. So getting good global illumination with rays is a lot easier. The craft can also have reflective bits, and SpaceX has demonstrated with a Tesla Roadster in orbit, planets reflecting off shiny bits make for great visuals. This would be a lot of work to get it right, though. Unity's support for ray tracing is still in preview, and you need people who really know what they're doing on this. Realistically, you'll need to hire a dedicated graphics engineer with RT experience just to work on this to get it in time for release. All the racing games devs obviously think it's worth it. But is it for KSP2? I don't know. And it doesn't look like Intercept currently has developer resources to throw around.

[TLTay]

8 hours ago, K^2 said:

Yes, graphics in a game engine usually runs on its own thread. What do you mean, that's not what you've meant?  

I agree that KSP2 will have to push graphics a lot further than KSP, but I'm not sure ray tracing will help a whole lot, and I'm usually the guy who pushes for broader RT use. It just... Doesn't help you render a planet, unless you throw a LOT of RT power at it. Talking about all the things Ray Tracing can do and how much of it you can support on next-gen is a complicated topic. Especially, because specs aren't public yet, so even things I know I can't discuss.

But in broad terms, the hardware isn't quite there yet to just straight up ray-trace the entire scene and completely abandon conventional rendering. You need very complex BVH and a lot of rays to achieve that, and even 2080Ti just can't in realistic scenarios. Instead, what you normally do is render scene as normal, and then use RT to improve lighting or reflections. Again, speaking very broadly, you can improve reflections, global illumination, and shadows. This can be absolutely phenomenal for creating atmosphere in some games, but KSP2 doesn't have scenes where it pays off.

Lets break it down a bit. I would broadly break down the components of the scenes into 3 categories. Planets that you're on the surface of or in low flight over, including terrain, sky, and weather rendering as applicable; planets that you're in proximity of, such as when you're in orbit; and your actual craft. You can have all 3. If you're flying over Lathe, you obviously have your craft, the terrain of Lathe bellow you, the sky above, and possibly, Jool occupying a solid chunk of it. All of these have to be handled differently.

Lets start with planets you are orbiting. Can you improve these with RT? Maybe, but it doesn't seem cost-effective. The only fancy things that can be going on are things like crater shadows and atmospheric scattering. You can try to get that with RT, but you'll need a ton of rays to get good resolution out of it without noise. It's way, way easier to just write custom shaders for these things. You can get absolutely amazing looking planets with conventional shaders if people writing them understand light theory and scattering processes. If you don't, they won't write a good ray tracer, either, so all around, you're better off with conventional shaders.

The planets you're in flight over are more interesting. Here, shadows really can be improved, especially, once you take global illumination into account. You can get better time of day and weather visuals for sure. But RT is still an expensive way to get these. And while it can pay off in very complex scenes, like if you're in a town or a canyon, where there are a lot of shadows from all kinds of vertical objects, you don't get much of that in KSP. The scenes we do get are pretty natural, and you can get very good look out of them by using prebaked lights. Can you get better quality with RT? On a powerful PC, yeah. On console hardware? I'm honestly not sure. But what you'll get won't be worth the effort. So conventional lighting still wins.

That leaves the craft. This is the only part of the scene that might actually benefit from RT if it's done right. Baking light probes for your craft doesn't really work because there is staging, moving parts, and occasionally things explode. So getting good global illumination with rays is a lot easier. The craft can also have reflective bits, and SpaceX has demonstrated with a Tesla Roadster in orbit, planets reflecting off shiny bits make for great visuals. This would be a lot of work to get it right, though. Unity's support for ray tracing is still in preview, and you need people who really know what they're doing on this. Realistically, you'll need to hire a dedicated graphics engineer with RT experience just to work on this to get it in time for release. All the racing games devs obviously think it's worth it. But is it for KSP2? I don't know. And it doesn't look like Intercept currently has developer resources to throw around.

I think you know way more about this than I, and are probably right about it being far more work than it is worth for a big performance hit. I wouldn't risk delaying the release over RT, it's not worth that. Hopefully hardware and budgets will allow for some RT options as the game matures over the years, even if it's just window reflections or something small.

Frankly, the duna base area shown in the most recently released dev video was pretty promising. I would not be unhappy if the release looked about like that. I just really want KSP2 to look better than a heavily modded KSP1.

[Incarnation of Chaos]

On 7/13/2020 at 3:44 PM, K^2 said:

Yes, graphics in a game engine usually runs on its own thread. What do you mean, that's not what you've meant?  

I agree that KSP2 will have to push graphics a lot further than KSP, but I'm not sure ray tracing will help a whole lot, and I'm usually the guy who pushes for broader RT use. It just... Doesn't help you render a planet, unless you throw a LOT of RT power at it. Talking about all the things Ray Tracing can do and how much of it you can support on next-gen is a complicated topic. Especially, because specs aren't public yet, so even things I know I can't discuss.

But in broad terms, the hardware isn't quite there yet to just straight up ray-trace the entire scene and completely abandon conventional rendering. You need very complex BVH and a lot of rays to achieve that, and even 2080Ti just can't in realistic scenarios. Instead, what you normally do is render scene as normal, and then use RT to improve lighting or reflections. Again, speaking very broadly, you can improve reflections, global illumination, and shadows. This can be absolutely phenomenal for creating atmosphere in some games, but KSP2 doesn't have scenes where it pays off.

Lets break it down a bit. I would broadly break down the components of the scenes into 3 categories. Planets that you're on the surface of or in low flight over, including terrain, sky, and weather rendering as applicable; planets that you're in proximity of, such as when you're in orbit; and your actual craft. You can have all 3. If you're flying over Lathe, you obviously have your craft, the terrain of Lathe bellow you, the sky above, and possibly, Jool occupying a solid chunk of it. All of these have to be handled differently.

Lets start with planets you are orbiting. Can you improve these with RT? Maybe, but it doesn't seem cost-effective. The only fancy things that can be going on are things like crater shadows and atmospheric scattering. You can try to get that with RT, but you'll need a ton of rays to get good resolution out of it without noise. It's way, way easier to just write custom shaders for these things. You can get absolutely amazing looking planets with conventional shaders if people writing them understand light theory and scattering processes. If you don't, they won't write a good ray tracer, either, so all around, you're better off with conventional shaders.

The planets you're in flight over are more interesting. Here, shadows really can be improved, especially, once you take global illumination into account. You can get better time of day and weather visuals for sure. But RT is still an expensive way to get these. And while it can pay off in very complex scenes, like if you're in a town or a canyon, where there are a lot of shadows from all kinds of vertical objects, you don't get much of that in KSP. The scenes we do get are pretty natural, and you can get very good look out of them by using prebaked lights. Can you get better quality with RT? On a powerful PC, yeah. On console hardware? I'm honestly not sure. But what you'll get won't be worth the effort. So conventional lighting still wins.

That leaves the craft. This is the only part of the scene that might actually benefit from RT if it's done right. Baking light probes for your craft doesn't really work because there is staging, moving parts, and occasionally things explode. So getting good global illumination with rays is a lot easier. The craft can also have reflective bits, and SpaceX has demonstrated with a Tesla Roadster in orbit, planets reflecting off shiny bits make for great visuals. This would be a lot of work to get it right, though. Unity's support for ray tracing is still in preview, and you need people who really know what they're doing on this. Realistically, you'll need to hire a dedicated graphics engineer with RT experience just to work on this to get it in time for release. All the racing games devs obviously think it's worth it. But is it for KSP2? I don't know. And it doesn't look like Intercept currently has developer resources to throw around.

I actually have somewhat of an related-unrelated question here. One of the persistent issues in KSP is that there doesn't seem to be a good way to determine where a light source (I.E a star) is coming from, and i know that while workarounds exist for this i was actually wondering if RT related technology could help here. Now I'm pretty sure making every star cast enough rays to properly illuminate everything would set anything barring a large supercomputer on fire, but would there be a way to have a more bespoke solution? Like being able to "Request" a Ray to strike an object on demand with a function; just to get the proper magnitude and direction so doing things like solar panels and the like is easier? Though...now that i think about it, a Vector could do that. But i was thinking the benefit of using a Ray would be that if you split a panel into individual elements, and each one made a call that the Ray would occlude when necessary and make situations where only a sliver of the panel is shaded but the entire panel generates no power much less common. 

Only reason i'm curious is that KSP2 will have multiple systems from the start, so they'd have to have a solution for solar panels from the beginning.

[K^2]

1 hour ago, Incarnation of Chaos said:

I actually have somewhat of an related-unrelated question here. One of the persistent issues in KSP is that there doesn't seem to be a good way to determine where a light source (I.E a star) is coming from, and i know that while workarounds exist for this i was actually wondering if RT related technology could help here. Now I'm pretty sure making every star cast enough rays to properly illuminate everything would set anything barring a large supercomputer on fire, but would there be a way to have a more bespoke solution? Like being able to "Request" a Ray to strike an object on demand with a function; just to get the proper magnitude and direction so doing things like solar panels and the like is easier? Though...now that i think about it, a Vector could do that. But i was thinking the benefit of using a Ray would be that if you split a panel into individual elements, and each one made a call that the Ray would occlude when necessary and make situations where only a sliver of the panel is shaded but the entire panel generates no power much less common.

RT hardware doesn't do anything you wouldn't already be doing as part of your physics engine. The RT ray casts work exactly the same as ray probes in PhysX/Unity. The only difference is how many rays you can cast on CPU vs GPU. Even without RT-specialized hardware, GPU can handle more ray casts than a CPU, but you have to do your own work setting up accelerator structures, such as BVH. Hardware ray tracers plus associated graphics libraries make that even faster and easier to set up. Bit I don't think KSP had a problem with how many rays you could cast - a sample of a dozen random rays between random point on the solar panel and random point on the near side of the star is adequate to get a fair estimate for efficiency, especially if you do some time-averaging between frames. Again, it's very similar to how you would do soft shadows on GPU with ray tracing, but since you don't need accurate measure of solar flux at every point you can see in the scene, you just don't have to throw GPU power at it. The number of rays you can cast on CPU are enough.

I haven't looked into it specifically, but my first guess for why it's hard in KSP would be how much of collision scene needs to be loaded. It should be very easy and cheap to check for craft occlusions, for example. You already have all of that as part of your collision scene, so Unity is all set up to do ray checks against the craft. Nearby terrain, like a rock you're right next to, should also be easy for the same reason. If either of these are already causing problems in KSP, there's something fishy going on. The next step up is entire planets/moons getting in the way. Trivial case is being on the night side of a planet, but you could also be having an eclipse or even just a significant transit that causes some dimming. This would require a separate ray cast on star system scale, but that should be very simple. Ray vs sphere collision check is the cheapest one you can do, and even if you just brute-force all planets and moons, it's really easy to check for this sort of thing. You first check if the ray hits a spherical representation of any planet or moon, and if not, then you check against collision scene. That gets you most of the way there.

Where this breaks down with the way KSP is set up is occlusions by mountains on the horizon, for example. Something that's far enough away that it's unloaded from collision scene, but large enough that it can cast shadows when sun is low. You obviously can't keep detailed terrain collision for distant objects, because that's just too much memory and computation required to handle. The real solution is to be handling it the same way you handle rendering. You don't draw every triangle of terrain for distant objects. You have simpler, low poly representations you render instead. So a mountain up close might have tens of thousands of polygons, while one on horizon would be rendered with a few dozen. Likewise, for purposes of solar panel occlusion, you don't need to load mountain in all its glory. You could substitute in a much simpler collider. I haven't seen a good way to do this in PhysX, so this would require custom code, but it's exactly the same situation with GPU RT. Either way, you have to write an LoD system for your collision scene, and if you're doing that for either system, you might as well just do it all on CPU for better support on mid-range PCs.

It is rather edge-case, though. So if solar panels are wonky in more cases than that, I'm not really sure what's going on there. It's not that hard of a problem...

[mcwaffles2003]

I just hope we get another push past the new surface textures for planets brought in the past few updates. Getting to the new Duna, to me was a bit jaw dropping. Hopefully we can get some procedurally generated collidable ground scatter (no more driving through giant boulders) 

[έķ νίĻĻάίή]

Clouds are already basically confirmed, and that's all I need

Edited July 21, 2020 by έķ νίĻĻάίή

[Danielle]

Seeing that PBR Textures are at full throttle for planetary bodies, do you think they'll go volumetric fogs for the atmospheres and gas planets? Or gas planets will be shader-based and with most effects being screen spaced. I'm hoping for a more visually livid representation of particles at the asteroid belt and planetary ring. A huge plus for enhanced atmospheric transition between the transition of atmosphere and space.

We'll probably see last/current gen implementation of lighting systems. Ray-tracing is very expensive and mainstream adoption of dedicated hardware is still quite low due to the prices for the cards. 

[K^2]

11 hours ago, Danielle said:

Seeing that PBR Textures are at full throttle for planetary bodies, do you think they'll go volumetric fogs for the atmospheres and gas planets? Or gas planets will be shader-based and with most effects being screen spaced. I'm hoping for a more visually livid representation of particles at the asteroid belt and planetary ring. A huge plus for enhanced atmospheric transition between the transition of atmosphere and space.

If you're well above atmo, doing any kind of volumetrics is way overkill. Rendering atmo as a shell is quite sufficient, and you can write a shader that estimates scattering for every point. So I'd probably just use a normal forward pass on this. For rendering clouds from within atmosphere, there are plenty of standard methods. A simple ray caster can give you amazing fractal clouds at barely a hit to performance. All of this is pretty simple to set up in Unity.

[Danielle]

15 hours ago, K^2 said:

If you're well above atmo, doing any kind of volumetrics is way overkill. Rendering atmo as a shell is quite sufficient, and you can write a shader that estimates scattering for every point. So I'd probably just use a normal forward pass on this. For rendering clouds from within atmosphere, there are plenty of standard methods. A simple ray caster can give you amazing fractal clouds at barely a hit to performance. All of this is pretty simple to set up in Unity.

What do you think will the implementation of planetary weather would be like? Akin to Martian Dust Storms or water planet waves.

[K^2]

5 hours ago, Danielle said:

What do you think will the implementation of planetary weather would be like? Akin to Martian Dust Storms or water planet waves.

I don't know what Intercept actually has time for. Weather can be super complex, and since I'm not a rendering engineer, I'm not necessarily the best person to ask about it. But traditionally, the way you'd do sand storms is just volumetric fog and particles. Looking at Red Dead Redemption 2, which has a better looking weather among recent games, it looks like that's all they did. This is computationally cheap, easy to set up in Unity, and looks reasonably convincing. If this is what Duna sandstorms look like, I won't complain.

I am a bit more familiar with water. State of the art there is running a very simple linearized surface wave simulation. This can be done in real time in frequency domain at a cost of a few FFT operations, or can actually be precomputed and stored as tillable texture. The later can be done with custom simulation, but Blender and Houdini have built in ways to handle it as well. You avoid tiling by doing this at several different scales, similar to how you'd handle noise maps. This approach is based on work of Jerry Tessendorf and has almost completely replaced the older method that was based on Gerstner Waves. A good example of a game that does this is Sea of Thieves. Of course, a big part of it is actually rendering water, which is not trivial at all, and there are plenty of talks on that out there. The key is you at least have to fake scattering or it will look completely fake. Getting water to look as good as in Sea of Thieves is a lot of work, and I wouldn't expect that quality, but there are definitely options for something that's very reasonable.

The hardest thing about weather is how much of it there is. Fortunately, we get a pretty good selection of it on Earth, so the tech for it is well developed. Given the scope of KSP2, I don't expect them to get all of it perfectly. Corners will have to be cut, I'm sure. If they have same tech for sand and snow storms, for example, with just a texture swap, that's good enough. Rain can use parts of that as well. In general, I just kind of want weather to be there, but I don't expect dozens of worlds with unique weather patterns all done at AAA quality. There just aren't resources for that at Intercept.

[Incarnation of Chaos]

On 7/20/2020 at 1:59 AM, K^2 said:

RT hardware doesn't do anything you wouldn't already be doing as part of your physics engine. The RT ray casts work exactly the same as ray probes in PhysX/Unity. The only difference is how many rays you can cast on CPU vs GPU. Even without RT-specialized hardware, GPU can handle more ray casts than a CPU, but you have to do your own work setting up accelerator structures, such as BVH. Hardware ray tracers plus associated graphics libraries make that even faster and easier to set up. Bit I don't think KSP had a problem with how many rays you could cast - a sample of a dozen random rays between random point on the solar panel and random point on the near side of the star is adequate to get a fair estimate for efficiency, especially if you do some time-averaging between frames. Again, it's very similar to how you would do soft shadows on GPU with ray tracing, but since you don't need accurate measure of solar flux at every point you can see in the scene, you just don't have to throw GPU power at it. The number of rays you can cast on CPU are enough.

I haven't looked into it specifically, but my first guess for why it's hard in KSP would be how much of collision scene needs to be loaded. It should be very easy and cheap to check for craft occlusions, for example. You already have all of that as part of your collision scene, so Unity is all set up to do ray checks against the craft. Nearby terrain, like a rock you're right next to, should also be easy for the same reason. If either of these are already causing problems in KSP, there's something fishy going on. The next step up is entire planets/moons getting in the way. Trivial case is being on the night side of a planet, but you could also be having an eclipse or even just a significant transit that causes some dimming. This would require a separate ray cast on star system scale, but that should be very simple. Ray vs sphere collision check is the cheapest one you can do, and even if you just brute-force all planets and moons, it's really easy to check for this sort of thing. You first check if the ray hits a spherical representation of any planet or moon, and if not, then you check against collision scene. That gets you most of the way there.

Where this breaks down with the way KSP is set up is occlusions by mountains on the horizon, for example. Something that's far enough away that it's unloaded from collision scene, but large enough that it can cast shadows when sun is low. You obviously can't keep detailed terrain collision for distant objects, because that's just too much memory and computation required to handle. The real solution is to be handling it the same way you handle rendering. You don't draw every triangle of terrain for distant objects. You have simpler, low poly representations you render instead. So a mountain up close might have tens of thousands of polygons, while one on horizon would be rendered with a few dozen. Likewise, for purposes of solar panel occlusion, you don't need to load mountain in all its glory. You could substitute in a much simpler collider. I haven't seen a good way to do this in PhysX, so this would require custom code, but it's exactly the same situation with GPU RT. Either way, you have to write an LoD system for your collision scene, and if you're doing that for either system, you might as well just do it all on CPU for better support on mid-range PCs.

It is rather edge-case, though. So if solar panels are wonky in more cases than that, I'm not really sure what's going on there. It's not that hard of a problem...

Yeah all RT hardware is are Matrix Units from what iv'e seen (Specifically I'm pretty sure they're 4X4) ; they're just accelerating existing calculations that would take too long on the GPU/CPU (Nividia uses them for Denoising of the rough RT scenes last i checked). So i wasn't thinking they're magic; just trying to think of something that they could be leveraged for that most everyone could benefit from.

But from your description it sounds more like an issue created by how KSP handles the pipeline in the first place, rather than a lack of a workable solution. Thanks for the answer anyway.