Gameslinx

Absolutely. Although I haven't yet to test ingame, the on-paper benefits are pretty big. Some things may be unavoidable. KSP wasn't designed to work well at large scales and I am trying to add cool new tech to a very old and technically inefficient game. I'll see what I can do but no promises! I imagine you will realistically be able to achieve a higher density before running out of memory, but who knows.

It could be. But DrawMeshInstancedIndirect appears to be a much lower-level command in that it's very specific and very direct "draw this here now". I am really struggling to figure out how to correctly identify which shadow cascade an object is. I assumed it was camera distance based, but it's not in world space coordinates. Anyone with the know-how would be much appreciated, lol

Development Update - Performance VRAM Hey all, I've been spending some time working on the features I outlined in the last update (https://forum.kerbalspaceprogram.com/index.php?/topic/209714-112x-parallax-pbr-terrain-and-surface-objects-202/&do=findComment&comment=4257019). Essentially I am rewriting a core portion of the mod responsible for object placement in order to switch from world space to local space in order to fix many key positioning issues that can arise in the mod, such as the floating trees. I have also made an estimated reduction in VRAM usage of 56%. At least, this is the VRAM usage of the generated objects on all built quads within range before they are evaluated by the culling compute shader. Before, I would compute the localToWorld matrix immediately and store these ready for the culling shader to process them and output the objects in range. This matrix is 16* 4 bytes. Now that the system works in local space, I only need to store the local position, rotation and scale as a float3, float and float3 (7 * 4 bytes). The culling shader now does a little extra work to construct the localToWorld matrix every frame, but this isn't too expensive to do. More testing - and in-game - will tell me more. But for now, this is looking promising. FPS I am able to make an approx 4x reduction in performance impact with shadows enabled. A fun drawback of Unity's DrawMeshInstancedIndirect function is that it draws the mesh in all shader passes in all shadow cascades. A shadow cascade is a region of shadow based on distance from the camera of varying quality. Further away objects will use a lower quality shadow map - a higher shadow cascade. With 4 shadow cascades, each object is rendered once for the scene and one additional time for each shadow cascade. This leads to rendering the object 4 times when it only lies in one shadow cascade. I have some preliminary but not perfect code in place to differentiate Parallax objects into 4 regions based on which shadow cascade those objects lie in. Each set of objects are drawn using a command buffer before each relevant shadow cascade renders. This means that most objects will be drawn just once for the shadow pass, and very few will be drawn twice if it lies within two cascades. Quick note - This technique will reduce the number of vertices rendered by around 75%. In a unity test scene with this code and a lot of objects, frame time changed from 17ms (58fps) to 4.4ms (227 fps) which is roughly a 4x increase in performance. I am looking forward to sharing more with you all soon!

I would imagine they are. For one, they haven't approached me about anything, but there are many people out there far more capable than I am lol I can do this but 'per type' is a fairly abstract concept. Internally there are 4 types of scatters: Nearest Quad - High density non persistent scatters (like grass) Fixed - Persistent collideable scatters, such as trees or rocks Volume (VerticalStack) - Persistent, collideable, and can stack on top of each other. Like the kelp, for example FixedHeight - Positioned to a certain min / max height constraint - Like the icebergs I could add per-planet settings but outside of the UI this creates problems with planet packs, but it is something I can look into doing. Btw, Kerbals are 0.75 meters tall. Most uncut, ungrazed grass on Earth can get to around that height. So, to be fair, the grass is a 'correct' size if we were being realistic. The real reason the grass isn't smaller is because of density limitations - The current VRAM usage is slightly too high for me to want to reduce the size of the grass. You might think 'why does the grass size correlate with VRAM usage?'. Good question! That's because if I reduce the size of the grass, they cover less area - meaning I need to increase the amount of grass objects to maintain the same coverage

This is caused by KS3P and its ambient occlusion. You should switch to TUFX, as it is the successor to KS3P edit: got ninja'd lol

Development Update Hey all, I am going to start working on some pretty big under-the-hood changes to the scatter system over the next few weeks. There are some fairly common occurring issues that have been identified that these changes should hopefully address: Scatters 'disconnecting' from the ground and appearing in the air until regenerated Scatters flickering when vessel is destroyed Significant VRAM usage I am confident issues 1 and 2 will be resolved by this new system but I can't promise the third will be entirely addressed, but this is probably the best shot at it I have. (Floating scatters!) Why? Parallax uses compute shaders to generate the scatters' transforms (position, scale, rotation). When I wrote the original system I didn't take into account every nuance of the floating origin system in KSP. The floating origin is when the origin of the world (0,0,0) is set to the craft. Instead of the craft moving around the world, the entire world moves around the craft. However, this isn't the case all the time when the craft is close to a planet. I did take these inconsistencies and the floating origin into account when I wrote the scatter system, but not in an ideal way. The compute shaders that actually generate the scatters work in world space rather than local space. Local space doesn't care about the floating origin offset and instead relies on being transformed into world space by the terrain quad's localToWorld transform matrix. The new system I am proposing will work like this: Scatter transforms are generated in local space (GeneratePositions.compute) Step 1 occurs every time a quad is built Scatter transforms transformed to world space before culling (EvaluatePositions.compute) Frustum culling, range culling, process LODs in world space (EvaluatePositions.compute) Output buffer of objects to be instanced Steps 2, 3 and 4 occur every frame This system negates the need to regenerate scatters when the floating origin changes unexpectedly such as when a craft is destroyed, kerbal EVA, etc. This tackles issues 1 and 2. This also means that the collider generation system will run faster. (Image from the first beta testing build of Parallax - I was an idiot and overlooked incorrect stride because it only affected 10xx series GPUs) Collider System Right now, the collider system has to undo a lot of the work that the floating origin does for us. Here's how it works right now. I will use 'position' instead of transform here because it's easier to visualize. First, the quad position needs to be noted at the time of scatter generation When the scatter transforms are requested from the GPU, they are in world space but these positions are at the time of quad generation which can be a long time before the colliders are ever generated - the floating origin could have moved during this time Scatter positions are transformed back into local space using the 'old quad' transform matrix Scatter positions are then transformed back into world space using the quad's current transform matrix - this is the true position the quad is currently in Colliders are then generated As you can see, this process is lengthy and can be shortened very easily. This system also takes a significant amount of time to complete and, if you drive around on Dres which has a lot of scatter objects, you will notice the hitching when colliders are generated. My proposed solution will work as follows: Request the scatter transforms from the GPU (they will be in local space) Transform the positions into world space using the quad's current transform matrix Generate colliders This would simplify the entire collider generation process. I could also switch from using a quad tree to evaluate which colliders are nearby and instead just run a compute shader to simplify things. The compute shader would use a slower algorithm but because GPUs are so parallel, it would end up taking less time (and memory!) Summary There are a lot of potential optimizations and fixes that I can implement from looking at these two systems. I intend to start in around a week or two once I'm past 'deadline day' at university. Until then, keep reporting bugs and I will address them soon!

I cannot quite recall what causes the saturated Kerbin bug (it could be AVP?) but I know for a fact that it isn't Parallax that causes it. Parallax doesn't change the Scaled Space planet textures or shaders at all

Assuming the terrain shader is using Triplanar Mapping, this means that the samples for the anti-tile system increase by an additional factor of 3. KSP1's method of just scaling the texture based on the log of the camera distance from the terrain worked well enough, and might be a suitable replacement for low/medium graphics. That only required 2 samples * 3. Also, since this is not mentioned often and articles about it are far and few... Triplanar mapping is superseeded by biplanar mapping which only requires 2 texture samples instead of 3, offering an immediate +50% performance at expense of a small additional amount of math. https://iquilezles.org/articles/biplanar/ Edit: For those interested, here is information on Concurrent Binary Trees (please don't call the new system CBT, you will be made fun of) and their implementation: https://onrendering.com/data/papers/cbt/ConcurrentBinaryTrees.pdf

Oh man. Looking at both of these I still can't see why the game crashed. Normally there's a line 'Crash!!!', but in this case the log just ends. Can you see if there's a crash report in that same location I mentioned? If there is one, send it my way. If there isn't - I have no idea what's causing your crash - certainly not memory / VRAM related that's for sure

Can you also send Playerprev.log and Player.log? They are located here: C:/Users/UserName/AppData/LocalLow/Squad/Kerbal Space Program

Parallax does not affect saves. Your save crash looks to be caused by Contract Configurator

Check the OP, there's one linked there

Cheers. I might be able to work on some of the bugs reported in the last ~10 pages of this forum some time this week and next, deadlines depending Busy times at university right now!

Thanks man! I try Honestly I must agree - but I am excited to see where KSP2 goes with the system as it is in its early stages. Nontheless I really appreciate the feedback!

Thanks for reporting. I am currently investigating this This is something I'm also looking into. The high VRAM usage has been something I have been trying to address for a long time, and it is difficult to pinpoint exactly why it is so high. This is the reason there hasn't been an update for a while - I'm trying to solve this! This is caused by a config in the GameData/Kopernicus/Config folder 'Kopernicus_Config.cfg'. Change the parameter "EnforcedShaderLevel" such that it equals 3 instead of 2. Colliders are more CPU heavy, and people who have already established bases on planets will end up with not very well established bases if this was enabled by default. It will remain disabled Yes - This is an issue I'm also working on. It's a bit more difficult to fix because it relies on a function in KSP's codebase that would be easy to call to fix a lot of the issues outlined in the last month or so, but unfortunately its implementation into the base game is poor and I have to come up with a feasable workaround. That is the last of the catching up I needed to do - I have a lot of time taken up IRL by studying at the moment, so progress has been slow on these issues