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

[BIOZ]

Hi, @R33. Here it is https://drive.google.com/file/d/1UtvgKx3omym0C-XmU5mwSqNe6vb7426p/view

This config doesn't contain Earth. As I understand, right now Parallax has some problems with cbNameLater detection, which Earth depends on (or maybe it's just me stupid). I fixed it in my own dll, so if it's a real problem I'm sure it will be fixed properly very soon.

Actually I didn't planned to make my configs public, so I optimized them for my GTX 1660. If you have better/worse hardware, you can tweak the numbers in my cfg. Also afaik BallisticFox was planning to make Parallax configs for both KSRSS and RSS, so I recommend to check KSRSS thread from time to time .

Edit 230619: Update https://drive.google.com/file/d/1GRbAlGB4DWfu_uNoTgedpBhU6roWpMc_/view

Edit 230709: Earth is back https://drive.google.com/file/d/13CyIsn81f9htq1CrMDO-kqfUm2RZCXJX/view

Edited July 9, 2023 by BIOZ

[Carni35]

Also, is there a way to define scatter density body by body ?

I changed the ''spawning chance'' but it seems to change nothing

[Vphurple Izumi]

On 3/8/2023 at 9:00 PM, Gameslinx said:

Check the OP, there's one linked there 

So thats a no?

[Pluspython68]

I can't get parallax  to work. here is my ksp.log

[Blufor878]

On 2/21/2023 at 6:56 AM, Fezak said:

Found out that it's not that Kerbin turns into a never ending desert when I return from another body. But the ground changes color to the ground colors of the previous body I've been into. Tried going to Minmus and the ground of Kerbin turned into that minty green. Then tried Duna and Eve and that confirmed my theory.

I'm having the same issue.


Kerbin is this odd minty green color now.

The terrain looks fantastic though.

[Gameslinx]

52 minutes ago, Blufor878 said:

I'm having the same issue.


Kerbin is this odd minty green color now.

The terrain looks fantastic though.

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  

[Blufor878]

16 minutes ago, Gameslinx said:

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  

I’ve had AVP installed for awhile now. No issues like this. Odd. Might give that a try then.
Are there any graphics mods that won’t react well to Kopernicus/Parallax in your experience? Just want to cover my bases.

[Vanamonde]

Oopsie. Some posts removed. Keep it on-topic, please. 

[Bulltoad]

I found a bug which makes the scatter on planets turn black. Only fix I've found is a game restart. I really don't want to restart my game when this happens, because it happens alot. Are there any fixes???

[Gameslinx]

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.

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

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

[Pluspython68]

4 hours ago, Gameslinx said:

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.

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

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

I can't get parallax  to work. here is my ksp.log. The trees just don't appear, and engines no longer show any plumes.

Edited March 11, 2023 by Pluspython68

[Pluspython68]

1 hour ago, Pluspython68 said:

I can't get parallax  to work. here is my ksp.log. The trees just don't appear, and engines no longer show any plumes.

Please?

[Lord_Dracon]

Hello.

It's my first time using Parallax. After installing it, everything worked seemingly fine, except for these "plants shadows" on the launchpad.

 

Currently I am using the following MODs.

What can it be?

 

[Pluspython68]

22 minutes ago, Lord_Dracon said:

Hello.

It's my first time using Parallax. After installing it, everything worked seemingly fine, except for these "plants shadows" on the launchpad.

 

Currently I am using the following MODs.

What can it be?

 

Show them your KSP.log

you can show it to them by giving them a link to google drive of your ksp.log

[Lord_Dracon]

19 minutes ago, Pluspython68 said:

Show them your KSP.log

you can show it to them by giving them a link to google drive of your ksp.log

I just found out what it was. The KSP PostProcessing (KS3P) mod was causing that issue.

I just replaced it with the latest version of TUFX and it solved.

Edited March 11, 2023 by Lord_Dracon

[Gameslinx]

1 hour ago, Lord_Dracon said:

What can it be?

 

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

Edited March 11, 2023 by Gameslinx

[ShadowDr]

Quite enjoying those detailed update logs, professional job.
Makes me wonder, are current KSP2 devs aware of this tech? Terrain seems to be one of the main fek-ups there for now, and this both looks in some ways better and runs oh so much smoother than what they have.

Some user question meanwhile. I'm slightly dissatisfied with certain scatter properties in various locations, both for visual and gameplay reasons.
For instance, Kerbin grass is HUGE (or maybe kerbals are midgets, result's the same) while trees are just right. If you happen to land or roll into grassy terrain, it also obstructs vision quite a lot.
Rocks on the Mun by default are way too dense, would be almost universally impassable if colliders are enabled.
Don't have much control over this in current config, found only global scatter density (helps with the Mun, but also makes forests into scattered trees).

So got this idea: 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.


as a side note, seems like the Kerbin grass interaction with bright long range  lights from some (modded?) rocket engines is the thing that may cause performance drops at launches. If someone experiences that a lot, decreasing grass density helps. Or limiting the range of those lights.

Edited March 13, 2023 by ShadowDr

[ManuxKerb]

Hi

Awoesome mod!

I got some problem with the Shaders or something:

Picture: https://ibb.co/n8ZQQ6J

As you can see the screen is somehow split in two parts. When im near the vessel im seeing these black lines everywhere....

I did get rid of this after i removed the whole AVP and TUFX but i belive that Parallax does work with does mods. So it must be some setting.... Or the order in wich they are loaded...

What i tried was the to switch of antializing in settings but it did not change...

Can anyone give a hid what couses this ?

Mods instlled:

Parallax

AVP

Scatterer

EVE

Waterfall

Planetshine

Thanks a lot!!

Edited March 13, 2023 by ManuxKerb

[R-T-B]

On 3/10/2023 at 6:08 PM, Gameslinx said:

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  

  

On 3/10/2023 at 5:14 PM, Blufor878 said:

I'm having the same issue.


Kerbin is this odd minty green color now.

The terrain looks fantastic though.

 

This bug is caused by an odd interaction between Scatterer and Kopernicus both authors have yet to narrow down.

There is a fix, if you have plenty of vram.  That is to completely disable Kopernicus's ondemand-texture loading subsystem.  This WILL eat a lot of memory, mind:

Simply throw this in a .cfg file anywhere:

@Kopernicus:FINAL
{   
	useOnDemand = False
}

 

Edited March 13, 2023 by R-T-B

[AdmiralAxolol__]

Hello!.. fun fact this is my first time ever using a forum.  I am having problems with downloading parallax where I get the error message "shader banks not installed" . I've tried reinstalling all the mods that are required for it including all the texture files and the parallax file itself and nothing seems to work. I just end up loading forever and ever. I tried the fix you proposed and replaced  Kopernicus and made sure it was 139. idk what to do at this point. 

[R-T-B]

38 minutes ago, AdmiralAxolol__ said:

Hello!.. fun fact this is my first time ever using a forum.  I am having problems with downloading parallax where I get the error message "shader banks not installed" . I've tried reinstalling all the mods that are required for it including all the texture files and the parallax file itself and nothing seems to work. I just end up loading forever and ever. I tried the fix you proposed and replaced  Kopernicus and made sure it was 139. idk what to do at this point. 

Can you post both a screenshot of your gamedata folder and if you are able, your ksp.log file?  That would help us help you.

 

By the way, it needs to be GREATER THAN 139, not exactly 139 Kopernicus.  Just use the latest.

Edited March 13, 2023 by R-T-B

[AdmiralAxolol__]

I got the newest version of Kopernicus and it worked! 

Thank you for your help, I'm kinda bad at this 

 

 

 

Edited March 13, 2023 by AdmiralAxolol__
I got some info wrong

[Gameslinx]

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

[ShadowDr]

3 hours ago, Gameslinx said:

• 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

Yep found this on github later. So all the persistent rocks are in one group? They look like there's more to them, well done again.

From some experimentation, seem to be useful to decouple high density stuff from the rest. Though this really affects mostly Kerbin( or whatever else foresty worlds you may have)
Haven't dealt with last two types close up yet, but kelp and icebergs of Kerbin look fine from above, I guess they scale well with global values now.
Per planet or at least per-whatever-you-call-environment-types settings also would be welcomed. This is to tweak rocks density on rocky worlds without destroying Kerbin forests, for example.
By the way, when the rocks would have reliable colliders, they may be considered as additional difficulty option, with how they spawn. Denser rocks make safe landing much trickier. Then density setting specifically for rocky worlds will be a must.

Kerbals being just 0.75 meters is new to me, i've read they're one meter (and never bothered to check). Still, even two meter grass isn't unseen, so there's nothing "unrealistic" in it being as high as it is, but realism isn't the point.
It is a case of "gamey compromises", when you may have to make something unrealistic for better playability. When someone does a lot of EVA or small vehicle gameplay on land, in this instance, that grass and some other things just make it too hard to see what you're doing. And dense rocks may be a problem for rovers.
I've got my grass to be quite scarce as side effect of spreading out moon rocks, and i'm almost fine with this compromise between looks and playability, so that's one option.
Another would be just to mow it. Have actual grass sprites of same size and density, but lesser height.

[Czejenesku]

12 hours ago, ShadowDr said:

Yep found this on github later. So all the persistent rocks are in one group? They look like there's more to them, well done again.

From some experimentation, seem to be useful to decouple high density stuff from the rest. Though this really affects mostly Kerbin( or whatever else foresty worlds you may have)
Haven't dealt with last two types close up yet, but kelp and icebergs of Kerbin look fine from above, I guess they scale well with global values now.
Per planet or at least per-whatever-you-call-environment-types settings also would be welcomed. This is to tweak rocks density on rocky worlds without destroying Kerbin forests, for example.
By the way, when the rocks would have reliable colliders, they may be considered as additional difficulty option, with how they spawn. Denser rocks make safe landing much trickier. Then density setting specifically for rocky worlds will be a must.

Kerbals being just 0.75 meters is new to me, i've read they're one meter (and never bothered to check). Still, even two meter grass isn't unseen, so there's nothing "unrealistic" in it being as high as it is, but realism isn't the point.
It is a case of "gamey compromises", when you may have to make something unrealistic for better playability. When someone does a lot of EVA or small vehicle gameplay on land, in this instance, that grass and some other things just make it too hard to see what you're doing. And dense rocks may be a problem for rovers.
I've got my grass to be quite scarce as side effect of spreading out moon rocks, and i'm almost fine with this compromise between looks and playability, so that's one option.
Another would be just to mow it. Have actual grass sprites of same size and density, but lesser height.

What parallax settings do you use?