CaptRobau

I will I will let you know. I'll also do the ASL change. As others have said, that's no longer true. It's crazy that you picked up about this a year after it was a feature for a very short while.

This is it in action on Gilly, with a high frequency (100) and red and blue as the two colors. In normal use you wouldn't make the frequency high though. Gilly only has a frequency of 1, Duna has the max with 24.

Judging by its source file, it seems to be a more advanced way to add some color variation to your planet in a procedural way. There's VertexColorNoise which just applies grey scale noise, VertexColorNoiseRGB which does the same but with a single color (so a red scale, blue scale or brown scale noise). This Simplex PQSMod seems to allow you actually do a gradient, so you end up with perlin noise with two colors and every color in between. Here's the PQSMod as used in Bops CFG: VertexSimplexNoiseColor { blend = 1 colorStart = 0.1716418,0.1504306,0.1306527,1 colorEnd = 0.2910448,0.24074,0.2128536,1 frequency = 1 octaves = 6 persistence = 0.5 seed = 64564 order = 100 enabled = True name = _Color index = 0 }

Ctrl+P

So you have your own planet or moon and you want to make it look as good from close by as it does from up in orbit? Good terrain textures are the best way to make this happen. In this tutorial I will explain how to properly apply both stock and custom terrain textures to your planets using Kopernicus. This lesson is based on what I learned myself while learning to do this for my own mod OPM. The tutorial consists of 2 parts: Applying textures to the terrain Making the textures appear where you want Texture application Note: for this step you can use built-in textures from the game or use your own custom textures. I will explain how you can do both. Open up your body’s cfg in something like Notepad++ (Windows’ Notepad won’t do). To edit the terrain textures we have to use the Material node. If you've never touched terrain textures, you probably won't have this in your config yet. Here is where it goes (excuse bad formatting, blame the forum software): @Kopernicus:AFTER[Kopernicus] { Body { PQS { Material { } } } } So material is where we're going to do our magic. There's one thing that we have to do outside of the material node though and that's to set the material type. Not all stock planets use the same one and, since some types work less well than others, we're going to define the type so that we're always working with the best one. @Kopernicus:AFTER[Kopernicus] { Body { PQS { materialType = AtmosphericExtra Material { } } } } From now on everything we'll be doing in side of the Material node. For those who've dabbled with texturing before KSP 1.1, note that AtmosphericExtra is the successor to AtmosphericOptimized. If you used that before, use AtmosphericExtra now. Before we start writing the material, you need to know that there are four texture slots we can use: Low: covers the lowest part of the terrain Mid: covers the area between low and high High: covers the highest part of the terrain Steep: covers all the steep areas like cliff faces, crater walls, the sides of mountains, etc. It will overlap with the three previous areas as steep parts can be anywhere So now we know that, we can start adding the textures to these areas: Material { steepTex = CTTP/Textures/snow steepTexScale = 1,1 steepTexOffset = 0,0 steepBumpMap = CTTP/Textures/snow_normal steepBumpMapScale = 1,1 steepBumpMapOffset = 0,0 lowTex = CTTP/Textures/snow lowTexScale = 1,1 lowTexOffset = 0,0 lowBumpMap = CTTP/Textures/snow_normal lowBumpMapScale = 1,1 lowBumpMapOffset = 0,0 midTex = CTTP/Textures/snow midTexScale = 1,1 midTexOffset = 0,0 midBumpMap = CTTP/Textures/snow_normal midBumpMapScale = 1,1 midBumpMapOffset = 0,0 highTex = CTTP/Textures/sand highTexScale = 1,1 highTexOffset = 0,0 highBumpMap = CTTP/Textures/sand_normal highBumpMapScale = 1,1 highBumpMapOffset = 0,0 } You see a lot of repeating stuff, so I'll only need to explain four of the values to help you understand what everything does:. ...Tex: sets the main texture for this area ...BumpMap: sets the bump map (or normal map) texture for this area. This doesn't have to look anything like your main texture, but if you want a unified look it's best you do. ...Scale: sets the scale of the texture on the X and Y axis. The default 1,1 is what looks the best, so use that. ...Offset: offsets the bumpmap from the main texture on the X and Y axis. The default 0,0 is what looks the best, so use that. You'll see I've pointed the textures to a folder called CTTP. This is the Community Terrain Texture Pack (still need to make a thread for this how others can use this). This is how you point to a custom terrain texture. Just replace the folder path to the one that matches your texture (YourModFolder/Textures/YourTexture for example). You can also use the builtin terrain textures found in KSP. These are lower quality and not all textures have a matching bump map, but you won't have to put custom textures in your mod. Here's a list of builtin terrain textures. To apply them you have to use a different folder path: midBumpMap = BUILTIN/RockyGround Next we're going to define how often these textures are applied to your planet. To prevent this code from becoming to long, imagine that the previous entries are also in Material. Material { steepNearTiling = 5000 steepTiling = 50 lowNearTiling = 5000 lowMultiFactor = 50 lowBumpNearTiling = 5000 lowBumpFarTiling = 50 midNearTiling = 5000 midMultiFactor = 50 midBumpNearTiling = 5000 midBumpFarTiling = 50 highNearTiling = 5000 highMultiFactor = 50 highBumpNearTiling = 5000 highBumpFarTiling = 50 } The higher the values you give to this tiling, the more detailed the terrain will become. Too much however will create noticeable tiling, making it look fake. So there's a fine balance. 5000/50 as shown above works well for textures with 1024x1024 resolution and what's on the texture looks close by, rather than far away. Is it 1024x1024 and the texture is far away (the case for CTTPs cliff and beach textures for example) than I've found 2500/25 to be a good fit. An explanation of the rest in the code above: NearTiling determines how often the texture tiles close to the player Tiling, MultiFactor and FarTiling (Squad didn't make it consistent) determine how often the texture tiles far away from the player. This works best if lower than NearTiling Steep only has NearTiling and Tiling for some reason, and these settings are used for the main texture and the bump map STILL WRITING, WANTED TO MAKE SURE IT SAVED

You can easily remove it from the terrain, but not from the texture you see from far off/map view as it's baked in there. To remove from the terrain, open up the cfg and remove the section that sort of looks like this: VoronoiCraters { colorOpacity = 0.7 DebugColorMapping = False deformation = 200 jitter = 0.1 jitterHeight = 2 rFactor = 1 rOffset = 1.1 simplexFrequency = 300 simplexOctaves = 3 simplexPersistence = 0.5 simplexSeed = 123123 voronoiDisplacement = 0 voronoiFrequency = 50 voronoiSeed = 462 order = 100 enabled = True name = _HeightNoise index = 1 CraterCurve { key = -0.9963056 -0.7950293 -0.1902251 -0.1902251 key = -0.9520697 -0.8223228 -0.6806358 -0.6806358 key = -0.7445966 -0.8581167 0.4436148 0.4436148 key = -0.4499771 -0.1392395 5.289535 5.289535 key = -0.4015177 0.2551735 9.069458 -2.149609 key = -0.2297457 0.08363447 -0.4453675 -0.4453675 key = 0.2817185 0.01192154 0.01421198 0.01421198 key = 1.000876 0.001117015 0.01397126 0.01397126 } JitterCurve { key = -1.000701 0.4278412 0.1577609 0.1577609 key = -0.7884969 0.09487452 -0.7739663 -0.7739663 key = -0.6091803 0.072019 0.123537 0.123537 key = -0.3930514 0.3903495 3.300831 3.300831 key = -0.3141366 0.9276265 0 0 key = -0.2586833 0.002564805 -0.01814346 -0.01814346 key = 0.9970253 0.003401639 0 0 } }

Kev and the new Pol look especially good.

Thanks. I wasn't that far off for most.

@OhioBob, I see you've made some changes like axial stuff and adiabatic index. What changes would you recommend for OPMs atmospheres to keep up with the new features? Don't know how applicable it is. My settings might be more/less wrong than stock KSPs, so I don't know.

I'm not completely happy with the results yet, so I will try to get it closer to what I really want in the future. Couple of things to note though: Karen is a really bad comparison, since it's terrain has been massively changed. The old Karen had very noisey terrain and the large terrain changes (like big impact basins) were not very pronounced. This normal looks so different, because it is different. Procedural craters also add a lot of detail to a normal map. Only the Mun has that in stock KSP and you're used to it there. The normal map lighting is not applied in the right direction, so it can look a bit off compared to stock KSP. Trying to fix that. I don't think the base idea behind these normal maps is not stockalike, just that stockalike has long meant fuzzy and not a lot of detail. If I can tweak it a bit further I think it'll start feeling like the high-quality version stockalike that I want.

Correct link now used. Padishar is right about the installation.

I'm thinking of finding and teaming up with a 3D modeller to create new forms of ground scatter to provide more varied environments for IPM. Before I do that, I was wondering if you, the community, had any suggestions for scatter that'd work well for the stock planets and moons. If you don't know what scatter is, it's those boulders, trees, etc. that you can find on Kerbin, Mun, etc. There are some limitations to what'd make good scatter: it can't be be too unique-looking, as even the lowest density scatter will have at least some it can't be too big, like an entire mountain

Hi, everyone. Mini-update: Currently slowly working on the lite version of IPM. This is relatively simple process, as it doesn't involve major redesigning like OPM 2.0 or the overhaul version of IPM. I'll release this version of IPM first, so every can play something that looks at least passable compared to OPM and other planet packs. The overhaul will of course take more time, but it'll also be more awesome

If it works, it's better if the changes are rolled into @Sigma88s mod since then they can maintain it. We can all work together on getting it done, but it's better if it's maintained by the mod that actually has the changes.

I'll take that in mind. Should be easy, since I don't intend on changing orbits. See comment above.

Maybe repost this is in the Kopernicus thread. Might be more related to its ring system feature than how I implemented it in OPM.

Looks both nostalgic and good.

Not at this point in development. There's more than enough to improve with adding new bodies. Forgot about that. Added it up there as well as here; Tylo Probably going to make the surface more like the real Ganymede: icy and irregular. I'll keep the high gravity though. It's not as unrealistic for its size, useful for getting gravity assists/capture and unlike Eve an airless rock doesn't have as many options to make it feel unique. Not necessary to actually go higher res. There's some tricks that I can use to make both the terrain and the ScaledSpace versions of Kerbin look much better without having to add resolution/degrade performance.

Ah ok. I thought maybe it was already half written as a custom Kopernicus PQSMod so might be easy to convert. Good luck with updating and expanding the mod.

Finally One of the greatest mods in KSP, based on what it allows you to do!

@Astrofox Slate uses the heightmap to get the general look of the ridges working and the PQSMod to get the ridges to look good from close up too. If you have a height map or procedural generated terrrain already you can utilize the PQSMod. Here's an example from my version of Eeloo. I keep them pretty much the same from body to body. I only change the deformity (how tall the ridge are, bigger bodies need higher values to get the same ridges as a small one) and the seed. I suggest using KittopiaTech to visualize which deformity/seeds work for your planet. VertexHeightNoiseVertHeightCurve2 { deformity = 140 ridgedAddFrequency = 32 ridgedAddLacunarity = 2 ridgedAddOctaves = 8 ridgedAddSeed = 12361237 ridgedMode = Low ridgedSubFrequency = 32 ridgedSubLacunarity = 2 ridgedSubOctaves = 8 ridgedSubSeed = 564523 simplexFrequency = 24 simplexHeightEnd = 1 simplexHeightStart = 0.2 simplexOctaves = 8 simplexPersistence = 0.5 simplexSeed = 78967456 order = 40 enabled = True simplexCurve { key = 0 0 0 0 key = 0.6311918 0.4490898 1.432598 1.432598 key = 1 1 0 0 } } The following is for everybody:

Inner Planets Mod Inner Planets Mod, or IPM, is going to be a companion mod of my well-known Outer Planets Mod. Now that this mod has matured a lot, I thought it would be interesting to look at the stock celestial bodies. Because like KSP's parts, there is a great deal of difference in terms of quality. Kerbin or the Mun still look pretty good, but some planets and moons haven't been touched in years. This mod tries to rectify that and give it a more balanced level of quality, that will integrate well with OPM. I intend for their to be two versions or two settings for IPM (I'd prefer the latter, but it'd have to be doable config-wise): A lite version: Fixes bugs or blemishes (like missing easter eggs or ground scatter in weird places) Overal improvements like better timewarp altitudes, better transitions between the terrain and ScaledSpace, etc. Better looking terrain and ground scatter textures A more thorough overhaul: Everything from the lite version More radical changes to the look and terrain of bodies, while not straying completely from their core concept. Sort of enhancing what's been established by the developer/community created lore Below are some WIP stuff, a mix of lite and revamp features: So what did I have in mind for the various bodies in the overhaul version? Moho Still in flux. Mercury isn't the most interesting place IRL, but the old Moho (overheating atmosphere) is a bit too cartoony. Maybe I can come up with some sort of compromise that's both realistic and interesting. Definitely getting procedural craters. Eve Stock Eve has some interesting bits to it, but after the initial challenge of going down and getting back into orbit it's not that fascinating. It's also become a bit too oceanic for my taste, especially for something that's supposed to be like hellish Venus. So the plan is to make it a real foreboding place, with lakes instead of oceans and countless ugly tiny islands (which is more inline with old Eve). I also intend to reduce the gravity from 1.7 to a more realistic (for a body that size) 1.2 g. This will make ground/low altitude exploration a bit more doable, seeing as the terrain detail will be increased by quite a lot. To offset this reduction in delta-V difficulty (it's still not easy), I want to make Eve's ocean dangerous. Kopernicus' HazardousOceans will slowly overheat any craft that lands in it, meaning that you will have to be a bit more careful when choosing a landing spot. This overheating would simulate strange ocean's corrosive liquid (mercury or hydrogen peroxide). This will make the ocean and Eve feel much more unique. The look of the planet will remain purple, but I intend for it to feel a bit darker, more ominous: a hellish volcano planet. In the screenshot above you can also see some procedural volcanic domes. Those are unique to Venus and I think they really add something previously unseen to the game. Gilly No concrete ideas yet. Kerbin No major changes planned. It looks good and aside from some detailing here and there it's fine. The lite and overhaul version of Kerbin will be relatively close. Mun I plan to reduce the density of the large craters and introduce some features that makes our Moon, the Moon, such as relatively flat basaltic plains (the dark grey maria where many of the Apollo's landed). Minmus The basic concept will remain the same, but Minmus will have a bit rougher terrain. I plan to keep the flats similar, but the mid-and highlands should be a bit more uneven. Look to comet 67P for an idea of the difference between the smoother and the rougher parts. Duna Duna is an ugly, featureless lump of red rock. People just want a KSP version of Mars for this one and I plan to give them that (as far as the original layout allows me). I'm trying to go for mesas, procedural craters, more mountainous areas, etc. Transform that central valley into something that feels more like Valles Marineris. Ike No concrete ideas yet, although the rusty coloration of Mars' Phobos and Deimos are much more interesting than Ike's dull greys and blacks. Definitely getting procedural craters. Dres See the screenshot above. Dres is a boring Mun-alike. I intend to spice it up by making it more oblate (like Ceres' neighbor Vesta) and giving it rings like Chariklo (the only confirmed rocky body with a ring system). The latter also lines up with Squad's addition of procedural asteroid in a ring-like orbit a few updates back. Hopefully this will help more people to go and visit it at least once. WIP ring btw, just a modification of Urlum's. Jool More like Jupiter, but keeping in line with dark ominous look of Jool. Laythe Pretty much the same, as it's a very high-quality planet. It's surface will have darker and rocky textures to make it feel as volcanic as it's supposed to. Vall No concrete ideas yet. Tylo Probably going to make the surface more like the real Ganymede: icy and irregular. I'll keep the high gravity though. It's not as unrealistic for its size, useful for getting gravity assists/capture and unlike Eve an airless rock doesn't have as many options to make it feel unique. Bop No concrete ideas yet. Poll No concrete ideas yet. Eeloo The same as the Eeloo overhaul in OPM. If you have OPM installed, it'll move it there but otherwise it'll remain in its current orbit. Thoughts, comments, critiques, etc. are always welcome.

@MrHappyFace Back in the day I completely glossed over the ModularNoise feature, mostly because it looked so complicated, but since then I've learned more about procedural generation. This ModularNoise looks like it could solve many of the limitations that stock noise is running into. Would it be possible for this PQSMod to be made standalone, so that it could be included with Kopernicus or with mods that use it. Because even if it were to be updated, it'd mean KopernicusExpansion would be mandatory instead of optional. All of your other additions to Kopernicus are that, additions. It's there for those who want it, can run it, etc. That's perfect for those things, but this ModuleNoise would be essential to any mod that used it.

@Poodmund, sure.

Finally got around to updating the OP (it still used the old forum's formatting). For the mods I've basically just weeded out the incompatible mods from the older list. But there's some newer mods out there too that are ideal for a recommendation, provide support for OPM or use parts of OPM. I have a few of them in the back of my head, but if you have any suggestions just drop it here and I'll add if it's relevant.