Jump to content

[1.11.x] Parallax, A PBR Terrain Shader [1.2.1]


Recommended Posts

56 minutes ago, KSPrynk said:

 MKS Akita Wheel just pass through that terrain. 

I tested that wheel and it worked fine. 

UJOyTxq.jpg

We did have issues with some wheels that deploy.

Link to post
Share on other sites
24 minutes ago, eberkain said:

I tested that wheel and it worked fine. 

UJOyTxq.jpg

We did have issues with some wheels that deploy.

Huh, I'll go back and try again, but what's the secret sauce on conditions for collisions to work?   I tried out an Akita, using all of the MKS parts (in version 1.4.1) on the Mun (via Alt-F12 position change) and had no luck.  When it does work with other wheels, I usually see some parallax collision messages briefly pop up on the left side of the screen during scene loading.

Is there something related to the initial altitude where the ray tracing needs an opportunity to converge properly?  Is there a minimum terrain feature size vs wheel size that may not trigger a threshold to interact?  And is there a diagnostic mode, like in your pic above, that can be turned on to show when things are active or gone askew?  EDIT: In the pic above, there's really nothing to bump on - on the Mun, I've flipped rovers hitting small ridges and rocks, when using RoveMax S2s in place of the Akita wheel.

Edited by KSPrynk
Link to post
Share on other sites
6 minutes ago, KSPrynk said:

Huh, I'll go back and try again, but what's the secret sauce on conditions for collisions to work?   I tried out an Akita, using all of the MKS parts (in version 1.4.1) on the Mun (via Alt-F12 position change) and had no luck.  When it does work with other wheels, I usually see some parallax collision messages briefly pop up on the left side of the screen during scene loading.

Is there something related to the initial altitude where the ray tracing needs an opportunity to converge properly?  Is there a minimum terrain feature size vs wheel size that may not trigger a threshold to interact?  And is there a diagnostic mode, like in your pic above, that can be turned on to show when things are active or gone askew?  EDIT: In the pic above, there's really nothing to bump on - on the Mun, I've flipped rovers hitting small ridges and rocks, when using RoveMax S2s in place of the Akita wheel.

If you you warp to another body the collisions wont work until you reload, a quicksave/load or tracking station and back, etc..  Its a known issue, not sure if @Gameslinxwill be able to find a way around that issue. 

Link to post
Share on other sites
6 minutes ago, eberkain said:

If you you warp to another body the collisions wont work until you reload, a quicksave/load or tracking station and back, etc..  Its a known issue, not sure if @Gameslinxwill be able to find a way around that issue. 

I had the same thing so that's good to know. Thank you!

Link to post
Share on other sites
13 minutes ago, eberkain said:

Its a known issue

Cheating to another body will cause that because the terrain quads are not generated properly. Going to another planet legitimately shouldn't cause that

24 minutes ago, KSPrynk said:

And is there a diagnostic mode, like in your pic above, that can be turned on to show when things are active or gone askew

Left Alt + 3 will show the collider cubes. Some wheels don't work because:

  1. They might not use the correct WheelDeploy orientation (1 = deployed, 0 = retracted)
  2. They might not contain the correct part module (ModuleWheelBase) or a module named "WheelCollider"
  3. They're modded wheels and therefor use different part modules that I can't target

 

Link to post
Share on other sites
42 minutes ago, Gameslinx said:

Cheating to another body will cause that because the terrain quads are not generated properly. Going to another planet legitimately shouldn't cause that

Gotcha.  What's the threshold for going "legitimately"?  Changing SOIs or crossing certain altitude bands, with different levels of texturing/tesselation kicking in? 

Link to post
Share on other sites
2 hours ago, vardicd said:

@Gameslinx Just tried again today with the new version, plus the dll from the dropbox link, and I'm still getting messed up graphics. here's a link to the output log this time, because I'm not half asleep trying to make a report. I don't know how to understand what's in the log, so I have no idea what might be causing this, the previous version of the mod works with every mod I'm running right now, but this version... well, the pictures kind of speak for themselves.

https://www.dropbox.com/s/7d7e22zx2aot363/log for parallax.log?dl=0

Ixshokq.jpg

Got the exact same problem

Link to post
Share on other sites
41 minutes ago, Folkhoer said:

Got the exact same problem

You have a ton of mods installed. Can you try with just Parallax, please?

 

Link to post
Share on other sites

I will be doing some clarification in the FAQ section and wiki tomorrow. Today's been very chaotic and I haven't had much time - thank you all for the bug reports :)

 

Link to post
Share on other sites

This mod is amazing. Makes space planes/planes more challenging.

I don't think the terrain "bumpiness" was working until I disabled terrain scattering?  Think its a Kopernicus thing.

Also does Minmus not have a texture or am I missing something? It still looks the same way it did 8 years ago. Haven't been there yet just looked though the tracking center. 

Link to post
Share on other sites
1 hour ago, SpaceFoon said:

Also does Minmus not have a texture or am I missing something? It still looks the same way it did 8 years ago. Haven't been there yet just looked though the tracking center. 

Parallax don't change the scaled space texture (what you see in the tracking station). You need to get closer to see the change.

Link to post
Share on other sites
6 hours ago, vardicd said:

Retested on clean install, fresh save, only parallax, and listed dependencies, still bugged out, picture and log below:

EgOcZ4r.jpg

https://www.dropbox.com/s/d2aej7mnz98hzjn/log for parallax again.log?dl=0

I had the same issue on KSP 1.10.1, right down to the date being Year 999 Day 499.  Everything works ok on 1.11 though once I upgraded Kopernicus BE to the correct build.

I have a stack of mods installed too and even just copying my mods folder across from 1.10.1 to the 1.11 install everything worked. Only update needed was Kopernicus.

Link to post
Share on other sites
7 hours ago, vardicd said:

Retested on clean install, fresh save, only parallax, and listed dependencies, still bugged out, picture and log below:

 

https://www.dropbox.com/s/d2aej7mnz98hzjn/log for parallax again.log?dl=0

 

34 minutes ago, bracknellexile said:

I had the same issue on KSP 1.10.1, right down to the date being Year 999 Day 499.  Everything works ok on 1.11 though once I upgraded Kopernicus BE to the correct build.

Can confirm that 1.10 no longer works. I'm going to update the title accordingly

Link to post
Share on other sites

 

12 minutes ago, Kovac said:

is there a way to install this for 1.10?

You can use versions prior to Parallax 1.2 for stock on 1.10.x. For 1.2 see below.

4 hours ago, Gameslinx said:

1.10 no longer works

Link to post
Share on other sites
3 minutes ago, cameronisher3 said:

theres no new accompanying stocktextures file, so do i just use the old one or is that not a thing anymore? 

all the cool kids ask dumb questions B)

Stock textures come included with Parallax 1.2.

Sorry if I misunderstood. Is there a file that is now gone?

Link to post
Share on other sites
6 hours ago, Gameslinx said:

 

Can confirm that 1.10 no longer works. I'm going to update the title accordingly

Oh, well, that explains it, shame. I'll have to wait a while before I get to use the new version, got a few of my must have mods that still aren't available in the 1.11 format. I won't be upgrading my KSP to 1.11 till those mods finally update.

Link to post
Share on other sites
6 hours ago, Gameslinx said:

 

Can confirm that 1.10 no longer works. I'm going to update the title accordingly

That's a shame indeed, given the issues with 1.11 at the moment. Any idea why that is though? 

Link to post
Share on other sites
1 minute ago, Morphisor said:

That's a shame indeed, given the issues with 1.11 at the moment. Any idea why that is though? 

I'm looking into it at the moment. Currently, I'm unsure. Nothing should cause the game to lock up as badly as that unless there's a new part module that was introduced in 1.11 and doesn't exist in 1.10

For the proper release (keep in mind that this is a Beta), I'll hopefully have this worked out :) 

Link to post
Share on other sites
13 minutes ago, Gameslinx said:

I'm looking into it at the moment. Currently, I'm unsure. Nothing should cause the game to lock up as badly as that unless there's a new part module that was introduced in 1.11 and doesn't exist in 1.10

For the proper release (keep in mind that this is a Beta), I'll hopefully have this worked out :) 

Isn't that almost exactly what happened though, given the new/changed inventory system?

Link to post
Share on other sites
22 hours ago, Gameslinx said:

Cheating to another body will cause that because the terrain quads are not generated properly. Going to another planet legitimately shouldn't cause that

Left Alt + 3 will show the collider cubes. Some wheels don't work because:

  1. They might not use the correct WheelDeploy orientation (1 = deployed, 0 = retracted)
  2. They might not contain the correct part module (ModuleWheelBase) or a module named "WheelCollider"
  3. They're modded wheels and therefor use different part modules that I can't target

 

Alright, I've got a better handle on this now.  The quicksave/quickload and Tracking Station back-and-forth seems to address my desire to cheat out to terrain to test it out.  And the Akita does work, though it looks like the relatively tiny amount of suspension travel (or small size of wheel) makes it hit every rock or ridge on the Mun hard and jump into the sky, while it just bumps a little on Kerbin's grasslands (I guess I should pop over to MKS since RD was doing some revamps). 

I checked the StockExpansion RoveMax M1-F folding wheel and that one does NOT work, per Rule #1 above.   A quick check in USI shows Karibou wheel .cfg is the same for the deployedPosition parameter.

I noticed that the collision markers (LeftAlt-3) are active when the wheels are folded, and nothing bad seems to happen - the [Parallax Collisions] damping engages and pushes the rover up to the surface.  The rover on a hill will slowly slide downward and jump a bit when the retracted, but collision active, wheel hits tesselated terrain, but that makes sense anyways.  I'm interested to see how this can be resolved. 

UPDATE 1: I'm a bit concerned about wheels with relatively low suspension travel versus rough terrain.   I'm trying out my baseline 6x6 rover with TR-2L wheels on the Mun, and driving at any speed is pretty dangerous.  It's similar to what I experienced with the tiny Akita wheel, which has the same suspension travel of 0.1 - the rover is occasionally tossed into the sky after a low speed (<1m/s) bump with relatively small objects, sometimes with a significant rotation.   Not sure how this can be addressed.  Is the collision plane (cube) a fixed size, or does the wheel size determine it?  Is this adjustable in a .cfg? 

UPDATE 2: I'll be trying out the low suspension travel wheels on other planets.  This may be a fact of life to deal with on planets with significant ground clutter, but getting tossed into the sky even while crawling at a snail's pace seems...demoralizing.  I just got flipped over driving on Duna at 2 m/s....

Edited by KSPrynk
Link to post
Share on other sites
5 hours ago, KSPrynk said:

UPDATE 2: I'll be trying out the low suspension travel wheels on other planets.  This may be a fact of life to deal with on planets with significant ground clutter, but getting tossed into the sky even while crawling at a snail's pace seems...demoralizing.  I just got flipped over driving on Duna at 2 m/s....

I'm going to try implementing a method which might help with this.

Currently, no matter what the displacement is, your wheel will be pushed up to meet it. Instead, I might be able to compare the current displacement with the previous displacement and, if the difference is too high, I can create a second cube which will stop the craft (like hitting a wall) instead of pushing it upwards. 

Since displacement is calculated on a per-pixel basis, I am not able to easily compute the next pixel the wheel will travel across. I only have access to the previous displacement value. I will be experimenting with this more in the future, but it's a lot to wrap my head around!

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...