blackrack

Thank you so much Proot, much appreciated!

I see, in the future I will make it so it scans the directory for multiple files or create a similar system. It may be a while before I do any work on the mod though. If I don't have this implemented in a month just remind me of it.

Thanks, happy new year to you too (GPU seems dead for good btw)

Alright, I'll see what I can do. It might be a while though, my GPU died and I'm right in the middle of oven baking it

Do a quick test for me, if you pan the camera back quite a bit do they get back to showing up?

I get it, but it doesn't seem to me like anyone would notice the difference when it comes to collisions, explosions and different interactions between the joints and the parts. For floating point calculations it shouldn't be a problem as everything is done in a limited-size physics bubble centered around the player ship where floating point issues wouldn't really be a problem. Did the devs actually say they do it like this? Do they expand on how they do physics without PhysX?

So KSP doesn't use physx? I thought it was pretty clear that KSP used whatever physics engine/SDK is used in unity by default.

I don't really get how a single ship will be single-threaded, in that besiege comparison all these contraptions are also "a single ship" as in they're all connected by joints and other things. In this physx 3.3 benchmark (which is what is used in unity 5), if you scroll down to "Scene #5 – spherical joints net", there are multiple rigid-bodies connected by joints, you can clearly see it scales (if moderately) with multiple threads and is quite a bit faster than the old physx version running in a single thread. I don't really know if there is something more here, but Is there a reason why KSP should be an exception?

I tried the newest version of besiege and I can confirm I got similar speed-ups. I hope 1.1 is as fast with the physics, but I'm a bit worried at this point as the developers didn't say a single word about performance improvements, we're pretty much in the dark.

Won't be updating anything unless 1.1 hits and it speeds up the physics this much https://www.youtube.com/watch?v=hYuPNmSnrB4 Sorry I just had to post that

I think you can, and if I'm not mistaken you don't even need to touch any config values or anything, you just stick the high res cloud textures in there.

I found this little tutorial http://img04.deviantart.net/a266/i/2012/163/b/f/earth_like_planet__texture_tutorial_by_bonvanello-d53a0v4.png , someone linked to it in the dark days mod thread http://forum.kerbalspaceprogram.com/index.php?/topic/120543-upcoming-dark-days-dying-of-the-light-kopernicus-mod-help-wanted-for-part-pack/&page=6#comment-2236015 I used the same panorama method to blend several satellite pictures and then overlaid them on top of an 8k texture. For normalmaps I used a tool but it was a lot harder to overlay correctly and make it match the texture, if you read back those old comments I posted when I was trying this, you'll find the name of the tool somewhere. I will try to see If I can find the sample textures I used and post them here. Edited: here are the sample textures I used: http://imgur.com/a/awsli Let me know if you come up with something.

I don't really see much point in this, so no.

It's not enabled in the tracking station because it would either take too much memory to enable on all the bodies at once or it will take a few annoying seconds to load a different planet everytime you switch focus.

I never did actually, I dropped this idea as it was too much work and I wasn't that good at it. If you want good planet textures I suggest trying Proot's KSPRC mod (freshly updated), I use it myself.

There's nothing to correct, I added a fake ocean in the postprocessing shader, the real ocean disappears and the simulated ocean appears instead in the postprocessing shader. This eliminates the bug where looking at the ocean from orbit causes artifact soup but has some z-fighting for now, this is all in the changelogs. Before this the previous workaround was to make the ocean disappear at an altitude of 70km, leaving the ocean floor exposed, so pick your poison. The altitude at which the ocean and fake ocean are switched is in the planetsList.cfg file, it's called either fakeOceanAltitude or OceanDeactivateAltitude, I can't remember.

It's stated everywhere that there's a bit of z-fighting, please don't keep reporting issues that are already reported.

If you're talking about the aliaing/crawling, it's "normal" and won't be gone for a while. What issues are you getting with 0.02182?

What seems to be the issue here? Anything in the debug log?

From what I remember this only happens in dx9, you can try forcing dx11 for now as a workaround, I will look into it.

It seems there is a slight blurriness but I don't really see how scatterer can be causing that. Can you try scatterer without other mods? Try going into the EmptyShader.shader file, find the two lines that say Tags, and add "IgnoreProjector"="True" after "QUEUE"="Transparent", it should look like this: Tags { "QUEUE"="Transparent" "IgnoreProjector"="True"} Pass { Tags { "QUEUE"="Transparent" "IgnoreProjector"="True"} This should remove the clouds on the ocean but they will still work on everything else I actually thought I fixed this a few versions ago. Does KSPRC include scatterer files or did you download it separately.

Post more screens of the blurriness, might help me determine it's cause.

I see, I may have messed up something up with the sphere intersection code I'm using to changed edge/rim settings, will fix this for next version. For now you can try setting exposure and rim exposure to the same values, also extinction rim fade to 0 or 100, whichever does it I forgot. Probably some weirdness with the render orders. Doesn't look like a bad problem unless you go looking for it. What do you mean by everything in the distance is blurred? Can you post screens.

I do too. Don't say that you're making me feel old.

I would say test without other mods first. Weird, not sure what's going on.