A nice shader for track materials

[Mr Whippy]

I take it you are using sensible values for all the maps?

Glossiness goes on the spec map alpha, so the glass needs to be white or very near white in the alpha.


The IOR is then on the spec map rgb channel.

Metals need a colour in the IOR map appropriate for the metal being reproduced.


Note that that map is linear too, so you need to take the IOR, turn it into a perpendicular reflection factor and gamma encode it, then multiply that by 255 to get the colour you should author in gamma space, to then appear as the right value in linear space.

So glass is 1.5 or so.

(n - 1).squared / (n + 1).squared = fresnel bias

So.

0.5 sq / 1.5 sq = 0.04

Gamma that.

0.04 power (1 / 2.2) = 0.231

0.231 * 255 = 50rgb or so.



Check here to just double check the values you are using.

http://seblagarde.wordpress.com/2012/04/30/dontnod-specular-and-glossiness-chart/


Also note that as mentioned earlier, the Racer sky colour and intensity are a bit incorrect right now for a few reasons, so reflecting them with these materials will usually give you results that look a bit wrong.

You really need to have a sky that is giving out sensible realistic values to be reflected and to light materials for things made with these materials to look 'right'

I've made a basic brick house here with reflective glass windows, normal mapped plastic door frames and window frames, tile roof with normals etc etc all one on material and each part looks 'ok'
It was very rough and quick but the shader works correctly.


Hopefully Stereo will post up his utils.cg file with the soft envmap feature, and then add that soft envmap entry to the PBL. I've added it here but I mess too much with my shaders so I'm not sure what you might be getting haha


So far though your building looks good to me. It probably is more a case of lighting and environment than the building you have made!


I'll try post up one of my new calibrated lighting scenes tonight then you can use it to develop your PBL materials in!

It's still not perfect of course, because of the whole way Racer deals with the sun/specular etc, but it's better than nothing for now

Dave

 

[Mr Whippy]

Uh this gamma stuff drives me around the bend sometimes.

The look up table for IOR doesn't really NEED to be linear... but since gamma encoding actually squashed blacks and that is the place where we have a lot of variance (0.03 > 0.06 values seem predominant for many materials), then using linear seems prudent as it give us an RGB range around 40 > 70 or in linear rather than about 10-15 in gamma... so we can author with more variance and accuracy.

Also note that the gloss map then looks different in linear too. A 50% intensity in PS (128 rgb) actually becomes 128/255 pwr 1/2.2 = 0.73 ~ 180 RGB once it gets into Racer... so about 73% glossy vs the 50% we thought we had authored.


Maybe for the gloss map, for being more intuitive, you'd author it in 16bit per channel PSD and pretend it's linear, but then run an exposure.gamma adjustment of 0.4545 *before* copying it to the final texture, that way when it's loaded in Racer it'll look how you authored it in PS.

Note the ideal is to apply the gamma encoding in 16bit per channel space, so you encode it how you want it to look in linear space, then when it's turned to 8bit you might get banding or whatever else but once it's back in linear space it should retain the ideal appearance that it did in 16bit per channel depth.


It still all hurts my brain a bit haha, you can see why game studios like DONTNOD create reference sheets for their artists that just remind them how values should look and be entered etc... that way the technical guys just check it all off and then let the artists go wild and not need to worry

Dave

 

[Mr Whippy]

Yeah, that makes more sense now.

Using linear or gamma space is really up to the author but it seems DONTNOD use a gamma space IOR map, but not sure on the gloss map, that might look linear from the guide they have (linked to above)

I think using gamma space is a good idea as really the real values are irrelevant as long as you know what RGB colour to use to represent certain materials.
The gloss map wouldn't be linear using gamma though.

I bet there is a way to hard code the alpha channel to come in as linear, so 128 RGB is 50% glossy, even though you haven't set mode=linear for the shader.


So gamma for IOR makes sense because most IOR values are in the low end range (except the odd metals but)
Linear for gloss makes sense because it's just intuitive that way.


If I get chance one evening this week I'll try make a building for the Exeter Road course with a nice texture set so we can all gasp at how amazing it looks


Just want to throw an occlusion map into the normals alpha channel too I think


Dave

 

[Stereo]

Heh, I was thinking about a demonstrator vehicle to show off the shader... Dunno if I should stick another project on my plate.

I suppose making it all purpose by adding occlusion in that unused channel is a good idea. Then you have layer0 rgb = diffuse, layer0 a = transparency (optional), layer1 rgb = normal, layer1 a = occlusion, layer2 rgb = IOR, layer2 a = gloss?

Occlusion would obviously affect ambient diffuse; should it also do specular?

 

[Mr Whippy]

I'm not sure if it should do specular... Maybe halve its power on spec/diffuse, full power on ambient stuff?

Technically only ambient should be effected but maybe some influence on diff/spec would be nice.

Transparency on base alpha sounds ok but does it make life hard wrt energy conserve etc?

Hmmm

Dave

 

[Stereo]

I'm mostly thinking of transparency for texture-keyed cutouts like a chain link fence. For a transparent material it's probably best to use a proper glass shader that does the right thing with fresnel affecting transmittance and stuff.

 

[Mr Whippy]

Ah yeah that makes sense to me

Can just do drains and decals etc with that version then.

I just need some spare time to work on Exeter Road now hehe. Moving house at the moment so not much time for anything on evening and weekend.


Gonna have a try at making a generic blurred ldr cube track envmap thing to match the softer reflecting maps, just to see if we can get an ok look and any fps boost.
Hoping Ruud can at least add DDS support so we can blur the MIPS which will help a bit.

PS did you have any thoughts on rendering the mie sun in the screen shader so we can still use it but only as an end effect not in envmaps etc?

Dave

 

[Stereo]

Couldn't find any reasonable ways to accomplish that unfortunately. Not a lot of information gets passed to the fullscreen shaders aside from the HDR colour of the pixel and the coordinates onscreen, so there aren't really avenues to pass the sun spot info along.

Getting Ruud to update the lens flare to (1) follow the sun's position accurately and (2) multiply in the sun color, seems like the best option to me.

 

[Mr Whippy]

Hmmm, might be a while waiting for that change/fix.

I'd say if Ruud was gonna fix that side of things, he may as well fix the entire sky system too since on testing it does seem broken or just not good enough to do the job it's tasked with.

Using a slower rendering imposter style sky would seem a better idea to me.


I'm easy with the flare or mie sun really, but there needs to be a way to just have the mie sun not in the envmaps etc

Though it'd make sense to have the flare working right too, then we can figure out which is more flexible. I'm guessing since most games I see use a flare system (decal) rather than a mie type sun then that is the way to go!

Dave

 

[boomer541]

Many long years ago the skybox/sphere size had no relation to the track size. A flag value made it appear far away and it worked quite well. The sun was and still is a problem.

Imho the sun should be a sepaarate object that can be excluded from the environment maps as Mr Wippy said, but I don't like the flare if it is to make the sun like the headlight flares.

The location of the sun is really a long distance away but it appears that the x,y,z location in the speacial.ini file doen't matter any more. Just try 0,0,0 for the location and see. The location doesn't change!!!

Another thing for ruud to fix, skies!

 

[Mr Whippy]

Things tend to line up ok when you are looking from the origin towards the sun, or any point along the track origin > sun vector.

If you are offset to it then the specular result (ie, line of specular across the ground at sunrise) seems offset vs the sun rendering in the sky.

I think this is because the mie sun stays still pasted to the far plane on the sky dome, while the specular moves with the car and is car relative.
OR, it's vice versa, so one or the other is wrong.

And it's quite noticeable even on smaller tracks... say 3km away from the sun > origin vector in a perpendicular direction and you can see the offset at sunset or sunrise, 6km and it's getting to be a long way out.


The system just needs tidying up, like a lot of them. These bugs only persist because no one tends to make sunset tracks for example... so it's never really noticed.

But I agree it's all stuff to fix because there is no point in having the TOD system at all unless you can do a TOD transition really.

A bad TOD system is worse than a good fixed TOD system. For TOD to work well it needs to be as good as a fixed sky AND allow time transitions, otherwise users will just go for static TOD any way (as I'm sure almost all content creators still do any way)


But the fixes and problems all seem well documented now so it just needs Ruud to want to fix it and he could I guess. I already emailed him a big list of stuff on how he could make it better so maybe if he gets chance he'll take a look

Dave

 

[Mr Whippy]

Well I've been tinkering around with this again tonight, trying to find ways to make it cheaper (so no envmap cube map mips etc), and more consistent for authoring and getting what feel like obvious results.

Midday lighting:

Late afternoon lighting:

Currently it probably needs more tinkering but it stands like this:

layer0 rgb = colour base
layer0 alpha = wear map impacting normal influence and gloss map base

layer1 rgb = normals detail map
layer1 alpha = gloss/ao/detail map combo


By tinkering around a lot I think I've found a good blend of how the maps are mixed in the shader to get nice ranges of possible outcomes.

In this case the asphalt track is 7m wide or so, and the base texture is 256px wide, so about 3cm of detail per pixel in the base maps.

The detail map is 2048x2048px and spans about 6m or so before repeating, so about 3-4px per cm for details.


The nice part is that in this new test track the whole road is one texture (unwrapped into a few strips on a square texture sheet), and is just 6mb in size... so every single 3cm squared on road can have unique colour and gloss and wear properties.

The detail map is 16mb in memory.


So for about 1km of road you can probably use about 6mb + 16mb of texture memory and get completely unique asphalt as you drive along each part.

Or given some creative work with generally repeating chunks and then detail chunks that blend across you could cover a road like Polish Roads with maybe only 50meg and get some really great details.
Since you might want to split your road up a few times any way, and the cost being so relatively low, you could easily add a few variants of the detail base map for different asphalts too (still need to make those I guess)... but in the end the visual look 99% of the time is driving along, not doing asphalt visual analysis hehe.


Obviously this technique then needs road decals for painted lines etc so that adds costs back.

I think for a race track you might be better to use 512px wide due to the width of race tracks, but you could still cover a 5km race course with 60meg of textures with unique details everywhere!
Pit entry/exit wear areas, per-corner wear lines, repair patches, different shades of asphalt etc etc...


Still playing around with it but it's feeling pretty nice now.

FPS are much higher vs the envmap one... and in certain conditions it doesn't look as good... but in many cases it looks better because that pesky sun spot isn't reflecting in the envmap AND via specular too... so the results are more accurate and realistic.

Also it feels easier to get a result you are happy with... but Stereo had best check it to make sure it's all making good sense I guess hehe.



I'll try refine what I've got and re-upload it all then we can have a play with it again!

Cheers

Dave

 

[Stereo]

Looks pretty nice now, being able to have detail combined with the overall uniqueness of every stretch of road is nice. Tiling textures means compromises - you can't have any stand-out features or it shows up every 7m, so the interesting parts of the texture get left out. Even just the larger-scale variations in colour and shine add a lot to the realism - actual pavement's not just grey, and the groove isn't a consistent patch, it depends on where the lanes go etc.

The tar patch-lines are probably better off as decals, looks a bit weird using the detail bumpmap around the edges of them.

Have been looking at the pavement round here - one thing that struck me once I was watching for it is how much more polished the groove gets on busy roads vs. side streets. The lanes tend to be more consistent (no parked cars to go around) and of course it just sees more traffic. The amount visible in the screenshots would be pretty heavy traffic - side streets are more subtle. I should take my camera out around sunset and get some pictures...

Not sure the best way to go about it but it'd be nice to have some color at the detail map level. Maybe just desaturating the non-gloss parts - tar is black/grey but the aggregate varies in colour, and is close to that 3cm scale, so you could put some more colour in the main map and still have grey in between the rocks if it selectively desaturated.

Anyway, presumably asphalt varies geographically so it's a matter of getting pictures of the effect you want and matching each channel to it. If a road features lots of concrete, a different sort of detail map could be put together for that, since the surface is different.

 

[Mr Whippy]

Hi Stereo,

Ultimately the earlier shader is good but I just found it too heavy and a bit hard to get the results I wanted somehow. I think it was the blending balances between the maps and how internally the ambient occulsion and so on were all mixed out to create the final maps.
I'd certainly use it for a smaller course where I want to add oodles of details or up-close quality. But for something like Exeter Roads or other tracks, to start with at least, I think something to lay down the basic building blocks makes sense.
Given the macro diffuse/wear can be authored in and UV mapped but don't really need to change much between the shaders is a good thing. It means all the magic comes out in the shader logic and detail maps.



A few changes to this new tweak were equalising the impact on gloss with wear, also on the normals with wear. Perhaps it's still not perfect but generally it seems ok here.
Also the world coordinate mapping wasn't working right. It was like the UV orientation of the actual mapping was turning the normals or something (hence us having variable normals and flipping channels it seemed)... so hjere I took the logic Ruud used for the blend maps using the tcW and then loading the tex info via those coords for the detail map.

Pavement is indeed highly variable. You see years of wear, patches, then wear, then patches over that.

Generally road can seem quite generic and repeating but there is always some detail there, like a slight curve bringing the worn line towards the middle etc. It all adds up I guess.
Not sure how you'd author it really easily though. I guess Mari or a tool like that might be nice if you had it but in the end it's a planar surface and if you manage the task well it should be fairly ok to work on.

It'd be great to try on a full circuit with the wear lines for each corner and other details added in, like changes of asphalt from one type to another etc.

//
// Dynamic model, bump+reflection
// In world space (more like the other shaders, and gives a chance to modify reflection vectors)
// RvG, 19-11-2010
//

#include "../../../renderer/shaders/atmosphere.cg"
#include "../../../renderer/shaders/lighting.cg"
#include "../../../renderer/shaders/fresnel.cg"
#include "../../../renderer/shaders/shadowmapping.cg"
#include "../../../renderer/common/utils.cg"

// Vertex to pixel shader structure
struct v2p
{
  float  extinction    : COLOR;
  float2 tc0            : TEXCOORD0;
  float3 Direction      : TEXCOORD1;
  float4 RayleighColor  : TEXCOORD2;
  float4 MieColor      : TEXCOORD3;
  float4 Position      : TEXCOORD4;    // For fragment shader
  float3 normal        : TEXCOORD5;
  // Fresnel in pixel shader
  float3 I              : TEXCOORD6;
  //float  fresnel        : TEXCOORD6;
  //float3 R              : TEXCOORD7;    // Reflection vector

  float4 tangent        : TEXCOORD7;
};

void main(
  // In
  in v2p IN,

  // Out
  out float4 out0 : COLOR0,
#ifdef CSM_MRT
  out float4 out1 : COLOR1,
#endif

  // Constants
  uniform sampler2D  baseMap  : TEXUNIT0,
  uniform sampler2D  normalMap : TEXUNIT1,
  uniform samplerCUBE envMap    : TEXUNIT2,
  uniform float3    lightDirection,
  uniform float3    lightColor,
  uniform float3    lightAmbient,
  uniform float3    ambientSpecular,
  uniform float3    eyePosW,
  uniform float    atmosRayleigh,
  uniform float    atmosMie,
  uniform float3    Ke,
  uniform float3    Ka,
  uniform float3    Kd,
  uniform float3    Ks,
  uniform float    Kr,
  uniform float    shininess,
  uniform float    far,
#ifdef USE_CUBEMAP_MIPMAPS
  uniform float    mipmap,        // Mipmap level of reflection map (blurry if >0)
#endif
  uniform float    sunny,
  uniform float    scale,
  uniform float    exposure,
#ifdef CSM
    uniform sampler2D    shadowArray  : TEXUNIT7,
  uniform float4x4    smTexMatArray[SM_MAX_SPLITS],
  uniform float smSplits,
#endif
  uniform float    fresnelBias,
  uniform float    fresnelScale,
  uniform float    fresnelPower
)
{
  float3 skyColor;

  // Use world planar mapping for the texture
  float2 tcW=float2(IN.Position.x,IN.Position.z)*scale;

  // Get texture map info
  float4 baseCol=tex2D(baseMap,IN.tc0);
  float4 bumpColor=tex2D(normalMap,tcW);

  // Texture space axes
  float4 tangent=IN.tangent;
  float3 N=normalize(IN.normal);
  float3 binormal=cross(tangent.xyz,N)*tangent.w;

  // Expand normal
  bumpColor.xyz=UnpackNormal(bumpColor.xyz);
  // Mix to 'flat and shiny' based on the interaction of the two values
  bumpColor=normalize(lerp(bumpColor,float4(0f,0f,1.0f,sqrt(bumpColor.a)),saturate(2.0f*baseCol.a+bumpColor.a-1.0f)));
  float ao = dot(bumpColor.xyz,float3(0f,0f,1.0f));
  // Calculate new normal in world space
  float3 bumpNormal=N+(bumpColor.x*tangent+bumpColor.y*binormal);
  N=normalize(bumpNormal);

  // Reflection vector
  float3 R=reflect(IN.I,N);

#ifdef CSM
  // Output shadowing
  float lit = GetShadowFactor(IN.Position, IN.normal,shadowArray, smTexMatArray, smSplits, lightDirection)*sunny;
#else
  const float lit=sunny;
#endif

    //lightAmbient = texCUBElod_soft(envMap,float4(R,12.0f));

  // Get sky gradient color
  skyColor.rgb=GetSkyColor(lightDirection,IN.Direction,IN.RayleighColor,IN.MieColor,atmosRayleigh,atmosMie,lightColor,lightAmbient);


//baseCol=float4(0.5,0,0,0);

  // Specular map
  float3 reflectiveNess=1-(baseCol.rgb);
  Ks*=reflectiveNess*(saturate(baseCol.a+bumpColor.a));
  float gloss = saturate(2.0f*baseCol.a+bumpColor.a-1.0f);
  shininess=50.0f*pow(10f,gloss);

  // only load an envMap if we have soft mipmaps
  // note: the 7.5f corresponds to shininess and really should depend on it.
#ifdef USE_CUBEMAP_MIPMAPS
  //float3 envColor=texCUBElod_soft(envMap,float4(R,10.0f-8.0f*gloss));
#endif


  // Lighting
  float3 ambient,diffuse,specular;
  LightingSun(Ke,Ka,Kd,Ks,shininess,lightDirection,lightColor,lightAmbient,IN.Position,N,eyePosW,
    ambient,diffuse,specular);

  //define fresnel
  float fresnel=Fresnel(fresnelBias,fresnelScale,fresnelPower,normalize(IN.I),normalize(N));

  // fresnel on specular, yay!
  specular=FresnelMix(0,specular,Kr,fresnel);

  // ambient specular options
  // really the cubemap mipmap is a more accurate representation of the 'ambient' light.
  #ifdef USE_CUBEMAP_MIPMAPS
    // the higher the gloss, the more it should use the reflective color.
    //ambient=lerp(lightAmbient,envColor,gloss);
    ambient=lightAmbient;
  #endif
  ambientSpecular=FresnelMix(0,(ambient*(saturate(baseCol.a+bumpColor.a))),Kr,fresnel);
  //ambientSpecular=0;

  float3 litColor=(baseCol*(0.5f+0.5*bumpColor.a))*(diffuse)+specular+(ambientSpecular*0.3183);
  float3 shadowColor=((baseCol*(0.5f+0.5*bumpColor.a))*(ambient+Ke))+ambientSpecular*0.1061;



#ifdef CSM_MRT
  // Mix sky with texture color based on atmospheric influence
  out0.rgb=lerp(skyColor,shadowColor,IN.extinction);
  //outShadow.rgb=lerp(skyColor,litColor,IN.extinction);
  out1.rgb=litColor*IN.extinction;
  out1.a=lit;

  // Blending
  out0.a=baseCol.a;
#else
  // Mix sky with texture color based on atmospheric influence
  float3 finalColor=lerp(skyColor,shadowColor+litColor*lit,IN.extinction);
  // Need to clamp output - my nVidia GTX285 only handles colors upto 255, then makes them +Inf!
  finalColor=min(finalColor,255);
  //out0.rgb=saturate(2.0f*baseCol.a+bumpColor.a-1.0f);
  //out0.rgb=saturate(bumpColor.a+baseCol.a);
  //out0.rgb=1.0f*((0.25f*baseCol.a+0.75f*bumpColor.a));


  out0.rgb=finalColor;
  // Blending
  out0.a=baseCol.a;

#endif
}

I'm not sure on tar lines etc. I guess it depends if you can get the look you want with the base textures or not. If you can't then use decals.

The truth is we can go really far with details but it's also nice to have a shader that is fairly fast and can do the main elements pretty easily.

In an ideal world you'd have a diffuse/wear and macro normal map, and then the same for the detail set with a colour map and a normal map... so less internal calculations of the final look and just have it directly looking up. But it'd be double the memory or more and I'm not sure it'd look better except for super-close screenies


As for colours, yeah I guess we can just author more into the base map, layer up dirt, other patches etc, and just bring a nice subtle patina of life to the material.
In this case the detail map is just rgb for normals so there isn't much you can add wrt colouring unless you use another full rgb map.
I suppose that might then leave another alpha channel free for decent AO, so the normal base can be gloss impact and rgb base can be ambient (and diffuse?) shading influence.

But it does suddenly double the detail element from 16mb to 32mb of memory... it's probably worth it though I guess... but only for the up-close analytical issues where individual road aggregates become visible and we start to see it's not all that realistic.

The biggest issue here is that of texture sizes. To get really nice aggregate up close the normal map density gets quite high and so the texture either repeats more often or gets really big... both are not ideal.

So in this case I've gone with maybe 8m x 8m for the detail map on 2048px, rather than 4m x 4m which offers really nice details up close.


But the world of graphics progresses, so having a system that can be up-res'd and look better makes a lot of sense. In a few more years we'll all be running 4gb GPU's and whatever else so 100meg of memory just for asphalt will seem very reasonable hehe!

Maybe a two layer detail approach is the way to go to save having so much maths operating on the shaders to build intermediate look up tables for rendering.

A dedicated AO that is tied to the wear map (so when the normals disappear the AO is gone at that location too as it's now smooth), and then the same with a dedicated gloss map... that way all the details are worn in a tied together sense, but can have base default starting points where they need to be before getting worn.

Also then the straight diffuse detail map can contain enough detail and interest and some subtle shading so that it looks great even when fully worn to a mirror (ie, bluey aggregate with darker less colourful surrounding tar)

Hmmmm

Dave

 

[Stereo]

In an ideal world you'd have a diffuse/wear and macro normal map, and then the same for the detail set with a colour map and a normal map... so less internal calculations of the final look and just have it directly looking up. But it'd be double the memory or more and I'm not sure it'd look better except for super-close screenies


As for colours, yeah I guess we can just author more into the base map, layer up dirt, other patches etc, and just bring a nice subtle patina of life to the material.
In this case the detail map is just rgb for normals so there isn't much you can add wrt colouring unless you use another full rgb map.
I suppose that might then leave another alpha channel free for decent AO, so the normal base can be gloss impact and rgb base can be ambient (and diffuse?) shading influence.

But it does suddenly double the detail element from 16mb to 32mb of memory... it's probably worth it though I guess... but only for the up-close analytical issues where individual road aggregates become visible and we start to see it's not all that realistic.

The biggest issue here is that of texture sizes. To get really nice aggregate up close the normal map density gets quite high and so the texture either repeats more often or gets really big... both are not ideal.

So in this case I've gone with maybe 8m x 8m for the detail map on 2048px, rather than 4m x 4m which offers really nice details up close.

It's also easy enough to generate half (or even quarter) size textures and drop in a 'light' version of the track shader for low-memory systems. Or even a variety of options (one large + one small, two small, one small + one very small), if the alpha layers are picked so that downsizing one of the two gets the less important quality loss.

 

[Mr Whippy]

Yeah I was just out driving along a mix of roads and there were patches/details all over the place. Certainly you'd want to use this technique for an accurate road like that.

I was also thinking about more controls. Ie, the detail map is quite limited because if we smooth out the detail we also make it more shiny, but some surfaces might be quite smooth but more matte.

Also the scales. I was walking over a car park and there were some fine aggregates and also some very large.

So maybe another macro texture rgba that does

red=scale
green=smoothness (normal impact only)
blue=smoothness (gloss impact)

Hmmm, actually maybe we could then drop alpha from these two textures.


But then the details are still just a normal map and a contrast map (alpha)...

Hmmm, so perhaps a lower res colour map for the details (to keep normals higher res)


Just takes time to try all these ideas. But again I guess the beauty of the system is that if you upgrade the techniques later the UV mapping and original textures are all there ready to work from.
Ie, we can add a colour map to the detail map, or add a second control map to the macro details and shift maps around etc.

In practice a well laid out UV for the roads with repeating blocks for low detail sections and then specific bits blocked out where there are details is pretty much applicable to any technique we might develop I suppose. Higher res, lower res, different res for the different blocks etc.

Hmmm

Dave

 

[camsinny]

Damn that's looking good Dave.
You should update Forest Club (is that the name of the track? I can't remember now) - I do remember that it had changing road surfaces and it's one of my favourite tracks to drive on.

For a test anyway.

 

[Mr Whippy]

Hi Cam,

Yeah, funnily enough I was doing some laps on there last night with new sky and shaders added etc.

It's a great track, it certainly does deserve an upgrade and perhaps a few new additions to really finish it off.

I'm sorely tempted when I get the time as it'd require the least input to get the best final result I think.

The only thing that I'd really want to change in the mesh work is the trees which look a bit iffy these days, and add some grass scatter and some variance so the grass really comes alive (have mown sections, then long ish grass sections that look rougher etc)

Hmmm

Dave

 

[Mr Whippy]

As per this shader, after standing around a lot looking at asphalt again (yay I'm so fun haha), I deffo think it's worth having:

layer0 rgb = macro - diffuse colour
layer1 rgb = macro - red gloss, green wear, blue scale (linear)

layer2 rgb = detail - normals (linear)
layer2 a = detail - AO (multiplied into above diffuse and gloss maps with wear etc) (linear)


This seems to give us a really nice set of controls to do any asphalt really. From crumbly coarse aggregates to smooth but fairly low gloss freshly laid asphalt with very fine aggregate.


There is more to author of course, but assuming we get the balance of the AO influence on the different elements nicely balanced then it's still going to be much easier to author most textures.

Hmmm


Even if you think you might be making mostly repeating textures, the fact you can just line them all up side by side on a 2048x2048 sheet, you can get 256 wide chunks x 2048, so repetition is low, and you can STILL get 8 varieties of tarmac that can look completely different to each other with oodles of character in them... all in ONE pass

Dave

 

[Mr Whippy]

Hmmmm.

Thinking more about these.

I guess a nice place to go would be to have a more generic shader for track materials that generally don't need a huge amount of control. Say concrete walls, grass, kerbs, sand etc?
You could also dump the whole need for the high end gloss via envmap/cube map/mipping stuff, just use the ambient value with fresnel on ambient specular and on main specular.

layer0
rgb diffuse, a AO/specular occlusion

layer1
rgb normals, a gloss

Then have an optional version with detail, where the 2nd layer can be mapped in world coords.


Then we can have the asphalt shader for the roads/tarmac etc.

We have the full on PBL shader for props etc which we want really nice details on (probably ideal to have a high gloss version (with envmap enabled), and then a low-gloss version with the ambient specular using ambient colour only...


I guess there might be space for a version that is diffuse and alpha for specular, and then second layer can be IOR and gloss... good for smoother stuff at a distance that can all sit on a big atlas?


Just thinking to upgrade a track these shaders should cover everything quite nicely.


If I get the time I'll try modularise the vert shader and a new fragment shader that can kinda incorporate the needed elements easily... then we can easily throw together realistic rendering shaders more easily for different needs.

Hmmm

Dave