Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by Gameslinx

  1. So happy to see you on the team after all these years! Great work, I'll definitely be taking away some points from this for my own projects ;)
  2. I do not plan on updating it again. Although, @ballisticfox0 maintains an up-to-date version of the mod with an updated Parallax version
  3. 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.
  4. 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
  5. 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!
  6. 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
  7. 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
  8. 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!
  9. 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
  10. 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
  11. 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
  12. Can you also send Playerprev.log and Player.log? They are located here: C:/Users/UserName/AppData/LocalLow/Squad/Kerbal Space Program
  13. Parallax does not affect saves. Your save crash looks to be caused by Contract Configurator
  14. 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!
  15. 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!
  16. 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
  17. This happens when the scatter system needs to regenerate objects because the world origin changed. It shouldn't take longer than half a second on slow systems, so I'm curious as to why this has such an impact for you. When you reproduce this, does the grass flash multiple times? This might indicate the regeneration occurring more than once and could be the source of your lag. Let me know!
  18. Oh wow! I haven't been on the forums this year up until recently. This has absolutely made my day. Thank you for all the kind words! There are so many other mods / threads deserving of this title as well. I for one am particularly interested in @blackrack's work on bringing volumetric clouds to the game. Can't wait to see where that goes! Happy new year
  19. Find GameData/Parallax_StockTextures/_Configs/IncreaseSubdivisionCount.cfg. Scroll down to @Body[Duna] Now delete the "VertexHeightNoiseVertHeightCurve2" and "VertexRidgedAltitudeCurve" nodes. This should be from line 85 to line 145. Save and restart the game
  20. I'm still investigating this myself, but I have heard that using the Settings.cfg file I provided in the OP under the 'troubleshooting' section should help you here. Which planets/moons are they landed on? I believe Laythe, Duna and Vall may be affected
  21. By default I use the LOD0 for all of the colliders. I wanted accurate collisions to the visual mesh. Only colliders directly next to the craft are ever enabled, so there is negligible impact to performance from the collider itself!
  22. I would need more opinions on this before I make this change go through I think a good approach would be to make the tree trunks collideable but not the leaves. It would be a surprise to anyone flying in forests now. Let me know
  23. Without Scatters, Parallax just does surface texture/shader changes for each of the planets. To disable scatters, there is a parameter in 'ParallaxGlobal.cfg' called 'enableScatters'. If you set it to false, scatters will not show up anymore for you
  24. I have made it fairly clear that I will not be making configs for RSS or any other planet packs - that is the responsibility of the planet pack author just as it is with EVE, Scatterer or any other visual mod However, version 2.0.6 will work on RSS even though RSS uses version 1.3.1, so you can now get the performance benefits on older versions.
  • Create New...