Jump to content

Gameslinx

Members
 View Profile  See their activity

  • Posts

    2,918

  • Joined

  • Last visited

 Content Type 

Posts posted by Gameslinx

    [1.12.x] Parallax - PBR Terrain and Surface Objects [2.0.2]

    in KSP1 Mod Releases

    Posted

    22 minutes ago, Whovian41110 said:

    I’ve seen that a scatter density multiplier is what I should be using for a scaled up system. Sorry if this is a silly question, but I am running a 6.4 X system and I’m curious what the maximum I can get out of the mod is. I am running a Ryzen 7800X3D, a RX 7900 XT (12gb of VRAM) and 32 gb of RAM. I’ve seen earlier in the thread that 50 is the maximum multiplier that most people usually take, but I was curious if anyone had some scaled system tips

    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

    [1.12.x] Parallax - PBR Terrain and Surface Objects [2.0.2]

    in KSP1 Mod Releases

    Posted

    26 minutes ago, Bizobinator said:

    Hello! I've been getting a sort of...I don't know whether it's a model or texture bug or something else entirely, on Eve. Everything looks fine when I initially start playing but, after some amount of scene switching, I eventually start getting these bland looking objects (see imgur link).
    https://imgur.com/a/diX1RwX

    Here's my player log. I tried looking through it, but I couldn't make too much sense of it :(. Has anyone else encountered something like this before?

    https://www.dropbox.com/s/gzjm512pfp3649l/Player.log?dl=0

    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

    [1.12.x] Parallax - PBR Terrain and Surface Objects [2.0.2]

    in KSP1 Mod Releases

    Posted

    42 minutes ago, space_otter said:

    I am getting an error on the loading screen.

    "Your system does not support compute shaders". I believe I have everything installed as planned. I am running a Mac computer, but I don't have the scatters installed so I hoped it would be fine.

    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

    [1.12.x] Parallax - PBR Terrain and Surface Objects [2.0.2]

    in KSP1 Mod Releases

    Posted

    45 minutes ago, UltraJohn said:

    I am curious if this new update will improve the performance and density on rescaled systems?

    Right now on a 10x rescale, I'm having to increase the densityMultiplier to 100 (according to other posts) to get the same density as normal. Though any value higher than 40 or so will just crash my game, presumably because of running out of ram. Also increases load times by a large factor and seems to cause microstutters.

    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.

    [1.12.x] Parallax - PBR Terrain and Surface Objects [2.0.2]

    in KSP1 Mod Releases

    Posted

    1 hour ago, ShadowDr said:

    Huh, does it mean that Unity's own code is somewhat cheeks shaped?

    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

    [1.12.x] Parallax - PBR Terrain and Surface Objects [2.0.2]

    in KSP1 Mod Releases

    Posted

    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!

    [1.12.x] Parallax - PBR Terrain and Surface Objects [2.0.2]

    in KSP1 Mod Releases

    Posted

    13 hours ago, ShadowDr said:

    are current KSP2 devs aware of this tech

    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

    13 hours ago, ShadowDr said:

    could we have some more scatter related values moved out into config, for fine tuning? My own wishlist would have scatter scaling and density per type (if possible, also per planet or even per biome) and perhaps something related to the noise pattern

    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

    [1.12.x] Parallax - PBR Terrain and Surface Objects [2.0.2]

    in KSP1 Mod Releases

    Posted

    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:

    1. Scatters 'disconnecting' from the ground and appearing in the air until regenerated
    2. Scatters flickering when vessel is destroyed
    3. 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.

    unknown.png?width=1920&height=546

    (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:

    1. Scatter transforms are generated in local space (GeneratePositions.compute)
      • Step 1 occurs every time a quad is built
    2. Scatter transforms transformed to world space before culling (EvaluatePositions.compute)
    3. Frustum culling, range culling, process LODs in world space (EvaluatePositions.compute)
    4. 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.

    JqoKZ1a.png

    (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.

    1. First, the quad position needs to be noted at the time of scatter generation
    2. 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
    3. Scatter positions are transformed back into local space using the 'old quad' transform matrix
    4. 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
    5. 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:

    1. Request the scatter transforms from the GPU (they will be in local space)
    2. Transform the positions into world space using the quad's current transform matrix
    3. 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! :) 

    Developer Insights #18 - Graphics of Early Access KSP2

    in Dev Diaries

    Posted · Edited by Gameslinx

    56 minutes ago, Intercept Games said:

    This visual polish comes at the cost of accessing each texture a few more times, putting strain on the memory bandwidth of the GPU

    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

    [1.12.x] Parallax - PBR Terrain and Surface Objects [2.0.2]

    in KSP1 Mod Releases

    Posted

    6 minutes ago, Eleven said:

    I always forget to mention. I play on Linux. 

    Player.log: https://drive.google.com/file/d/1GerZhLWMLGrERq5_nrP2kaLYUk7Zbr4v/view?usp=sharing

    Player-prev.log: https://drive.google.com/file/d/1Y6aErDwNonVKnV_A73lFSy6fkJbVakj6/view?usp=sharing

    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

    [1.12.x] Parallax - PBR Terrain and Surface Objects [2.0.2]

    in KSP1 Mod Releases

    Posted

    1 minute ago, Eleven said:

    Thanks for the quick reply!

    Unfortunately when I removed contract configurator (and the contract packs folder) the game still crashes. But if I remove Parallax (and the stock textures folder) the saves load just fine. I previously removed EVERY mod except Parallax and the game still crashed when switching scenes. The only time it does not crash in that scenario, is on a brand new save, at day 1. In that scenario I can have as many mods installed as I want and it's no prob. Could it be something in the persistent file of existing saves?  I'm a total noob at reading the log files, but here's the new file with contract configurator removed and the game still crashing:

    https://drive.google.com/file/d/1Af7chnp952wT6hxL4lmS1jx-6mGUAK07/view?usp=sharing

    Can you also send Playerprev.log and Player.log? They are located here: 

    C:/Users/UserName/AppData/LocalLow/Squad/Kerbal Space Program

     

    [1.12.x] Parallax - PBR Terrain and Surface Objects [2.0.2]

    in KSP1 Mod Releases

    Posted

    1 hour ago, Kerballlistic07 said:

    I must say, now that KSP 2 EA is out, I think that this mod looks better than KSP 2. More ground scatter, better lighting, etc. Honestly Linx, you did a phenomenal job making this, especially because it can run on hardware way below than KSP 2 minimum. (Note that I am saying these things without having actually played KSP 2. My computer can't handle that! :/)

    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!

    [1.12.x] Parallax - PBR Terrain and Surface Objects [2.0.2]

    in KSP1 Mod Releases

    Posted

    On 1/7/2023 at 5:42 AM, bQuest said:

    TL;DR Parts crashing or going EVA causes it to flash and lag, But pausing seems to reset and fix it, I have no clue why this happens.

    Thanks for reporting. I am currently investigating this

    On 1/9/2023 at 3:18 AM, NielsGx said:

    It works well, really well, but I have a lot of stutters because my 6GB of VRAM are full

     

    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!

     

    On 1/21/2023 at 8:03 PM, DevCo said:

    I am trying to enable Tessellation on Parallax in KSP 1.12.5 and I'm unable to set my Terrain Shader Quality to Ultra, when I set it and apply and accept the settings, it doesn't change. If I set it in the settings.cfg file Parallax says it is in Ultra and that Tessellation is enabled but when I load a save it is not enabled and the setting is back to High. Anyone ever run into this issue?

    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.

    On 1/22/2023 at 12:21 PM, pmborg said:

    Hello and welcome! My suggestion it to do this: edit the default config file and enable the collisions I don't know why this is not the default...

     

    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

    3 hours ago, ltajax said:

    Any one else had an issue where the scattered trees will appear again when you are at a high altitude during launch ?

    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

    [1.12.x] Parallax - PBR Terrain and Surface Objects [2.0.2]

    in KSP1 Mod Releases

    Posted

    On 12/28/2022 at 8:26 PM, bQuest said:

    Once I exit my craft to explore whatever pine forest I just landed in, My fps drops from 70 to 10-12 and the grass/trees flash for a few seconds

    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!

    2022 thread of the year

    in Threads of the Month

    Posted

    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 :) 

×
×
  • Create New...