Jump to content

Gameslinx

Members
  • Posts

    2,917
  • Joined

  • Last visited

Reputation

4,656 Excellent

Contact Methods

Profile Information

  • About me
    Celestial Terraformer
  • Location
    Underneath the terrain
  • Interests
    Not being under the terrain

Recent Profile Visitors

47,251 profile views
  1. As you scale a planet, its area increases by the scale factor squared. Since scatters cover a given area, you should multiply the density factor by square of the rescale value Although, there is a hardware limit to how high you can push it. For a 6.4x system you'll want to set the globalDensityMultiplier to around 41. Most people usually turn this down for performance reasons, since density multiplier is directly linked to RAM/VRAM usage. If you get crashes or the game simply doesn't load, lower the multiplier a bit
  2. It's a very rare occuring bug but it gets reported every now and then Yeah, I'm rewriting Parallax at the moment to get in a whole load of bug fixes and optimizations
  3. It's a bug in my texture loader somewhere. This should hopefully be fixed in the mod rewrite but it's still a fair bit of time out
  4. If you don't have the scatters installed, you can ignore this warning. As long as the terrain looks correct there's nothing to worry about Technical reason why: Apple dropped support for OpenGL and uses a version that does not support compute shaders which sucks. So while you can't use the scatters, the rest of the mod will work fine
  5. 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 ;)
  6. I do not plan on updating it again. Although, @ballisticfox0 maintains an up-to-date version of the mod with an updated Parallax version
  7. 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.
  8. 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
  9. 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!
  10. 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
  11. 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
  12. 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!
  13. 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
  14. 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
  15. 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
×
×
  • Create New...