rbray89

Shadow configs are required for them to work. What pack are you using? Logs? Screenshot? (Help me help you) The celestial shadows *should* be fairly accurate with regards to umbra and penumbra. Not certain with RSS though. Things that could trip it up would be things like scaling issues and Kopernicus not setting radii correctly. As distance increases from the Sun, penumbra becomes less and less. The only reason we have penumbra is due to the size of the light source. So if your sun is only a sliver of light, your penumbra will basically be non-existant. So yeah, in many circumstances (eg. Jool) the size of the sun isn't large enough to create MUCH of a penumbra (it is still there if you look carefully). Kerbin-mun creates a sizable Penumbra on the other hand. Most of the images online demonstrating Umbra/Penumbra aren't good representations because the scale is WAY off. EDIT: Added code for the curious. v is the point of interest, R is the Solar radius, r is the body radius, P is the Sun position p is the body position. inline half BodyShadow(float3 v, float R, float r, float3 P, float3 p) { float3 D = P - v; float a = PI*(r*r); float3 d = p - v; float tc = dot(d, normalize(D)); float tc2 = (tc*tc); float L = sqrt(dot(d, d) - tc2); float scale = tc / length(D); //Scaled Sun Area to match plane of intersecting body float Rs = R * scale; float A = PI*(Rs*Rs); float s = saturate((r + Rs - L) / (2 * min(r, Rs))); s = (INV_PI*asin((2 * s) - 1)) + .5; return lerp(1, saturate((A - (s*a)) / A), step(r, tc)*saturate(a)); }

I prefer a case-by case basis... Exposing the GUI directly would lead to (in my opinion) too many people messing with things they probably shouldn't mess with

ALT+0

No worries, let me know what you find.

You are running out of memory. Looks like it might actually be caused by Kerbal Alarm Clock: 5/1/2016 5:26:41 PM,KerbalAlarmClock,API Ready (Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64) DynamicHeapAllocator allocation probe 1 failed - Could not get memory for large allocation 673616. DynamicHeapAllocator allocation probe 2 failed - Could not get memory for large allocation 673616. DynamicHeapAllocator allocation probe 3 failed - Could not get memory for large allocation 673616. DynamicHeapAllocator allocation probe 4 failed - Could not get memory for large allocation 673616.

If I were doing this, I'd do it this way: Texture on Y axis. Offset of x,z,0 Speed of x,z,0 Rotation Axis0: 1,0,0 Rotation Axis1: 0,0,1 Rotation Axis2: 0,1,0 You just have to remember that you aren't using the body's axis, you are using the CLOUD axis. You have to imagine the axis being moved around. This also means that you could do NON-X/Y/Z axis too... Say you want the clouds to swirl around the planet, you can do so by messing with Axis0 and Axis1 and speed/offset of x and z. EDIT: Thought I'd explain what you are seeing in your second GIF as even I had trouble visualizing it. What is happening is that when you rotate on Y, you change where your X and Z axis are. This isn't much of an issue when you only use X to rotate after your Y, but when you think about it, you end up with something like this:

The axis of rotation are applied in order... As are the offsets. So what you can do: Place the texture on the Y axis. Rotate on Z or X using offset Rotate on Y axis using speed. This will get you a spinning texture at wherever you rotated the Y axis to be.

Yeah, it was lazy of me, but it wasn't game-breaking so I didn't bother pushing a "real" update so to speak.

This may simply be an old install (there was a quick patch put up shortly after release to address this).

Now that we have command buffers, it should actually be surprisingly easy to do. I have a few things I'd like to add before I get there though.

Also, with EVE, I made it so the cloud layers can rotate on up to 3 axis, and an option to "kill" (negate) planetary rotation. What this means is that you could set an axis on X or Z with body rotation killed to create a Uranus style rotation.

Exactly! Be on the lookout for it. Craft aren't currently affected yet though. I actually do something similar in the shader (the large equirectangular format has been replaced with a multi-map system. Textures can now be represented as 6 (or 2) textures where RGB components equate to the different sides of the cubemap, or one channel in the 6 textures is used for one alpha mask). The problem isn't actually the mechanism, it is my awful textures (programmer not an artist) If you open up the textures in GIMP or PS you'll see what I mean. Other pack authors actually know what they are doing in graphics packages. I just supply the backend Right now my textures are 2k (actually scaled from 1k without any detailing), but they could easily be bumped up to 8k (for machines that can handle it)

This is simply beautiful. Wow.

You *CAN* use openGL from my testing.

Don't use DX11. It is in a pretty unusable state at the moment.

Don't forget to add a PQS Manager entry for non-PQS entities (gas Giants). There is an example there for Jool.

ALT+0. Navigate to the clouds config, and either disable the volume clouds (radio button) or lower the Area values. Don't forget to hit apply and save.

Sorry, just Area. First value sets the size of coverage, second value is density.

ALT+0 and navigate to the clouds config. There you'll see in the volumetrics section two config items for IIRC Area and Division. Area controls the size of the spread, and division controls density.

Congrats! I hope this doesn't cut into your modding time *too* much

I'm working on a few small tweaks that may help performance.

Working on the crashes. Unfortunately it seems as though the unity upgrade borked one of the functions I was heavily relying on. I have to refactor a LOT of code to get this to work, and early testing shows that it may not be possible. I'll keep you all informed here of any progress.

I wanted to make sure no one could use the excuse "I didn't see that" Not at the moment. I have plans for this however.

Unfortunately it still has to sample the texture 3 times, but I won't have to do other expensive operations to blend them, so it will be a tiny bit better.

Yes, the mipmaps are used in all instances.