rbray89

Oooooh! The cutaway shot gave me a great idea... You could render the IVA view to another texture, & use the alpha component on the textures for parts to render the insides using that texture (using screenpos co-ordinates in the pixel shader).

Yes. Not abandoned. It is just so different from the last version I had to refactor pretty much everything. Started a new thread, and suspended the old method of doing things.

You can do what I do: internal void Awake() { KSPLog.print(configName + " " + SceneLoad); if (sceneLoad) { StartCoroutine(SetupDelay()); } } IEnumerator SetupDelay() { yield return new WaitForFixedUpdate(); Setup(); }

Another possible option instead of a new texture for making ports invisible would be to use vertex color. The problem would then be to go through the mesh and re-assign port vertex colors. You could do the same to IVA internal parts as well. If you need any shader help, let me know!

It doesn't stop? That is odd. I'll have to look into that.

You could create another shader that has an additional mask for the texture that is toggled on open. This would be the way I would do it. Then you could open and close the hatch, and if you used all 4 colors, you could create up to four hatches that could open and close.

You can move BoulderCo to inside the EVE folder if you want. There should be no negative side effects. I'm actually planning on the exact opposite. I'm planing two releases, the plugins, and the content. This will allow for easier use of EVE config files.

The latest version is just the most recent commit to the overhaul branch. I commit the release package to the source as an easy way to generate releases. That's the issue though. Equirectangular mapping allows for better pixel density where you see it the most (equator) whereas cubic enforces much more uniform pixel density, but slightly worse at the seams. So to get similar density, you have to repack it at slightly higher resolution resulting in more pixels used overall. Editing textures also becomes a bigger pain, and would make a procedural generation method much more difficult I believe.

You would have to edit the Texture2D instance in-game (you can't just edit the file), but yes if you modified the texture, it would reflect on the cloud particles and 2D layer. - - - Updated - - - I did this at one point, but people complained about the increased memory usage. Clouds will be able to move in more directions once I make some enhancements to that mechanism shortly.

Hmmm... I'll have to take a look at that.

Basically, a depth map/texture is rendered based from the camera view. This is then projected onto the scene's shadow receivers. This is also why some weirdness occurs at the edge of the two camera planes. A good wiki article on the matter: https://en.wikipedia.org/wiki/Shadow_mapping

Performance mostly... Dynamic shadows are expensive. I tried doing it with the existing bodies similar to what you tried, but you get the issues you've seen. I'll be using a projector along with the scaled space body shader to render the body shadows.

Ah, true... I've been trying to figure out how to *Efficiently* do the shadows on bodies. I'm pretty sure I want to keep using the projectors, but I'm afraid multiple bodies will eat up all my interpolators.

I'm using it to actually perform depth checking on oceans, so it is required that I do this for the pixel shader. There are a couple implementations of ray-casting that could be used... but they are all iterative and can be pretty performance hungry. I don't think 1 raycast will make a huge difference, but many would. https://unity3d.com/learn/tutorials/modules/intermediate/physics/physics-best-practices Basically, ray casting has to loop over all the verticies/triangles in range and somehow determine which intersect the ray's path, and which is closest. My solution is an O(1) solution, ray tracing would be at BEST O(Log n) if it was heavily optimized in Unity. So you would end up just doing this once for the center of the body each update of course

Already working on it. I'm re-jiggering the shadow mechanism I created for the clouds to work for moons as well

Actually, Now that I think about it, this would actually probably be much less computationally intensive than a ray-trace. To detect if you hit the sphere: float3 L = _PlanetOrigin - _WorldSpaceCameraPos; // Vector to Center of body from camera float3 La = normalize(_SunOrigin - _WorldSpaceCameraPos); // Vector to the Center of the Sun (might also be able to use Vector3 La = Vector3.Normalize(Sun.Instance.sunDirection) float tc = dot(L, La); // Component of L that is parallel to the view direction float d = sqrt(dot(IN.L,IN.L)-dot(tc,tc)); //dot(x,x) gets magnitude squared. This just uses Pythagorean's theorem to get the distance from the center to the tangent of the view. if ( _SphereRadius >= d && tc > 0) // Check to ensure tangent distance is less than sphere and that we are looking in the right direction. { Collision = true; } I apologize for just using pseudo code here. Couldn't remember all the references to the math functions.

It doesn't have to be modified. When blank, it re-uses the one provided by default.

They should. I believe that is how the existing sun flare system works. The only other way I have is using spherical intersection models in my shaders You'd have to pass in the body origin and the radius however.

Alpha doesn't do anything there... It isn't supposed to.

Haha, it *should* but as that shader isn't used, it won't matter

Haha, I never even noticed that. E.V.E will be keeping its name for the meantime at any rate.

Yeah... I know what is going on here in the shader, I just need to figure out what the best way to address it is.

I'm very excited for this.

These values produce pink? The Terrain has an ocean color to color the seabed. Stock KSP does something similar but with the vertex color. We pass it in so it can be based off of visibility depth (eg. looking at an angle makes it closer to _OceanColor, looking from above makes it closer to the vertex/sand color). Really odd that DX 11 doesn't like it.

What were the values before?