Shader loader/replacer

[rbray89]

Hey All!

I was thinking about creating a shader loader for EVE, and then it occurred to me, why not just make it a new standalone plugin?

The idea is that it would read in all files ending in *.shader, load them up in unity so that they can be called on with Shader.Find().

I *think* this should work with parts, but I'm not entirely certain. This could mean authors could craft their own shaders for specific uses, and have an easy way to get them into KSP.

Thoughts?

[nlight]

I am very happy that I'm seeing this thread! I have put some work into making this happen but sadly it's not at all trivial. The first issue I encountered was that you cannot just pass shader code to Material, you have to go through the Unity compiler first, open up the compiled shader and copy its source. This is semi- OK, it makes things a bit inflexible but we can work with it. The other issues are worse though - first KSP renders with 3 cameras instead of one and blends the results onto each other. This makes many usually trivial post-processing effects like SSAO, DoF and many others to now become very tricky to implement. This is mostly due to the three cameras having different far/ near planes and therefore their depth buffer ranges are very different, I cannot see how this can be worked around without major loss of precision somewhere, maybe somebody can prove me wrong. I see replacing part shaders as being doable in two ways - either walk the scene and forcibly replace all Renderer.material's or use Unity's render with replacement shaders functionality. Both of the approaches have different drawbacks, but I have mostly explored rendering with replaced shaders so I can tweak the cameras to get proper depth buffers. Another thing I've tried is forcing deferred rendering on all the cameras, but many fixes need to be made for this to work also. I hope somebody can figure out how to get a normal and depth buffer with good precision that contains the whole scene, this will at least open up the possibility of a nice post-processing framework. As to replacing part shaders, this will also be fun to do, the only success I've had is to write shaders that have completely identical inputs/ outputs to KSP's stock shaders (which I've had to decompile for this). Also it seems that for some reason most of the part shaders are marked as Transparent and this brings a whole another bunch of problems. Sorry if this seems somewhat incoherent, I've worked on this some time ago and some details slip my mind, this is pretty much what I can remember.

Here is my GitHub repo that I've now made public which contains a semi- working implementation of depth of field + some material replacement by walking the scene. The DoF implementation has its own huge issues but the shader loading stuff is there. Sadly I've seem to have lost the shader sources themselves, but the dof shader was from the default unity pack so it should be pretty easy to setup.

Edited December 18, 2014 by nlight

[rbray89]

I am very happy that I'm seeing this thread! I have put some work into making this happen but sadly it's not at all trivial. The first issue I encountered was that you cannot just pass shader code to Material, you have to go through the Unity compiler first, open up the compiled shader and copy its source. This is semi- OK, it makes things a bit inflexible but we can work with it. The other issues are worse though - first KSP renders with 3 cameras instead of one and blends the results onto each other. This makes many usually trivial post-processing effects like SSAO, DoF and many others to now become very tricky to implement. This is mostly due to the three cameras having different far/ near planes and therefore their depth buffer ranges are very different, I cannot see how this can be worked around without major loss of precision somewhere, maybe somebody can prove me wrong. I see replacing part shaders as being doable in two ways - either walk the scene and forcibly replace all Renderer.material's or use Unity's render with replacement shaders functionality. Both of the approaches have different drawbacks, but I have mostly explored rendering with replaced shaders so I can tweak the cameras to get proper depth buffers. Another thing I've tried is forcing deferred rendering on all the cameras, but many fixes need to be made for this to work also. I hope somebody can figure out how to get a normal and depth buffer with good precision that contains the whole scene, this will at least open up the possibility of a nice post-processing framework. As to replacing part shaders, this will also be fun to do, the only success I've had is to write shaders that have completely identical inputs/ outputs to KSP's stock shaders (which I've had to decompile for this). Also it seems that for some reason most of the part shaders are marked as Transparent and this brings a whole another bunch of problems. Sorry if this seems somewhat incoherent, I've worked on this some time ago and some details slip my mind, this is pretty much what I can remember.

Here is my GitHub repo that I've now made public which contains a semi- working implementation of depth of field + some material replacement by walking the scene. The DoF implementation has its own huge issues but the shader loading stuff is there. Sadly I've seem to have lost the shader sources themselves, but the dof shader was from the default unity pack so it should be pretty easy to setup.

Ha! Funny! I did pretty much the EXACT same thing with KSP for my EVE overhaul... The atmosphere effect and ocean depth changes I'm working on required a working depth buffer, so I extracted the Squad shaders so I could add the "RenderType" shader tag to them. I then grab all the materials and forcefully replace all the shaders. I do this at the begining before parts are created, so when the parts are duplicated, they bring the new shader with them. I also go through the cameras and enable the depth rendering. It works pretty well for me, but unfortunately, as you said, the multiple cameras thing is tricky. So far, I've resigned to only doing depth stuff on the "Far" camera, and making sure the effects "fade in" as they approach the camera before they hit the near clipping plane.

You can check out all the work I've done so far at https://github.com/rbray89/EnvironmentalVisualEnhancements/tree/Overhaul