Galileo

[1.3.1] Rescale! Comprehensive SD Configs [1.0.2.8] [03 Dec 2017]

Recommended Posts

29 minutes ago, Tyko said:

What still confuses me is why the two versions aren't aligned with each other. There will be a ghost mountain above a lunar plain. Seems like if they were just high-res and low-res versions they should line up with each other.

It might just be the viewing angle.  When near a body, i.e. 25-30 km, the horizon is much closer then when we're at a high altitude.  It could be that the mountains you're seeing in the ScaledVersion are over the horizon of the PQS.  As the altitude increases, the PQS horizon moves farther away.  Perhaps at 100+ km the previously "over the horizon" terrain will come into view to where the PQS becomes a closer match to the ScaledVersion.

The above is just a guess.  I really don't know enough about how it works to say for sure.  It could be that there's more to the problem than I thought.
 

Edited by OhioBob

Share this post


Link to post
Share on other sites
31 minutes ago, OhioBob said:

It might just be the viewing angle.  When near a body, i.e. 25-30 km, the horizon is much closer then when we're at a high altitude.  It could be that the mountains you're seeing in the ScaledVersion are over the horizon of the PQS.  As the altitude increases, the PQS horizon moves farther away.  Perhaps at 100+ km the previously "over the horizon" terrain will come into view to where the PQS becomes a closer match to the ScaledVersion.

The above is just a guess.  I really don't know enough about how it works to say for sure.  It could be that there's more to the problem than I thought.
 

Could be. Most of my testing is at about 31000m and when I go to 10x time acceleration it becomes easier to "map" what my brain is seeing to possible perspective errors and I'm pretty sure they're not aligned.

Are there two different textures for ScaledVersion and PQS? If so, where are they referenced and how do they get mapped to the planetary surface? Maybe I could dig into it and see if one is getting twisted somehow.

Edited by Tyko

Share this post


Link to post
Share on other sites
16 minutes ago, Tyko said:

Are there two different textures for ScaledVersion and PQS? If so, where are they referenced and how do they get mapped to the planetary surface? Maybe I could dig into it and see if one is getting twisted somehow.

The scaled version is just a color map and a normal map.

		ScaledVersion
		{
			Material
			{
				texture = path/colorMap
				normals = path/normalMap
			}
		}

The PQS is a lot more complicated.  It can be just a height map and a color map, but often there are additional PQSmods that contribute to a planet's terrain.  There are all types of PQSmods that can add height noise, craters, color, etc.  Virtually an entire planetary surface can be generated using PQSmods.

Share this post


Link to post
Share on other sites

@Tyko, I wonder what would happen if you just did a terrain offset.  Try something like this:

@Kopernicus:AFTER[GPP]
{
	@Body[Iota]
	{
		@PQS
		{
			@Mods
			{	
				VertexHeightOffset
				{
					offset = 2000	// any positive or negative number, will move terrain upwards or downwards
				}
			}
		}
	}
}

If it changes both PQS and ScaledVersion, then you'll gain nothing.  But if it changes one and not the other, maybe you can get the radii of the rims to match.

(I'm starting to grasp at straws.)

(edit)  Adding the above means that you should also delete the cache before restarting the game.

(edit 2)  This might not work on oceans worlds because it could change sea level.   It would have to be tested.

 

Edited by OhioBob
  • Like 1

Share this post


Link to post
Share on other sites

Hmm. Inside the configs I find a lot of
NEEDS[SigDim,GPP]

Does that mean

  1. wrong, GPP has to be deleted from the configs
  2. right, this only works with GPP as dependency

??
:sticktongue:

Edited by Gordon Dry

Share this post


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

Hmm. Inside the configs I find a lot of
NEEDS[SigDim,GPP]

Does that mean

  1. wrong, GPP has to be deleted from the configs
  2. right, this only works with GPP as dependency

??
:sticktongue:

It means the patch will only run if both Sigma Dimensions and GPP are installed. Likely because it is not needed unless you are using GPP.

Share this post


Link to post
Share on other sites
4 hours ago, Gordon Dry said:

Hmm. Inside the configs I find a lot of
NEEDS[SigDim,GPP]

Does that mean

  1. wrong, GPP has to be deleted from the configs
  2. right, this only works with GPP as dependency

??
:sticktongue:

Settings for Sigma Dimensions can be global or planet specific.  So what you are seeing are planet specific settings that apply only to GPP.  For everything else, the global settings are used.  The global settings are the stuff at the beginning of the config inside the @SigmaDimensions{} node.  All the GPP stuff doesn't do anything unless GPP is installed.  And when GPP is installed, the planet specific settings take precedence over the global settings.

Share this post


Link to post
Share on other sites

So 6.4x version works almost fine with KSP 1.5.1 and Kopernicus-1.5.1-1 but for some reason FPS drops to unplayable level ON THE SURFACE of Mun. Does anyone have the same problem? Any solutions?

Edited by Nathanson

Share this post


Link to post
Share on other sites
On 10/23/2017 at 2:12 PM, Galileo said:

This is something that has been around for a long time now with scaled systems. Unfortunately, there isn’t anything I can do, and I always tell people to disable rescue missions with contract configurator. There isn’t a parameter I can change to raise the altitude. 

I realize this is an old post that I'm replying to, but there are two things that can be done here

For planets with atmospheres, the minimum orbit is linked to atmosphereDepth (radius + atmosphereDepth). if atmosphereDepth doesn't accurately reflect where the edge of the atmosphere is then you get  can contract orbits inside the atmosphere.  (assuming that the value for this is less than the altitude of the edge of space)

For planets without an atmosphere things get tricky. First the highest peak of the airless planet is found. Then the code runs through timewarpAltitudeLimits and finds an altitude in that list that is higher than the highest peak and returns that value + radius. Most of the time that's ok but it can result in orbits which are dangerously close to the highest terrain and the orbit could clip something even off rails. timewarpAltitudeLimits should be scaled by the rescale value to avoid this.

These are the things I have done to my installation to avoid impossible rescue missions. (sanitize atmosphereDepth and rescale timewarpAltitudeLimits)

  • Like 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now