Some shader development I'm doing.

Discussion in 'Track Modding' started by blakboks, Sep 12, 2014.

  1. blakboks

    blakboks Registered

    Joined:
    Oct 20, 2010
    Messages:
    843
    Likes Received:
    30
    Howdy y'all,
    I just thought I'd share with you all some shader development I've been working on.

    For comparison:
    [​IMG]
    All three images use similar checkerboards to modify the specular values (with the values of the checkerboards adjusted so they'd end up with similar appearances according to the needs of the different shaders)
    [​IMG]
    The image on the left is what we currently have to use: BumpSpecMapT1, with Fresnel values set to: 0.1, 1, 5, 259.5.
    You'll notice that the specular lighting is only modulated. You can only decrease the brightness of the specular highlight with this shader, which also decreases the size of the specular highlight. Which is the exact opposite to what really happens on most of your materials.

    So, to get around this, I first created the middle shader. Which uses a 'roughness' map instead of a specular map. The roughness map actually controls the specular power instead of just multiplying by whatever the global setting is. This causes the light to be spread over a wider area of the surface as the roughness increases, but it's the same amount of light overall, so it's not as bright--which is where the traditional specular map of the 'old' style shaders (i.e. ISI's implementation) falls short. This better mimics what occurs in the real world, where 'specular power' is actually describing the roughness of the micro-surface, and most materials (other than metals) actually reflect a similar amount of light given the same micro-surface smoothness (which is actually about 2-4% of incoming light, when viewed perpendicular to the surface, and the light is also perpendicular to the surface)--which is what the Fresnel Min value actually represents. The actual Fresnel Min is set by one of the channels in the Spec Map (can't remember which at this moment--getting late :)), and is multiplied by the shader setting (so, it's recommended to set Fresnel Min to 1.0 in the shader itself) to add some last-minute tweak-ability without having to re-author textures.

    The image on the right is similar to the one in the middle, except it uses a different function (called GGX) to model the specular lighting. Unfortunately, I didn't tinker too much with the actual checkerboard values to get it to look similar to the other two. I also did a little bit to add in the ability to do both an actual Ambient Occlusion texture, and a Direct Occlusion/crevice map (which I may eventually drop, because I kind of forgot a pretty important term that needs to be put in to the shader somewhere, and I'm running out of channels without having to add an additional texture), but I didn't actually put anything of interest in this example (i.e. each of those channels is 1 (white) across the whole texture).

    Anyway, I just thought you guys would like to see what else can be done with this graphic engine with just a little bit of tinkering. I'm by no means a Graphics Engineer, and I'm just doing this stuff in my free time learning as I go (maybe an hour or two a few nights a week, and the occasional clump of hours on the weekend over the past month). I'm sure it's all quite buggy and inefficient and messy code so far, so I don't have any plans to release anything JUST yet. I also have quite a bit of work to do with the CubeMap versions that you can see in back of each main sphere. I just thought I'd share what I've been working on.
    View attachment 14244 View attachment 14243
     
  2. Some1

    Some1 Registered

    Joined:
    Aug 23, 2012
    Messages:
    176
    Likes Received:
    14
    That's an interesting topic. I have been wworking on custom shaders as well - namely the light flare shaders.

    Custom shaders are cool and all, but increase the shaders count, and we already have quite a lot of shaders (IMO too many). It would be nice if your work could be integrated into the already existing shaders thus improving all the content immediately. ... Or not. I don't know. :)
     
  3. blakboks

    blakboks Registered

    Joined:
    Oct 20, 2010
    Messages:
    843
    Likes Received:
    30
    Thanks, Some1! Looking forward to your light flare shaders. I'd played around with them only a little bit, but wasn't exactly able to get it to look how I wanted; I'll be looking forward to see what you're able to do with them!

    re: shader count---again, I'm not a graphics engineer, but I'm pretty sure there isn't really any performance down-side to having so many shaders. As I understand it, there's more or less two ways to handle shaders. You can either have an uber shader that handles the maps that are provided it automagically (and there's a few different ways to implement this), or you can have a bunch of different shaders that are authored specifically to what they'll do. Obviously, ISI decided to go with the latter method. As a result, there really isn't any way around it for us modders. About the only downside to having so many different shaders is that it can cause confusion to the artists.

    Anyway, my intention is to be able to use the GGX shader(s) on pretty much everything in the scene. It wouldn't make much sense to have two different lighting models be used in the same scene.

    As far as being able to override ISI's lighting equations: I don't think that's possible, by ISI's design; since they've only provided stubs for their lighting functions. AFAIK, there's no way to override/overload the functions. Besides, the textures would need to be re-authored to work well with these shaders (I've actually packed different maps into the R, G, and B channels of the Spec Map texture). So, if you were looking to be able to 'plug and play' and have the whole game magically look better, it wouldn't work, and would probably look a LOT worse.

    One of the downsides of these shaders (the GGX shader, specifically) is that textures would need to be authored specifically to fully utilize the shader. Which would most likely mean baking textures off of a high-poly sculpt, or using a tool such as DDO or Substance. The main advantage to the shaders is to be able to represent different surface materials within a single texture.

    Ideally, I'd love to see some sort of IBL be implemented in-game to go along with these shaders. I could do it now using pre-authored / pre-convolved environment maps, but it wouldn't look right for all times of day, and especially at night. I'd love it if ISI could implement it so we could get dynamic convolved/mipped EM's that update with the time of day. Even if we could get one that's basically just the sky dome, it'd make a huge positive difference to the look/lighting.
     
  4. Woodee

    Woodee Registered

    Joined:
    Oct 4, 2010
    Messages:
    4,002
    Likes Received:
    1,056
    bumping this for interest.
     
  5. blakboks

    blakboks Registered

    Joined:
    Oct 20, 2010
    Messages:
    843
    Likes Received:
    30
    Hah...thanks for the interest! Believe it or not, I'm still working on the shaders. It's been pretty slow-going, but I've also made some pretty significant progress since my last post. One of the biggest improvements, in my opinion, is the way I'm using Omni lights--we can actually get some pretty decent specular lighting with night scenes, now! I've also added a few different shaders that use a cubemap for ambient lighting--it's suuuuuper slow, and not very good-looking, though, due to the low number of samples (per fragment) that can actually be used before bringing the whole thing to a grinding halt.

    I'd intended to throw together some screenshots for this update, but I'm in the process of getting a new computer set up, and, unfortunately, everything is still on my old computer; which I can't access at the moment. Once I get it up and running again, I'll try to post some images.

    Thanks again for your interest!
     
  6. Woodee

    Woodee Registered

    Joined:
    Oct 4, 2010
    Messages:
    4,002
    Likes Received:
    1,056
    Thanks for the update

    Sent from my Nexus 7 using Tapatalk
     
  7. blakboks

    blakboks Registered

    Joined:
    Oct 20, 2010
    Messages:
    843
    Likes Received:
    30
    Ok, I've finally gotten around to taking some more screenshots of the shader development.

    Here's a comparison between the equivalent ISI shaders, some other shaders I tried out (using the same lighting model as ISI's shaders), and finally using a different lighting/microfacet model.

    Some things to notice from this image are how the ambient lighting is different. You'll notice how flat the ambient light is on each test sphere except the ones that actually use a cubemap. Ideally, we'd be able to use the 'GGX Bump Cubemap Spec' shader for everything, because it more accurately represents how ambient lighting actually works, but a.) due to super low sampling rates of the environment map, it looks really really bad with anything that has any sort of contrast (you can see a bunch of spots scattered all around the surface) (an improvement to the way that environment maps are created would help to fix this), and b.) again, due to how the EM's are created and having to sample multiple times, it's a much much slower shader--I have yet to test it out on an entire scene with these materials. There's another technique that I could try to improve on point a.), but I need to do a bit more research, and spend some more time on it before I'm there (apparently random number generation is very difficult on a GPU).
    [​IMG]

    This image just shows off what the ambient lighting can do for a real-world object. The glossiness on this concrete wall is probably a little high, but that's totally tune-able.
    [​IMG]

    Here's the same setup as the first image, but with night lighting. You'll notice that the GGX shaders actually have specular highlights! There's actually 10 omni lights in this scene. Due to the limitations of the engine, none of these lights are actually passed into the pixel shader directly (which is where the lighting calculations are actually done). So, I had to figure out how to get that data passed from the vertex shader into the pixel shader (turns out I had to do quite a bit of trickery due to registry limitations on how much data can be passed in the VS_OUT/PS_IN struct--based on the way they did the lighting in God of War 3). This is why you're only seeing one highlight on the spheres from this particular viewpoint. In short, all of the lights need to be aggregated to create a 'virtual light' for each vertex on the object. As you'll see below, it's possible to have multiple spec highlights on an object, but it depends on a bunch of things. It's not 'physically accurate', but it's a ton better/closer than what we have with the default shaders.

    The other thing that's quite a bit different between the ISI shaders, and the ones I'm working on is how the light attenuation is calculated. The ISI shaders take both the 'intensity' and the 'range' of the light into account, and interpolates from full 'intensity' bright at a distance of 0m, and fully dark at whatever distance the range is set to. My shaders use a more physically-based approach, in that the light falls off with the square of the distance (which is how light falloff actually works), and it's a hard cut outside the range. It's a little less artist-friendly, but is more 'correct'. Now we just need shadows on the omni lights!
    [​IMG]

    This just shows some more of the night omni lighting. You can see that I'm getting more than one spec highlight on all of these images, and they're using the roughness values that's contained in the texture. All of the tonal differences are due to the spec lighting--the diffuse is a flat grey.
    [​IMG]

    Some more night stuff. Took this screenshot to again show the spec highlights on the asphalt. Once again, have a texture that controls the roughness instead of just the specular level is really coming to play here. It allows the asphalt to have a pretty broad diffuse coverage of specular highlights in general, but also allows it to have some glints here and there that really pop. (side note: I think this idea could be taken much much further when it comes to a road surface, and would probably require a special shader to replicate how a real road interacts with the light)
    [​IMG]

    More night stuff. This one's quite a bit more subtle, but you can see some nice variation in the highlights on the surface in the lower half of the screen. Again, this is all omni lighting.
    [​IMG]

    Finally, more night stuff. Again, spec highlights on the gravel (maybe a little too glossy, IMO, though). The take-away with this image is that this is more how we'd likely see the spec highlighting on an actual full-sized track--multiple lights off in the far distance.
    [​IMG]

    View attachment 20907 View attachment 20909 View attachment 20908 View attachment 20910 View attachment 20911 View attachment 20912 View attachment 20913
     
  8. WiZPER

    WiZPER Registered

    Joined:
    Oct 5, 2010
    Messages:
    1,517
    Likes Received:
    186
    Cool stuff, hope all is not to be binned when rF2 goes DX11 in Q1 (if achieved on time)
     
  9. blakboks

    blakboks Registered

    Joined:
    Oct 20, 2010
    Messages:
    843
    Likes Received:
    30
    Yeah...assuming we are still able to write our own shaders when they switch to DX11. I'm really hopeful that DX11 will actually allow us to do more, actually.
     
  10. blakboks

    blakboks Registered

    Joined:
    Oct 20, 2010
    Messages:
    843
    Likes Received:
    30
    So, to kill some time until the DX11 build comes, I've decided to play around with some better Aerial Perspective. This is literally my first working pass. Once again, due to limitations with what we can do as modders with DX9, it's not production-ready :(. It'd be awesome to get it working with the parameters that the engine is using for the sky rendering (e.g. the amount of particulates in the air--"how thick the air is"). I haven't looked too deeply, but as far as I know, these parameters aren't available to the shaders. Also, this could be made even more performant if we had more registers to pre-calculate some values in the vertex shader and pass to the pixel shader (DX9 limitation); or we could define our own render targets (compute shader), and bind those as shader resources (modding limitation).

    We're mostly looking at the distant mountains in these images:
    AerialPerspective_wToD.jpg
     
    roby13 and jpalesi like this.
  11. jpalesi

    jpalesi Registered

    Joined:
    Sep 15, 2011
    Messages:
    366
    Likes Received:
    231
    There are quite a few shaders that could be done, and that should have been done in the base game really...

    I'm really curious about your distant mountains stuff. So far I only use the simple Google Earth import, but didn't have the chance to experiment more, a proper shader for this could be really interesting.

    Regarding the night stuff you posted earlier : do you think it is feasible to get simple shaders for buildings, with an emissive map ? With this, we could finally have pre-rendered lighting, that would look good at dawn or dusk.
     
  12. DaVeX

    DaVeX Registered

    Joined:
    Feb 7, 2015
    Messages:
    637
    Likes Received:
    701
    @blakboks nice work mate! I really hope there will be a shader rework soon or later and I hope your work can be used for this!
     
  13. blakboks

    blakboks Registered

    Joined:
    Oct 20, 2010
    Messages:
    843
    Likes Received:
    30
    The takeaway from those mountains is how they're changing color based on the distance and sun angle. Technically, it's not specific to the distant mountains, and is applied to everything that is using that shader (everything else in the scene). Importing from Google Earth is still a good way to go for getting the model in-game.

    Yes and no. Emissive textures are kind of tricky things in the world of HDR lighting. The trick is getting the exposure right in the texture. One way of doing this may be to use 16 or 32 bits per channel (half or float) texture, and encoding the lighting information directly into the texture. This, however, is expensive if you're doing an entire scene this way, and have many textures. Another way is to map the 8-bpc (0-255) over some other pre-defined range. This is imprecise, as you only have 256 steps per color. Also, it will likely be unclear to the artist what that range will be, and will require iteration to get it right, instead of being able to put values into the shader with any sort of knowledge. Finally, you could have a normal 8bpc image, and then have some sort of scalar be passed in as a shader constant that the artist can use to control the exposure of the emissive texture.

    Personally, I'd lean toward the last method. However, to the best of my knowledge, it's impossible to have custom user-defined values be passed into the shader...though it may be possible with the Emmissive value in the material editor. I'd have to look up how that's passed into the shaders. (On inspecting it in the editors, though, it appears that the user can't actually define decimal values, and are limited to 0-255 as well :/ )

    Anyway, take all of this with a grain of salt, this is just me going off the top of my head. I haven't done any research into emissive textures at all yet. I'd have to have a look at how other engines handle them. One other thing I will say about emissive textures, is that they benefit the most when it comes to bloom. Until we get decent bloom in the game, emissive textures won't have the effect that most people are looking for.

    To address the other things you mentioned, the light baking in particular: emissive textures wouldn't really help with the overall lighting in the scene. In a way you could have lighting baked into the texture, but there's so many issues with that; too many to get into right now (I haven't even had breakfast yet :) ). The gist is that it wouldn't work with any other dynamic lighting that's in the scene as well (headlights, sunlight, etc.). In theory, if there's some sort of dynamic radiosity solution (e.g. spherical harmonics / light probes), then yes, the emissive textures could improve the overall lighting, though. However, I'd expect that to be a year or two or more down the road (if ever, idk...I can't speak for S397).
     
  14. blakboks

    blakboks Registered

    Joined:
    Oct 20, 2010
    Messages:
    843
    Likes Received:
    30
    Thanks! It's been fun just to play around with this stuff, however, as it currently stands, it's not at all performant (not that it couldn't be, but as far as I know, I've more or less reached the extent of what I can do with just writing shaders...beyond this, one would have to actually get into the graphics code itself). I've got a GTX1080, and I'm barely getting usable framerates on this tiny test scene at 720p (albeit windowed) in the Viewer. :eek:

    That being said, there's things I'm doing per fragment every single frame (i.e. per pixel per object--even if another object is drawn over the top of it), that could be done only once per frame for the entire image at worst, and only once per sun/sky update (or even less frequent) at best.
     
    Last edited: Mar 12, 2017
  15. jpalesi

    jpalesi Registered

    Joined:
    Sep 15, 2011
    Messages:
    366
    Likes Received:
    231
    Thanks for the detailed answer :)
    It all looks quite complicated :p I managed to get a decent night track by making night buildings, with a white emissive color, and black texture where it's not lit. I guess I'll have to stick with this with ISI based games !
    And I'm not holding my breath waiting for anything from S397 really :confused:
     

Share This Page