plonk

@Jhaxxar Have you tried to copy, paste and run the example code from the docs? Here's the link again: simple-example Try running it with a console window opened and the telemetry window opened. If the cosine plot appears in the plot window, all's fine. If not, you'll probably get some error messages either in the console window (as I do), or in case of compiler related error messages in the mod's main window under "reboot errors". The "telemetry" window is essentially a plotter, providing some convenient features like autoscaling and JSON export of its data. For each plot you'll have to create a TimeSeries Object by callingthe add_time_series function. Once you've got the TimeSeries Object, you provide your datapoints by calling the object's add_data function. At least that's what the example programs do. But currently it's broken in version 0.4.1.3, at least on my side - for the error message see my last post.

Am I assuming correctly that you too get this error when calling add_time_series() ? >>>>> ERROR <<<<<<<<< Module plonk::testgraphs terminated with: Object reference not set to an instance of an object And are using version 0.4.1.3 as I am? If so, I'll file an issue on github. I can't even make the example code from the docs (simple-example) work.

Yes, yes, yes! Automation for KSP2! That's better news than KSP2 release. Oh, what a crapload of kOS (and load of crap kOS) code there is to port over. Thank you very much, @Untoldwind, as you gave me a reason, or should I say an urge, to try out KSP2 again. Although I bought and installed it on day 0, for me KSP 2 alone has yet too few to offer to even think about playing it. Seemingly things have changed now. I am really looking forward to playing around with TO2.

I've been following this thread since first release but did not dare to try out this mod on my ancient (12+ yrs) machine. Until 1.12 started wrecking ships and made some planes jump around like bitten by a snake in my career game. I tried to narrow down if there's a mod responsible for those problems(it's not). But hey, I was on the edge of throwing KSP out the window anyway and had made a seperate installation, so it decided to try it out. Then a big smile went over my face! Never thought it would run decently on a GTX660 full of years old dust, but it surely does! And it does run pretty smoothly as long a there are not too many lights around. I was very impressed, and I still am. Thank you very much @Gameslinx, for making my day. This fine mod almost made me forget the annoyances with KSP 1.12.1 Keep up the great work!

Yes! Fix confirmed. Great work @R-T-B, thank you very much! Replacing the sunflare works fine, too. Astroniki's sunflare is back!

Actually, terrain geometry is occluding the flare, too. I should have posted better images. Added two more to the gallery linked in my previous post. While providing new sample images, I've discovered another oddity: if moving the camera towards the ship (see image #4 vs.image #5) the sun (not the logical lightsource itself) disappears. Edit: I cannot pinpoint situations where the flare disappears while the sun is over the horizon (like img #4 & #5), yet. I'll report as soon as I see the pattern

That's totally understandable. Sure thing! Have a look at the images on Imgur Big thanks for your efforts!

It's so good to have scatterrer back scattering! KSP simply feels wrong without it. But on my install, lenseflares are still occluded by geometry. Interestingly, in map view lensflares are rendered correctly. I tried unofficial Releases V1.41 nvidia shadow hotfix, and V1.3, both with dx9 and dx11. My machine is pretty old and limited though, having 8G RAM and a GTX660 with 2Gig. Despite of this, the occlusion issue didn't occur with KSP 1.8. Anyone out there, running KSP 1.9.1 with scatterer on an ancient GTX660 without this bug? KSP.log on paste2.org

If I may add, most decent editors can record, save, and exec saved macros (e.g. Sublime Text). You have a pretty good usecase for them here. Text replacements via RegEx can also come in very handy every now and then.

Hi, and welcome to the forums. Sure. It's essentially derived of the configs I've found in this thread. I don't remember anymore which user provided the base works for this particular config, so thanks to all users that provided configs. You should also try out others' configs, and modify or merge them. Be sure to check the output of the debug console (alt F-12) or the KSP log to identify unsupported config sections/shaders. For example, I run into problems if I try to use Eye_Adaptation. Hope this helps,and here you go:

Not really, but some kind of. You need to prepare mask images and config files for the parts though. See another Mod, namely TU Stock Recolor which is part of the TU Recolor Depot available here: It comes with a simple GUI that enables you to tint (not replace) colors, adjust reflectivity and metalness in the VAB/SPH. It's not too comfortable to work with, but it does the job. Here's a screenie of TU + TU Stock Recolor in action, running on my old GTX660. I've assigned the chrome, grey and green colors using Stock Recolor's unified switching GUI. Here is an example of a mask, converted from dds (TURD\TU_Stock_Recolour\Command\MK2 Cockpit Standard\131_mk2Cockpit_Standard_Paint.dds) to png (via tga): Once you've got the masks set up, you need to either add a config patch or directly modify 141_Standardised_Recolour.cfg to add TU Stock Recolor functionality to each of your parts. If you want to create masks for stock parts, have a look at DDS Utilites here https://developer.nvidia.com/legacy-texture-tools. You can use readdtx.exe to convert dds textures to tga, and nvdtx.exe to convert back to dds format. Hope this helps. Thank you very much for your reply! I've got VS 2017 and Unity running, and even step debugging of my first "hello world" mod is working in VS, when running it in KSP, too. Now the hard part is getting into unity, and understand how it interops with KSP and Mods. Luckily there are lots of mods to dissect, like for example TU. This will take it's time, but I think I am on track. Will report back, as soon as I've managed to modify the shaders/SRP and use them in KSP (, or completely fail at it for some weeks).

That's, great. Meanwhile I've began to read into how Unity's graphics works, but there's no way of trying things out at the moment. Sadly, spare time is rare. I didn't install Unity, or Visual Studio, yet. And if I'd do, I'd have no Idea how to set up an environment to test KSP mods and shaders. So please let me rephrase: " Maybe someone can give a pointer / links to a condensed guide to get started modding KSP and its shaders?". I'm probably going to make a fool of myself again, but I've been using Notepad++ without syntax highlighting, and found out most using "search in files" so far. I didn't anticipate how deep the rabbit hole goes when I started. Should've known better. All this started simply because I couldn't believe that the shadow map can't be used to inhibit the specular highlight, completely unaware of how Unity works. After some searching, it seems IDE support is rare and often limited to GLSL. At least in the OSS domain. Maybe Visual Studio does a good job, since HLSL is developed by Microsoft. In the meantime, I've been reading some stuff and think the places I've found are the right ones, but changing them is wrong. Found a seemingly brilliant tutorial, which also covers the built-in shaders, and tweaking them. Now I think, modifications have to be carefully inserted into the "scriptable render pipeline" - as opposed to modify the library files. ( I've no practical experience at all in dealing with unity. So my view may be completely BS, still!) I'm still thinking, there's hope to get rid of shadowed spec. highlights, at least in space where there's no atmosphere, having the brightest spot exactly at sun's location (as atmo reflections must not be affected by shadows). See the aforementioned tutorials here: https://catlikecoding.com/unity/tutorials/. I think they're pretty promising. For info on the scriptable rendering pipeline, visit: https://catlikecoding.com/unity/tutorials/scriptable-render-pipeline/ In my naive read-through, I've got the impression that FragmentGI does not take atten (and therefore direct light occlusion) into any account, except returning it in the UnityGlobalIllumination struct. I did not find a place where it affects the specular highlight of the main light in any way, yet. Seems to always get down to one of FragmentGI in UnityStandardCore.cginc and finally one of the UnityGI_* functions defined in CGIncludes/UnityGlobalIllumination.cginc Yes, you're definitely right. But (my) KSP has only one light source supporting a shadow, the directional light of the sun. There's also a distinction between the directional "main light" and other lights in the docs and tutorials, but I'm not yet experienced enough with Unity/KSP to really judge what's going on. #ifdef (and other) overkill. @Shadowmage Please nudge me towards correct directions if I'm getting things wrong. As far as Unity is concerned, I feel like an eunuch right now. I have a rough understanding of how it works, but I can't do it.

I'm neither a KSP modder, nor a gpu-shader wiz of any degree, nor do I know much Unity3D specifics. But I do know pretty much of the maths and many techniques involved in CG, and I'm experienced in C-like syntaxes (A couple of years ago , I've developed some CPU based raytracing and raymarching visualisations of x-ray CT and MRT volume data [C/C++/Java], and have played a little with WebGL). So I went on a little adventure, reading "alien code", after I've downloaded the built-in shaders' sources (here, took Version 5.4.0 built-in shaders) and digged through the code. I dug through small parts of TU to find out what it actually customises, too. Not too deeply though. Tricky, but interesting stuff. This is dragging me into a deep abyss! Curiosity kills the cat. To whom it may concern, my modest findings (WARNING: might be complete BS) : Although it's extremely interesting and tempting, I do not want it's probably not a good idea to extend this topic here in this thread, since it doesn't seem to be a TU specific topic, and I'm far from beeing an expert on shaders. It's fun anyway. Maybe someone can give a pointer / links to a better choice of thread?

That sounds a little odd, probably because I've wrong assumptions about rendering in KSP/Unity. My first bet would have been, that the information stored in the sun's shadow map would suffice to decide if a point is lit directly by it's light or not. At least in (unoptimized) theory, shadow maps are geometry agnostic, too. Looks great anyway. Guess, I'll browse the Unity docs for a while, to get a rough understanding of it's rendering pipeline. Just out of curiosity. Thanks!

Looking for advice: I noticed, that specular highlights from the sun appear in shadowed areas. They are dimmer than in lit areas, but they are still very visible. Is there a way to dial their intensity down when in shadow, maybe via config?

It took almost a whole day of tweaking configs and NRE's, but now I've got KS3P running fine in concert with Scatterer + EVE + PlanetShine + Texture Replacer +Textures Unlimited on a GTX 660 (DX11 for TU). It makes me very happy to see this running on my aged hardware! A big thank you, @The White Guardian for this great mod. And some big thanks to all you guys posting configs to learn from, and start with!

After a saturday of fiddling with configs and NRE's, I finally got it all working: Scatterer + EVE + PlanetShine + TR with visor reflections + KS3P + TU in KSP 1.6 on a GTX 660. Framerate is not the best, but it makes me very happy, to see this running on my aged hardware. A big thanks to @Shadowmage for this awesome mod. I do not want to play KSP without it anymore!

Whoa. KSP 16.1 as of 2024. You guys really plan ahead!

Take a look at the OP, under Current Major issues. There's a link to the unity docs.

While doing my regular scan for mod updates (I want to switch to 1.6), I browsed through the release pages on github. I came across this: https://github.com/linuxgurugamer/ksp_toolbar/releases?after=1.7.16.0 Maybe the one on top is one you're looking for.

Java support, too! This is going to be fun. Got the connection test script from the tutorials working, and eagerly looking forward to port some badly slow kOS code containing two nested loops (100 steps each or more) to a kRPC client. Behold! so much possibilities! Thumbs up and thanks, this really made my day (and will do for some others coming). Great stuff.

@maculator Have you checked the version number in the scatterer screen in game menu? Strangely, both DL links in the OP, Mega and SpaceDock, offer a zip named scatterer-0.0300.zip, but both of them show "Scatterer v0.0275 preview". After noticing that when installing SVE 1.2, I took (only!) scatterer from the last bundled version (https://github.com/Galileo88/StockVisualEnhancements/releases/tag/v1.1.6) from which I remembered that it came with v0.0300. I did not try SVE 1.2.2 yet. Hope this helps!

Very wet! I'm looking forward to the next images. I now have to check, if one can configure some kind of backback with ballast to keep a kerbal submerged. Maybe with KIS. This looks really great!

By looking at the image, I assume you have the intensity of the refractive component calculated according to the fresnel equations. To me it looks, as if the transmittant (refractive) component is rendered pretty good, and "all that is missing" is the reflective component. (The observed phenomenon is called Snell's window. See https://en.wikipedia.org/wiki/Snell's_window ) At this point, to achieve a physically accurate model, you'll probably need to incorporate another, custom tailored mie scattering. And reflection maps. And, and... Maybe I've got an idea of how to crudely, naively and inaccurately (i.e. purely visually) approximate fake the intensity values for the reflective component by taking into account 1) the distance of the camera to the surface (perpendicular) 2) the length of the view ray from camera to surface, 3) the length of the reflected view ray (clamped to a max value, length to ground otherwise) and 4) the cosine of the angle of the reflected view ray to the water surface (or sine using the normal). It's basically distance fog with additional steps to increase light intensity the nearer and more parallel the reflected view-ray is to the water surface. It's based on the assumption that there is more scattered light traveling in any direction at any point near the surface, exponentially decreasing in intensity the deeper it gets. Just an idea. Yours is probably already better

there's hope that this will be fixed soon https://github.com/KSP-KOS/KOS/pull/1902