blackrack

When it's released you'll have to update EVE and get a different set of configs. Old configs will continue to work as before (it's retrocompatible). Thank you. Considering I do these checks for 460800 pairs of points currently (2560x1440 / 8) per regular frame, 28 per physics-frame shouldn't be an issue. However is a delay of 1-2 physics-frames acceptable in the update of visibility-reduction? It would allow calculating the checks asynchronously on the GPU (the same way scatterer does wave interactions) for even lower CPU load and a simpler implementation (won't need to readapt all the shader code for the CPU). Could this delay be ascribed to pilot reaction time for example, or even just not be noticeable?

Click for better quality

The colors and shading on your planet don't look like mine, so I was wondering if you're using the stock configs or something else.

I looked for this issue today but it's not there Does this happen all the time or randomly? Is Kopernicus installed? Also your settings look a bit different.

It was improved but still happens in some areas (to a lesser extent). You know you can disable the feature that causes it right?

From KSC menu press the scatterer icon (blue orb) and find the setting for temporal antialiasing. Thank you. That's not an NRE though, it's a debug message as in nothing is thrown and scatterer handles it internally, there is no actual error breaking anything. I'm not sure what's causing your problem but you might want to not run opengl on win 10 already, not only does it run supet bad and not support some features, it also heavily bloats the memory usage which may lead to crashes. Just run directx11, remove whatever commandline parameter you added to force opengl.

I was planning to add a similar thing, primarily to have clouds be cut down by mountains but that's still up in the air and may come later. As it stands right now relying entirely on animating the noise for this won't be enough for what you want. There will be, I'm attacking configs for all bodies soon and will surely post some. Yeah I plan to fix the bump maps with scatterer but that won't be right now though.

Yes there is a cloud type map, and although I did describe it as a biome map I should have added that it rotates with the cloud map and is not locked to geographical position. The reason is that the coverage map and cloud type often have to work together to look good, for example cumulonimbus clouds should have low coverage edges as a lead in and shouldn't appear randomly anywhere, otherwise it looks really weird. A motion map, I guess you mean similar to a flow map, is also possible but would also need doing double samples and interpolating between them, so will be expensive. I was planning on adding it for the decals I plan to add later to do storms, however it seems like a really worthwhile addition so I think will bump it up and do it earlier.

Yeah both the cubemaps and detail textures will be supported, although I haven't added support for detail textures yet but it will be there, I know it's important for some pseudo-dynamic cloud setups. So I don't have a self-lighting option yet but it will be trivial to add so I can add it. There is a density variable that controls how the cloud looks and it can go anywhere from dense cloud to very thin mist/fog. It's a bit different from painting a lower value on the 2d map as that works more like "this point has this % chance of being covered by a cloud", if that makes sense, the 2d map essentially works like a probability map that modulates the 3d noise, I just call it "coverage map" now. For example in this old gif I posted a while back I'm animating the alpha value of a 2d map (basically just i terpolating it over time from 0 to its real value) and this is how it behaves, notice it never turns to thin fog/mist just cloud blobs: I plan to provide this and a density fade as transition modes for when I fade layers in/out over time (what I plan to use for pseudo-weather transitions, making rain/fog/clouds appear/disappear at given time intervals etc). Also this means that if you use the detail texture to make pseudo-dynamic clouds and you give it soft edges it will behave like this as well when transitioning.

The only problem I see is that you have a GameData folder inside GameData. First try deleting that additional GameData. Second try to run without any other mods and just a fresh reinstall of scatterer+EVE+boulderco and see if anything changes.

If you weren't able to persist scatterer settings they'd revert between scene changes too, so I'm not sure what's going on there, maybe a random ModuleManager patch? Anyway I personally wouldn't worry about a UI error if everything is working. If someone else wants to chime in though they're welcome.

Four months for me to finish my stuff in peace

Does this break anything?

Maybe not

Not yet but soon Can't really tell much, but likely a config issue, include which mods you installed+versions+log file, and more screenshots

Ah I see, well in scatterer there is the issue of not lighting the terrain like you mentioned but also if you want to use it as planetshine the angle to the sun isn't taken into account, ie no full moon or moon phases but always a constant intensity.

Which games are those btw? Just for reference. I know in msfs it looks really bad from orbit (and the draw distance is limited). I see what you mean, like it's done in the terrain shaders, but already that implies doubling the noise samples in the raymarching loop and blending between them, which is very expensive because it's in the raymarching loop and it's done potentially hundreds of times per pixel, then there is the issue of this scaling throwing off the balance of things like cumulonimbus clouds and the vertical profile of the clouds in relation to what is painted horizontally on the clouds map. This will introduce all kinds of problems so not sure about it for now. This will make more sense after release when you see how the clouds are configured and how a delicate balance is needed between the noise scale, the cloud height, and what is painted on the cloud map. With that said, on Jool there is probably going to be some large scale clouds which work well from orbit, I hope that works as well as I'm imagining it

You need separate EVE configs, they can also be configured with the existing EVE gui. That really doesn't do much apart from making them look like a blobby version of the 2d texture. I think there was a misunderstanding, the issue is not that to make the light itself static, the issue is that when traversing the volume you also need to do a secondary traversal towards the light source to find how much light actually reaches inside the cloud, that's what gets expensive with multiple lights and it doesn't look right when replaced with a flat term. For me rainbows have been very rare irl (and I've never seen one from a plane to this day but I've seen every other atmospheric phenomenon) but yeah they just look silly in my opinion and I don't think they are worth the effort. Maybe an install issue but you should ask in the KSRSS thread.

Star citizen seems to be the closest, but they also seem to scale the clouds waay up to avoid those issues.

Yeah things really don't look good at all from orbit right now unless scaled to humongous proportions, it's hard to explain but it's a combination of the temporal upscaling not handling high-frequency detail well, the raymarching noise/flickering at those distances and the noise/cloudtypes distributions looking uniform-ish and repetitive at that scale. If scaled up to look good from orbit they look very big and out of place from the ground and when flying through at low altitudes, while still looking unrealistic from orbit. I'm not sure what you mean about the transition but the 3d volumetrics are derived from the 2d layer so fading in to the 2d should be ok. In the previous images I posted both the godrays and the cloud-on-cloud shadows are just read directly from the 2d layer texture for performance and you can't tell most of the time. Ehh they don't add much in my opinion. Besides, IRL I see them very rarely.

Please take this to JNSQ thread.

Yeah I was thinking about scatterer's secondary lights but it can't do planetshine yet, so just additional suns. Additional lights will nearly double the performance hit as at every point raymarched a secondary raymarch needs to be done towards the light source. I was thinking of dropping the quality of secondary lights or trying to find some other approximation. Maybe even only sample the light currently shining the brightest, that way it cycles between different lights as needed, and still sample the sky and scattering contributions for all lights to help blend it. For using the world itself as light source it'd probably "just work" if there is support for multiple lights just like in scatterer where people put an atmo on the sun and make it shine on itself. Also, point lights with no secondary raymarch seem to work and look ok from what I've seen in other games (typically used with lightning on the clouds). I might try that and see how they look (I plan to try lightning at some point), if they work ok maybe I'll consider using it for custom placeable lights or have other light approximations like a global gradient instead of a totally uniform light.

Thanks. Right now the view from orbit is still the weakest part, and while it has improved from the last time I showed screenshots I still don't have enough variety in noise/shapes/shading yet to make it look good. In addition the temporal upscaling starts to deteriorate in quality from orbit showing increased artifacts and blurring. So it can do 3d in scaledSpace and the transition altitudes to 2d are going to be configurable but for now I'm going to go with a relatively early transition due to the above issues. At the moment clouds at night are still pitch black. They don't look good with a uniform "ambient" light and need a directional light. My goal is to have them be lit by the mun or a second body at some point for a convincing night look.

I haven't tested that in a while but somewhere around 200-300 fps iirc