Parts shaders replacement, PBR, WIP release!

[blackrack]

On 4/25/2016 at 9:38 PM, Porkjet said:

1.1 doesn't have reflection probes (cubemaps) yet, which are fundamental to this lighting model, so PBR is currently useless.

What do these reflection probes entail? Can we just write a plugin to render cubemaps of the environment/sky and use those with the PBR shaders? Because I'd be down for it.

[nli2work]

reflection probes are not absolutely necessary. A proper skybox for planets instead of the color gradient will make the biggest differece. Same transition point from planet to galaxy skybox. Probably make a noticeable different by changing Ambient Light source from skybox (unity default) to gradient in the Lighting setup, and match the gradient colors to the specific planet's atmosphere gradient. It would even make a noticeable difference to legacy shaders. Using reflection probes just to get ambient lighting for PBR is an incredibly wasteful.

Edited May 9, 2016 by nli2work

[Porkjet]

2 hours ago, blackrack said:

What do these reflection probes entail? Can we just write a plugin to render cubemaps of the environment/sky and use those with the PBR shaders? Because I'd be down for it.

Probably. Tho there are some difficulties due to the way the flight scene is composed. Also since we're stuck with Dx9, we lack some features that make realtime probes look better, smooth transitions between mip levels and 'edge fixup'. What's probably a better way is using premade cubemaps that are switched depending on situation (landed, low orbit, etc) perhaps even per biome. They don't really have to precisely reflect the surrounding, approximating the general colors of terrain and sky will do. However there's still the problem that 'up' and 'down' are quite relative in KSP, and the cubemap will be rotated depending on where you are on the planet. (at equator everythings on the side) It should be possible to modify the lighting model to be able to manipulate the cubemap 'rotation' tho. That's something I'll look into for the next update.

 

2 hours ago, nli2work said:

reflection probes are not absolutely necessary. A proper skybox for planets instead of the color gradient will make the biggest differece. Same transition point from planet to galaxy skybox. Probably make a noticeable different by changing Ambient Light source from skybox (unity default) to gradient in the Lighting setup, and match the gradient colors to the specific planet's atmosphere gradient. It would even make a noticeable difference to legacy shaders. Using reflection probes just to get ambient lighting for PBR is an incredibly wasteful.

We can't use gradient ambient in flight scene because as mentioned above, there are no defined 'up' and 'downs' in the flight scene, at the equator of a planet the ambient gradient would be tilted 90°. Reflection probes aren't wasteful at all, we'll probably only need a single one in the flight scene, and ambient is only one part of the visual benefits it brings. There's no reason to switch to PBR at all without reflection probes.

[nli2work]

If you can switch premade cubemaps/skybox per flight situation or biome, then you already have more than 75% reason to use PBR shaders. Ambient lighting, strictly speaking a reflection, doesn't require Reflection Probes, neither does light maps nor realtime GI. the only thing that requires reflection probes is real-time reflection like mirrors and polished metal, things that you would only see when you're close up. Reflection Probes add a lot to the visuals, and as you said, there're probably only need to be 1 in the scene.  It maybe required for KSP because of how the flight scene is setup but it's certainly not required for PBR rendering as PBR shaders already account for ambient lighting from skybox/gradient/ambient color without expensive reflection calculations.

Edited May 10, 2016 by nli2work

[nli2work]

 

Edited May 9, 2016 by nli2work

[Lilleman]

The renderprobe object itself is the most "transparent" way to get this working, but it seems to have too much limitations at the moment, compared to a camera, to render a cubemap.

I tried to render a cubemap following this script http://docs.unity3d.com/ScriptReference/Camera.RenderToCubemap.html but it got the same problems( rotated textures, and terrain not reflected). Though I probably should've used TR sources instead, I really didn't expect it to work on first try...

 

@nli2work What's happening in this last vid?

 

 

V0.04 Changelog :

-Added an UI in flight scene (still WIP).

Added the possibility to refresh shaders masks after reloading the game database.

 

Download : https://www.dropbox.com/s/qh714b3p6an1e9i/PBRShaderLoader_v0.04.zip?dl=0

Sources : https://www.dropbox.com/s/a2jeqd5a2jg8fd6/PBRShaderLoader_v0.04_src.zip?dl=0

 

Edit: Already found a bug, sorry : the reflection probe can't be reenabled via the UI. I'll fix it for next release.

Edited May 9, 2016 by Lilleman

[Starwaster]

14 minutes ago, Lilleman said:

The renderprobe object itself is the most "transparent" way to get this working, but it seems to have too much limitations at the moment, compared to a camera, to render a cubemap.

I tried to render a cubemap following this script http://docs.unity3d.com/ScriptReference/Camera.RenderToCubemap.html but it got the same problems( rotated textures, and terrain not reflected). Though I probably should've used TR sources instead, I really didn't expect it to work on first try...

The code on the page you linked to is the basis for reflection plugin first created by Razchek and then picked up by myself:

https://github.com/Starwaster/Reflection-Plugin-Continued/blob/1.1-Update/ReflectiveScript.cs

The Texture Replacer plugin uses some of that code only they render in three passes (skybox -> scaled space -> terrain), a change that I've incorporated back into the Reflection Plugin.

[nli2work]

3 hours ago, Lilleman said:

@nli2work What's happening in this last vid?

Not sure to be honest... I don't know exactly what flight scene setup is, I understand it's a bunch of cameras render different scenes layered together, but apparently they don't all move the same... looks like it's reflection of galaxy map mesh being left behind. I guess it shows the galaxy map is on a mesh object and not a real skybox, and its position is reset when you timewarp

Edited May 10, 2016 by nli2work

[Starwaster]

7 hours ago, nli2work said:

Not sure to be honest... I don't know exactly what flight scene setup is, I understand it's a bunch of cameras render different scenes layered together, but apparently they don't all move the same... looks like it's reflection of galaxy map mesh being left behind. I guess it shows the galaxy map is on a mesh object and not a real skybox, and its position is reset when you timewarp

What it kind of looks like is the camera's viewpoint not moving with the ship or part's transform. But I'm not sure that can account for everything happening in your video

[Lilleman]

10 hours ago, nli2work said:

Not sure to be honest... I don't know exactly what flight scene setup is, I understand it's a bunch of cameras render different scenes layered together, but apparently they don't all move the same... looks like it's reflection of galaxy map mesh being left behind. I guess it shows the galaxy map is on a mesh object and not a real skybox, and its position is reset when you timewarp

That's what it looks like, but it shouldn't be happening: at the moment, it's still a simple reflection probe, supposed to be attached to the vessel's root part...

I realize the last updates were only to make it work, without success so far. I'll focus a bit on something else for the next release(clean the code and add a few functions).

 

Got a bit bored of trying to make reflections work with vessels, so I'd make them not work with planets, too! (glitches may have been cropped from this screenshot)

Edited May 10, 2016 by Lilleman

[nli2work]

4 hours ago, Starwaster said:

What it kind of looks like is the camera's viewpoint not moving with the ship or part's transform. But I'm not sure that can account for everything happening in your video

The navball did the same thing before it was culled from reflection probe. the galaxy map could physically be anywhere really, even a tiny cube for all that matters, if it's just a camera projection layered onto the player camera. it doesn't have to move at all. it certainly makes it difficult to get an accurate reflection that way. At least with the way it looks, it's a sizeable box that contains the player vessel. Planets/Sun are outside of it seen by a different camera, which is what you see in the video, the vessel and it's reflection probe passing through the galaxymap box, and reflect the actual Sun geometry in a black void, since there's no real skybox at all.

 

Edited May 10, 2016 by nli2work

[Starwaster]

1 hour ago, nli2work said:

The navball did the same thing before it was culled from reflection probe. the galaxy map could physically be anywhere really, even a tiny cube for all that matters, if it's just a camera projection layered onto the player camera. it doesn't have to move at all. it certainly makes it difficult to get an accurate reflection that way. At least with the way it looks, it's a sizeable box that contains the player vessel. Planets/Sun are outside of it seen by a different camera, which is what you see in the video, the vessel and it's reflection probe passing through the galaxymap box, and reflect the actual Sun geometry in a black void, since there's no real skybox at all.

 

Well it is just a tiny cube actually. About 100m across. (less actually)

			_cam.transform.position = GalaxyCubeControl.Instance.transform.position;
			_cam.farClipPlane = 100.0f;
			_cam.cullingMask = 1 << 18;
			if (_cam.RenderToCubemap(_rtex, faceMask))
				result = true;

 

Edited May 10, 2016 by Starwaster

[Lilleman]

The sky is reflected on the launchpad and the runway, where the vessel spawn. It happen on a small distance, the sky stop being reflected once the probe get out of this cube. I guess this one is the "atmosphere" sky box.

I suppose it's always placed at vessel's position when a flight scene start, but after that it doesn't move (the position is probably refreshed with scaled space). If I can make it follow the vessel, it could solve the skybox problem, but I'm not sure if the game will like it.

Edited May 10, 2016 by Lilleman

[nli2work]

It's possible to manipulate the skybox orientation in Unity5; it would be better visually if the atmosphere and galaxy map cubes were replaced by the real skybox that blends between atmosphere and galaxy. Otherwise you'd have to resort to a lot of orientation matching to get different camera layers to all line up in the reflections. I don't know which one is easier... probably equally difficult.

Quote

If I can make it follow the vessel, it could solve the skybox problem, but I'm not sure if the game will like it.

I don't think there would be any issues... it doesn't follow the vessel because there was never any reason to. All it does is project the sky in the bottom layer of player camera. I think the bigger problem is the galaxy box blocks out planet's (or the sun) reflection while in orbit.

Edited May 10, 2016 by nli2work

[Mad Rocket Scientist]

I have a question, which I don't think I saw answered in this thread.  

I'm not a modder, but I'd like to try this mod out.  How do I do that?  Thanks!

[nli2work]

Just now, Mad Rocket Scientist said:

I have a question, which I don't think I saw answered in this thread.  

I'm not a modder, but I'd like to try this mod out.  How do I do that?  Thanks!

just download and place in Gamedata; Lilleman has made masks for all the stock parts.

[Mad Rocket Scientist]

Just now, nli2work said:

just download and place in Gamedata; Lilleman has made masks for all the stock parts.

I tried that, but I'm not seeing anything.  However, I suspect my anti-virus.  I'll disable it and try again.

I reinstalled it, this time copying the Squad folder inside the Masks folder over the default Squad folder.

This is what I got.

I have one more idea, be right back.

[Mad Rocket Scientist]

Nope.  What info can I give you to help?  Other mods?  

[Lilleman]

I hope you've got a backup of you original Squad folder...

To install it, you just need to unzip the archive in the GameData folder, like any other mod. the masks textures should stay there, otherwise the mod won't load them. You can check if the mod is loaded correctly in the main menu (it should log some infos), and in a flight scene (the "PBR SL" icon in the toolbar).

The current masks are made to look like the vanilla game. I plan to add some tools to modify them in-game shortly, but until then you'll have to make them by hand.

[nli2work]

don't overwrite anything in Gamedata/Squad. never. You don't need to do anything other than extract PBRShaderLoader into Gamedata. 

The effects are very subtle by default. If you are expecting something super chrome shiny maybe it's best to wait till there's a final release.

 

Well dang it... the only axis you can rotate the scene skybox is Y; so that can't work for anything except in orbit maybe.

Edited May 11, 2016 by nli2work

[Mad Rocket Scientist]

20 hours ago, Lilleman said:

I hope you've got a backup of you original Squad folder...

To install it, you just need to unzip the archive in the GameData folder, like any other mod. the masks textures should stay there, otherwise the mod won't load them. You can check if the mod is loaded correctly in the main menu (it should log some infos), and in a flight scene (the "PBR SL" icon in the toolbar).

The current masks are made to look like the vanilla game. I plan to add some tools to modify them in-game shortly, but until then you'll have to make them by hand.

 

19 hours ago, nli2work said:

don't overwrite anything in Gamedata/Squad. never. You don't need to do anything other than extract PBRShaderLoader into Gamedata. 

The effects are very subtle by default. If you are expecting something super chrome shiny maybe it's best to wait till there's a final release.

 

Well dang it... the only axis you can rotate the scene skybox is Y; so that can't work for anything except in orbit maybe.

Don't worry, I backed it up first.  I think I am getting the effect.  I can't wait to see what the final release looks like!

[Lilleman]

I'm rewriting pretty much everything, to include the changes from the latest parttools release. It means this mod will be able to replace more parts shaders (like the OscarB fuel tank), but this also means the shaders will need KSPLighting.cginc to be compiled, and I can't include this file with the sources. I'll add another readme file to explain how to set up the editor folder to compile them.

I have a quick question regarding the tool I want to implement:

Where can I find some decent algorithms to convert a diffuse texture to metal/gloss/occlusion values (I can also have access to bumpmaps and emission if it's necessary)? What I have right now is a very basic function that will probably provide basic results. It's a port of what I've used for the stock parts so far: you set a range of values, contrast, brightness, then it returns a value based on the texture's grayscale.

float GetGloss(float min, float max, float4 color, float brightness, float contrast)
{
  float range = max - min;
  return ((range * pow(Grayscale(colot), contrast)) + min) * brightness;
}

Same for Metallic and Occlusion values at the moment.

 

If not algorithms, anything relevant will be appreciated.

Edited May 12, 2016 by Lilleman

[nli2work]

I don't know if you will be able to get fully accurate conversions... there's no way to guess what the material surface properties from just the Diffuse and Spec maps. High Spec doesn't necessarily mean Metallic surface; high metallic surface doesn't necessarily mean high Spec surface. 

This may help coming up ways you could get decent conversions through code. https://www.marmoset.co/toolbag/learn/pbr-conversion

Edited May 12, 2016 by nli2work

[Lilleman]

Thanks. I've read this article already, but it kinda contradict the Unity's materials charts,

Quote

Grey values can also be used for materials that partially metallic; however, these are generally quite rare

Where the charts advice is to keep this value pretty low (light-grayish).

The idea is the same, though. The code above, despite being simple, can provide this kind of results. I guess my question should be : What kind of parameters should be able for modders to use?

Edited May 12, 2016 by Lilleman

[nli2work]

16 minutes ago, Lilleman said:

What kind of parameters should be able for modders to use?

not sure what you mean... just one consistent implementation is enough, either Metal or Spec. I expect asset creators will have their source material to create the necessary masks. At most a simple conversion utility like MBM2DDS converter is enough. Nothing like Squad's Wheel stuff please.

Metalness values are consistent every where far as I know, 1 = metal; 0 = non metal. The only real point of confusion is Rough/Gloss map; that is more less solved by inverting one for the other.

Not sure if I really understand your algorithm to be honest, It looks like you'd get the same result for Metal/Gloss/Occlusion since you're just basing the return on texture's grayscale. What's the point of that?

Edited May 12, 2016 by nli2work