foonix

I hadn't had a chance to really watch it but just remembered this was here Can they do it independently? I think so. Nothing in CBT is married to HDRP. Would they want to? It's hard to say. If I were in there re-engineering the system knowing I'd eventually have to do it in HDRP anyway, I might want to target HDRP in the first place. Nothing jumped out at me as being impossible to do as part of the background render or in a custom render pass. It's just that engineering the color sampling to work with both their current PBR and HDRP's PBR seems like a lot of unnecessary pain. I learned a few other things watching though. Apparently the artists wanted to control the ambient light map in a way that has different emphasis for things like specular bounce, and such. They mentioned it is done from the cubemap sampling side, but for HDRP I believe the cubemap sampling is down in the guts of the HDRP/Lit shader, which has strict limits on what can be change about how light interaction works. So this will probably have to be moved to the cubemap generation process, which can be controlled from code. This throws some more complexity into the conversion process I hadn't realized. They may have to use different materials to render the planet when doing it in the cubemap to get this kind of effect.. which is doable but needs retooling and then an art pass to re-evaluate what they're trying to do works. But imagine something like this, potentially: you pan the camera at the Mun surface and the stars fade out as the camera focuses on the surface detail, then look back up at the sky and the surface washes out a bit while a sky full of stars and Kerbin comes back into focus. They mentioned that they control the directional light intensity based somewhat on the SOI.. that adds a lot of work I hadn't thought about.. at minimum will need an artist to take a pass at tweaking the levels for hdrp to get the desired look. From their diagram, they're probably not really following the inverse square law, which is fine, but this tells me perfectly realistic lighting isn't the goal. But HDRP could also open some opportunity to do things in ways that would have been hard with the current system.. they mentioned trying to adjust the light brightness to get a "moon landing" type feel to the images. HDRP has a notion of camera exposure control, so this kind of thing can be done not only based on SOI but also auto exposure change based on what the light levels are in the camera. Moon landing pictures where the stars aren't visible and the shadows are very hard, that is actually a byproduct of the interaction between the light levels and the exposure settings that had to be used in order to get any picture at all. HDRP should be able to do that kind of thing maybe a little bit too accurately. It can reproduce various physical camera artifacts at a very low cost as well.. I think the total difficulty is going to swing heavily depending on how hard they want to preserve prior artistic choices, and the willingness to lean into the new system to make different (potentially as good?) choices. My heart goes out to the graphics engineers and artists who are working on this... time to start sacrificing some Kerbals to the Kraken

After a lot of poking my nose under the hood, I have to say I'm pretty excited about HDRP. Below are just my random assessments and observations. KSP2 uses unity's legacy built-in render pipeline, but "retrofitted" with a lot of HDRP-like features. For instance, they're already using PBR-style shaders that use a cubemap for environmental lighting. HDRP uses PBR by default, and its "Environmental Lighting" system also uses a cubemap. KSP2 uses third-party deferred light/shadow shaders that support soft shadowing, where HDRP supports PCSS and screen space shadows out of the box. Most opaque materials in KSP2 use deferred rendering, but transparent materials use forward. HDRP supports mixed deferred and "Forward+" rendering, which may perform better in certain lighting situations. KSP2 uses some of the post-processing effects HDRP supports. However, HDRP combines a bunch of them into a single "uber shader", where as the old render pipeline has to apply them one-at-a-time while moving the result between buffers. There are various other postprocessing quality improvements available such as SSAO. KSP2 uses camera stacking for certain things like UI layering. Camera stacking is generally a bad idea in HDRP, but HDRP has features that would eliminate the need for most of the cameras. I've done a single camera that can render out to 100km, and the PQS/CBT might want to be engineered not as a separate camera (see HDRP "custom pass"). The UI camera can probably be eliminated just by moving the UI shaders to the right draw phase. So basically, it might be possible to shove the whole camera stack into one camera. Although HDRP cameras are a lot slower than old cameras, eliminating extra cameras has the benefit potentially reducing the number of culling operations, which might partially make up for it. KSP2 uses a setup that pumps planet cloud data into the volumetric cloud system. I've not used HDRP clouds so I can't comment on how "easy" this would be to use, But, HDRP's various volumetric effects are integrated with each other. For example "god ray" effects would be out of the question if volumetric processing is already turned on. IMHO a big potential win, from a performance standpoint, is might be SRP batching. In certain situations (eg, landed at KSC), draw call batching takes a significant portion of the frame loop. KSP2 uses instancing for a lot of the terrain clutter, which is quite fast in theory, but in practice gets split up into tiny batches due to a combination of material differences and distance sorting. There is potentially some chance to leverage the SRP batcher for this stuff, depending on how the materials are set up. Finally, a big difference is that all of the above (except PQS/CBT) in KSP2 are kind of mix and matched to work in spite of the old render pipeline, more so than with it. Doing them with HDRP means working with a product that was designed from the ground up to do these things, and shares various computational steps between them. The challenges I see: Every material needs to be retouched. At minimum, converted to HDRP/lit, HDRP/unlit, or some shadergraph shader. This process for some assets could be as simple as a tedious repack of the textures/ material. For some assets it may need to be re-baked for HDRP's specific type of PBR and AO mapping. Lighting in general works differently and needs to be retouched. Camera stacking has to be reduced. The way PQS and/or CBT interface with HDRP is different and will require reworking. However this might actually be _simpler_ as an HDRP custom pass. Environmental lighting works differently and may require some custom lighting, depending on how married to the current aesthetic they are.

I've already started working on an SRP prototype that is a drop-in replacement for the built-in pipeline in an attempt to cut out buffers and leverage SRP batching. I'll be glad to throw this out though! But HDRP is probably what I'd do if I were doing it from the source code end. There is just so much better about HDRP than builtin. But quite a lot of assets are going to have to be reworked. I can't understate how much of a challenge this is going to be.

With the dampeners turned down, it's pretty obvious that something in the system is adding energy to the system.. perfectly stationary craft will bounce higher and higher until the gear explode. Even with max dampener settings, it's not enough to stop the bouncing. No matter how heavy a craft is or how poorly aligned the gear are, a stationary craft shouldn't bounce higher on subsequent bounces.. Slashy's tweak helps a lot. The increasing bounce amplitude is still apparent with the dampener turned down.

Check that you downloaded the actual file. I tried to "Right click -> Save As" on the link above, and that was actually the page serving the file. I had to go to the page and click another download link.

Enabling surface attach also worked for me. attachRules = 0,1,0,0,0

I had this exact problem in Arch linux. mozroots didn't work, with or without sudo. ckan (libcurl) was looking for certs in /etc/ssl/certs/ca-certificates.crt. https://blizzy.de is using Let's Encrypt certificates, which were not in the open ssl trust store for the system. The following will fail if this is the problem: curl -I https://blizzy.de Once I fixed the above, ckan started working. The fix in arch, based on this document Download (do not install into the browser) the Let's Encrypt root and X1 intermediate certs from here: https://letsencrypt.org/certificates/ Copy both files to /etc/ca-certificates/trust-source/anchors/ and rename them .crt run: sudo trust extract-compat

With the changes to CompoundPart mentioned in the dev notes, would it be possible to have a piston that attaches like a strut? It could make controlling the same structure with multiple pistons easier, especially if it could function as if having a ball joint on both ends.

For working around the FAR problem, using the KerbalStuff URL seems to work

It would definitely solve the pain point of working with multiple sets of mods and fill the mod pack niche. It would also save a lot of disk space. It might be a bit tricky working with the saves. If a part does not exist when a save is loaded as I understand any craft using it will disappear. I would be worried about shooting myself in the foot switching between radically different profiles. There are some situations where it might be useful to run multiple versions of KSP its self though, such as after a new release when most mods are not compatible. I guess running multiple instances of the manager could solve this problem as well though. Another corner case may be if a mod pack maintainer needs to stipulate an older version of KSP.

Thanks for this. I've wanted a cross platform mod manager for a long time. It would be nice if it could roll a full installation from scratch. Combined with the mod list import/export, this could produce something similar to the way Feed the Beast launcher for minecraft works. It would be a killer feature to be able to click a few buttons to materialize a new KSP instance with all the mods as your favorite youtuber, for example. If a mod manager had such a feature for Interstellar Quest it would be the gold standard by now. The FTB launcher does packs really well, but it is not friendly for building your own custom installations. It might be enough to be able to "subscribe" an instance to mod pack. Maybe pack authors can just publish a meta-data URL, and the manager can poll it for updates. The meta-data would contain a list of each version of the pack, each version of each mod used therein. When the pack updates, the user is notified and can update all of the mods to the version listed in the pack.