Blocky Coastline Textures from LKO 4k Medium Settings w/ 4x AA

[JoeSchmuckatelli]

 

[Cytauri]

Yeah, this needs to be fixed. It was in KSP 1 also so I really hope its not going to forever be in KSP 2.

[MehJeb]

not just coastlines, make note of how clouds shader simplifies them based on distance, what we see here is most probably a multiplication - the topmost shader drew a blocky block for clouds layer (above) and the render pipeline considers that terrain shader has no use for rendering with higher resolution since the upper level shader already premul the block of pixels at that spot. That's exactly the same problem with render queue that I mentioned in these posts: 

and

 

...also  rendering Sun and other distant light emmiters _THROUGH_ solid objects, mentioned  in this post:

 

those are all render queue bugs, the have to do with initial default setup of render pipeline (and shaders for that matter) in Unity; the programmer who does graphics should clearly hand-manage render

queue, like:

	SubShader {
		Tags {	"RenderType"="Opaque" 
				"Queue" = "Background+100"
	//			"ForceNoShadowCasting" = "true"
		}
		LOD 500

for layered ground polys that have no z-fighting ;-)

or:

SubShader {
    Tags {
    "Queue"="Background+85" 
    "IgnoreProjector"="False" 
    "RenderType"="Transparent"
    }
    LOD 200

for transparent vertical bilboard-style polys that are vertex-lit (btw, if you keep this setting and for seome reason would ever need to get to "Fallback "Transparent/VertexLit", the resulting compiled shader will also not have z-fighting problems even thou it is vertex-lit and objects whose materials it is supposed to be used on are typicaly perpendicular to the plane where distant projectors (Sun) have their kinky light stuff going on

This is just an example of hand-managed render queue which solves all kinds of problems reported in this and cited posts. Good luck! 

 

[coyotesfrontier]

4 hours ago, MehJeb said:

not just coastlines, make note of how clouds shader simplifies them based on distance, what we see here is most probably a multiplication - the topmost shader drew a blocky block for clouds layer (above) and the render pipeline considers that terrain shader has no use for rendering with higher resolution since the upper level shader already premul the block of pixels at that spot. That's exactly the same problem with render queue that I mentioned in these posts: 

and

 

...also  rendering Sun and other distant light emmiters _THROUGH_ solid objects, mentioned  in this post:

 

those are all render queue bugs, the have to do with initial default setup of render pipeline (and shaders for that matter) in Unity; the programmer who does graphics should clearly hand-manage render

queue, like:

	SubShader {
		Tags {	"RenderType"="Opaque" 
				"Queue" = "Background+100"
	//			"ForceNoShadowCasting" = "true"
		}
		LOD 500

for layered ground polys that have no z-fighting ;-)

or:

SubShader {
    Tags {
    "Queue"="Background+85" 
    "IgnoreProjector"="False" 
    "RenderType"="Transparent"
    }
    LOD 200

for transparent vertical bilboard-style polys that are vertex-lit (btw, if you keep this setting and for seome reason would ever need to get to "Fallback "Transparent/VertexLit", the resulting compiled shader will also not have z-fighting problems even thou it is vertex-lit and objects whose materials it is supposed to be used on are typicaly perpendicular to the plane where distant projectors (Sun) have their kinky light stuff going on

This is just an example of hand-managed render queue which solves all kinds of problems reported in this and cited posts. Good luck! 

 

Sorry, but I'm fairly certain this actually has nothing to do with the render queue. It's actually a direct consequence of how the PQS terrain engine works. Terrain in KSP is composed of a planetwide sphere made out of individual squares called quads. The quads subdivide into more quads the closer the vessel is to the ground, with them being at their maximum subdivision amount when the vessel is landed on the surface. Likewise, the further a vessel is from the ground, the quads desubdivide (combine?) into larger squares. When a vessel is very far from the surface, like in orbit, the quads are at the lowest subdivision count, which means each individual quad is huge, on the order of a kilometer or so. Viewed from orbit, the coastline appears pixilated because it actually is pixelated, a fact that isn't noticeable when at a lower altitude because of the higher subdivision count.

[MehJeb]

Quote

 I'm fairly certain this actually has nothing to do with the render queue

then, you are wrong

Quote

Terrain in KSP is composed of a planetwide sphere made out of individual squares called quads.

those at most are logical units, what I'm talking about is what directly happens on BitBlt calls (drawcalls) on your hardware (GPU);

now think of this: your max usable texture resolution is 4096x4096 pixels - so you split your spherical map into how many quads to achieve say 1 pix == 1m resolution? From 10,000 ASL - 19m per pixel looks kinda ok - how many quads do you need at that resolution? ;-) Do you draw quads that ar partially in view? Do you retexture your "sphere" on the fly consecutively or in one pass before rendering next frame that occures after LOD change? ;-))

Go on, answer all these to yourself and your picture of how things work will change to more accurate.

 

Quote

Viewed from orbit, the coastline appears

And the clouds? ))) What happens to them?