Moose

This just betrays that you really don't understand the relationship developers have with publishers.

The only one I've found it interferes with is the one on Val, which is several meters below ground. Hoping @Gameslinx fixes that one eventually.

I found this is due to normals not being correct leaving holes in the meshes, and is related to the pile of shader tricks Scatterer is pulling alongside this. I ended up reinstalling both and that fixed the issue.

Throw this one onto the pile. I used the clouds for the Odyssey mission since they were released and the finale had a really nice glimpse of Eve at sunset.

This is the bit I needed, thank you.

Hey @linuxgurugamer thank you very much for this mod, it's helped me put together module lists for the Restock+ parts that are missing them. However a couple of questions/clarifications if I may: Firstly, there is still no description in the readme or this thread as to what "Process manipulable-only parts" actually does - and I can't see any changes in the generated config file when enabling it. I'm assuming it filters out all parts that are too big to be moved even with X kerbals, but I'm likely quite wrong there. Secondly, is there any way of tuning the generated list to be closer to stock values? Some of these parts are generating vloumes in the tens of thousands when equivlent sized stock parts are fudged to be ~1k. If you ever get back to this, can we have an option to set an upper bound that, if within the "largest allowable part" range, resizes the part to that bound? E.g. if I have a part that calculates at 24000 litres, and an upper bound of 2000, it should be set to 2000 rather than 24k. Thanks.

I dunno, Eve also suits a very thick cloud layer.

It's amazing how quickly a bit of tool development can make things go (referring to in-game cloudmap editing). You're doing great! But please, don't rush.

Cheers - personally I only do the base layer (which are the trunks). The "tops" are the leaves which are worth leaving uncollidable imho. I also do "sapling" for the smaller trees that spot the planet.

You can manually add these yourself, it's a flag in the stock configs. E.g: # Kerbal Space Program\GameData\Parallax_StockTextures\_Scatters\Configs\Kerbin.cfg Scatter { name = OakTree model = Parallax_StockTextures/_Scatters/Models/Kerbin/oaktrunk0 collideable = True # This is the new line updateFPS = 0.330000013 cullingRange = 200 cullingLimit = -400 alignToTerrainNormal = False maxObjects = 40000 SubdivisionSettings

So my Minmus still won't show the scatters, but does appear to load them in the log. @GameslinxYou've mentioned a couple times to delete settings.cfg. Are you takling about the one in the root KSP folder? As I did so and no change. Should I just reinstall the plugin again and see what happens? The only errors I see are lots of : [ERR 00:58:47.197] Material doesn't have a texture property '_DispTex' But this is true for scatters that do display normally. Suggestions welcome! Edit: Literally reinstalled KSP and all mods to bring it to stock and still nothing on Minmus?! Second edit: I think? I found the issue, see below: Turns out your system doesn't like when minimumSubdivision at the body level matches that of a scatter. So by default, the stock config for Minmus sets that value to 7 for all cases. But if I set that value to 6 instead of 7 at the body level, e.g.: ParallaxScatters { body = Minmus minimumSubdivision = 6 Scatter Suddenly everything works!

I don't know how many of us still use this, but I certainly do. Thank you for keeping it going @linuxgurugamer

Unfortunately TXAA has an issue where we get depth infighting in some cases - though mainly in mods. I've most noticed it with Waterfall and the flag decales on Restock/+. But this is an issue better raised for Scatterer I feel.

I've also noticed this issue, sometimes it just refuses to draw ambient light in the shadow of an atmosphere. However I've yet to narrow it down too far. My best result in fixing this was disabling Scatterer's TXAA and replacing it with the SMAA option. I think it has a conflict with Parallax but I am unsure as to what.

I promise you that doubling the range barely touches it I agree with you with how Windows handles anything outside of fullscreen. Unfortunate penalty we have to live with.

So turns out it's Windows being an amazing person @Gameslinx Specifically, even with terrain set to high, framerate was being oddly specifically crap. Then it dawned on me, I hadn't run the game in true Fullscreen. I rely on Windowed mode (and borderless) for various reasons (streaming primarily). So in fullscreen? Runs fine. Better than fine. 90fps at 5120x1440 with double the draw distance fine. Windows has this nasty habit of not handling loads properly when running games in windowed mode. This has been an ongoing problem since Windows 8 and still haunts the OS all the way to the latest release of 11. My solution? Give KSP high CPU core priority. Screw you windows. Can now run at my target resolution at Woomerang (it's a real stress test!) at a comfortable framerate while (test) streaming too. It's not ideal but with Windows being a pain with CPU handling (and Parallax is genuinely pretty well optimised, I never doubted that) there isn't much more I can do here.

B-e-a-utiful! Shall be, thank you.

@Gameslinx when I finish my work I'll test more, with shaders first then onwards. I do indeed have it set to Ultra right now. I'm aware of Kopernicus and Stock hitching but this is very new in comparison. As for general performance, I notice it mostly when on Kerbin. If I disable grass scatters the improvement is substantial, and I do see noticeable improvement if I increase (thus reduce) culling interval to 2.0. I've been using the in game performance graph plus external toolsa nd at one point the TimeControl mod because it thankfully has an FPS counter. I have a 5950X at stock speeds with PBO disabled - though I am only using 8 of its cores when not doing production workloads by disabling a CCD. Typically under KSP's load I'm around 4.5 to 4.7ghz. Temperatures are nominal there. GPU is more than enough, as well - full specs. I will attempt the shader settings etc as dictated in OP (including terrain to high) when I'm done working and will get back to you. Sorry, I'm genuinely not trying to be a pain. Just want to help where I can.

I'll give it a go, it was added after the last time I took a good look at the OP. However I have 70+ fps. What I mention isn't frame rate (as mentioned in op) but frame pacing - overall frame rate is high but there are a lot of frames that hitch. Some people don't notice it very much. Unfortunately, I notice it and it is distracting. If the settings shown don't give me an improvement I'll make an issue on GitHub and dive into the source.

Linx, are you aware of poor frame pacing issues with the mod enabled? Is this something I should report in full on github?

Final edit ahead of all the others: I ended up reinstalling Parallax, Eve and Scatterer and that fixed it. It seemed to be some odd combination of the three and some setting somewhere. But it's fixed for me. Leaving this here for the future but shouldn't be anything that needs fixing in the mod itself. Performance isn't a concern, thank you for the quick response! I'll do that and have some fun. Post-experiment Edit: Right @Gameslinx I have tried this and I've seen no change. But after various attempts at increasing the quality settings deep in config (using your wiki) I have come to the conclusion that it's not the tesselation itself that is the problem, it's that tesselating the Moutain biome is just broken. It leaves lots of black squares where the texture isn't applied (this is with the default Parallax_StockTextures package from CKAN) which make the crawling geometry much more apparent than if it was matching the colour of the terrain. Unfortunately, I have no idea how to fix this, so flagging it as a bug. I've supplied a picture with the coordinates on Kerbin so you can see for yourself (this is with stock settings). It is important to mention that this is unrelated to shadows - regardless of time of day, the missing texture mapping stays in the same place. There are no errors in the logs at all. I think there is a mismatch between a couple textures somewhere, or normals are flipped on some of the vertices, but I am unsure how to see this as it doesn't output anything to the logs. Further edit: This is happening across all surfaces and is definitely holes in the mesh, I can see clean through the Mun with this bug in place. https://i.imgur.com/IBPrs5g.png

@Gameslinx I've been having a great time pushing the thing up to its limit, and other than some CPU hitching when running grass (even with default settings) it's holding up damn well. Great job! I was wondering, though, if there is something I can do to mitigate this geometry crawl at the edge of the tesselation range. It's incredibly distracting. I know it's the geometry being calculated up on the fly but any suggestions welcome.

I work in VFX, I wouldn't dare if it was just for games If you need it pushed hard hit me up.

Mine literally arrived today, I can legitimately try this if the option is tweakable in config.

When it's released I believe it'll be in the same pipeline as the current Eve Redux, so it should just be an update - I use CKAN, I highly recommend it. Though @blackrack may decide to have a second download (I'd assume) for earlier releases if it's a fundamental rewrite?