A nice shader for track materials

PSPS, having the extra detail contrast in the diffuse/ambient makes the surface look a lot better with Racer's light system on cars... :)





I'm not sure if the textures I have here are right or not but I'm using values from above for the diffuse (0.04 > 0.12 reflectance >> rgb gamma space as described), and also using about 150a for the worn areas and 114a for the less worn areas in the alpha map.


Given that the influence via gloss/wear is tunable, I seem to be finding that I'd want to set a gloss of at least 50a as a default value even for fresh asphalt with this detail map we are using.

And as soon as I get near 150a I think I'm nearing the limit of how glossy a real road ever looks... maybe 175a tops.
At that point the specular is pretty tight for asphalt in my view.

So I guess it maybe makes sense to use those values as a guide to re-range the wear map influence?

Make 0a how it is at 50a currently, and make 175a how it is at 255a currently.

Then when we are authoring the wear map and it's gone smooth (no normal map influence left) it'll be smooth about as shiny as it currently is at 175a and it'll all tie together nicely?




But part of me can't help but think it still doesn't look glaring enough... My photo wasn't even late on an evening with a low sun and yet the specular dominated the appearance of the material but wasn't confined to a sharp spot and was actually quite soft and dispersed.

Maybe this is all down to the tone mapping and auto-exposure though...? Again this is where having real imagery at known exposures vs Racer exposures would be really valuable in giving us some good reference materials.
Maybe the tone mapping is just giving our 'eyes' a break and reducing the impact of the high intensity values making them look to subtle?

Just trying to figure in the dark when finding the right values for textures is not a good idea :)



I'm not sure how good Forza 4 is, but this specular for example is super powerful and whited out but it's not sharp @ 58s into the video...

Then again maybe that is wrong?

This image is pretty dark exposure but the specular is 100% dominant here and also soft
http://i179.photobucket.com/albums/w289/Fleaver/Random/ShinyRoad.jpg


Really hard to get a gauge on it but I just have a gut feeling that the gloss seems to need to go too high (and thus sharp) before specular power gets up...


Hmmm

Dave
 
Hmmm, tinkering/thinking/reading more.

IOR for asphalt is 1.635, give or take.

So the fresnel settings need tweaking too.
Code:
  fresnel
{
bias=0.058
scale=0.942
power=4
}

I've adjusted the bias, and then the scale adjusted so the bias+scale = 1

Also adjusted the power a bit to add a bit more specular.

Right now this adds quite a bit more specular with 'realistic' values so maybe things are actually ok...

It's rather sad that I'm sat here looking around on Google Earth Street View for images of asphalt at different times of day hehe, but it's quite a good reference actually :D

I'm fairly certain the exposures are fairly consistent and it's interesting to move towards a road running perpendicular to you (say approaching a cross-roads) and seeing the specular reduce in power... which brought me nicely onto the fresnel and checking the values made sense :D



I'm gonna have to build a test normal map though to make it easier to check lighting direction etc... it seems to be wrong half the time haha :D
I'm not sure if there is a bug in the shader code, Racer, my tracks UV mapping, or just my texture, but it's bugging me now :)

Also I still think the gloss thingy needs re-ranging as there is no point I'd say in going too rough or too glossy for asphalt... though there is no harm in making it have the wide range I suppose, just a bit less intuitive for authoring maybe? since this is a dedicated asphalt shader maybe it's best to optimise for it?

The main thing really I think is that the gloss influence on normal map reduction is made to happen around the point we hit the max ideal value for asphalt gloss, or maybe just a bit beyond it... :D


Feeling a bit happier now with those better fresnel values.

Cheers

Dave
 
Just noticed that reflectiveNess gets multiplied into specular twice - on line ~115 Ks is adjusted and then on line 149 the litColor multiplies the specular factor by reflectiveNess again. I deleted the second one since it's probably contributed to the wrongness of spec colour.


Anyway. reranging the shininess to go from 50a to 175a isn't a problem.
Currently, maximum shininess is 1000. 175/255 =0.69 baseCol translates to up to 750.
Minimum shininess (again looking at the top of bumpColor, where it's alpha=1) would be currently a 30. Bumping it up to 50/255 = 0.196 translates to 77.

I'd say that given the envmap/ambient treatments of gloss are basically not working anyway, may as well scrap them and start over.

So, may as well reduce the number of constants in play, and just give the 'gloss' variable a range of 0 to 1, with 0 corresponding to 75 shininess, and 1 corresponding to 750.



An interesting effect of the fresnel being applied to specular is this:
xe9rQub.jpg


In absolute terms, the low-angle less-sharp specular is brighter than the high-angle more-sharp specular. So a lot of the time, from a driver's view, the shiniest bits of the road are only the second-most polished, where specular spreads to farther angles from the sun. Could be where the idea of the groove being darker comes from.


Anyway, today's update is here.
Line 118's 75.0 constant is the minimum specular size; the maximum is 10 times that. So you could try dropping it to 50.0 if it's still too sharp, to get a max of 500.

The other constant likely to be of interest is line 116's 1.3f. Adjusting the first one lower makes the bumpColor's contribution to shininess smaller - I just found 1.3 to be a reasonable value.

Mainly this is just cleaning up the gloss & shininess variables, but it also includes your changes to ambient+diffuse based on the maps.

If you have the time, I'd also like to get your opinion on an alternative line 116:
Code:
  float gloss = min(1.0f,1.3f*(bumpColor.a-1.0f)+1.3f*baseCol.a);
This lets the low points on the bumpMap's alpha drop shininess even farther, instead of clipping it to a minimum value.


Something to keep in mind with spec, I think, is that camera fov can change the spot's size quite a bit for a flat surface, esp. with Racer running up in the 60's whereas cameras are more like 25-30. The Porsche's cams are for the most part near the lower end of that anyway so I get a fairly wide spec spot even with high shininess.
 
Hi Stereo,

I'm not sure how Ks propagates through the shader... so can't be sure it's really being multiplied by reflectiveNess again.
Ks isn't used in the litColor output, so where does it get 'into' the specular map? In lightingSun function?

I've been confused by this a bit as the shader has become more complex.

My testing in this regard has been to do what you have done, just apply it to a red or green base diffuse texture and suddenly it's obvious if the calculation is out as the specular spot gets tints of light other than what should be almost perfect white.

I've added in the odd bodge to try get the inverse base map term looking about right but I'm not sure if that is a good idea or not. Hmmm.



These names do get confusing too hehe. What was wrong with using gloss and specular throughout kg, ks, gloss, spec, etc etc... shininess and reflectiveNess inter-mixed make it really hard to read since they are replaced in other locations with gloss and stuff :D







The AO still looks incorrect. If I apply it to the output (10*ao) I see the aggregate tops darker than the areas around them. It's inverse to the logical appearance and also very low contrast.

Also isn't it costly to generate AO from normals which needs a lookup and then processing and writing to the AO float, vs just doing a texture lookup on the detail map alpha which looks very similar?

For me at least, if I just drop in the weighted mixing that I used

Code:
  Ks*=reflectiveNess*((0.25f*baseCol.a+0.75f*bumpColor.a));

Then that makes everything look ok again (to me any way hehe)


I'm not sure how right/wrong it is but if you look at the raw output it reacts nicely. The deep pitted 'fresh' aggregate is dark around the edges (so micro-occluding the specular nicely in those hard to reach areas)...
As the wear map increases then these pits start to fill with specular light but are still out-shone by the overall weight of the bumpColor.a map.

Obviously this is just picking numbers from thin air to do micro-occlusion, but I guess if it works right in the ambient/diffuse slots then it's logical that it makes sense to use it on the micro-occlusion applied to the specular power and ambient specular too?





Also just wondering if we should define these 'hardcoded' mixes and the gloss blend etc up above the normals blending line (89) so that we can use the gloss value to lerp between rough/smooth normals?

That way maybe the AO multiplication and stuff can all be combined so the AO and detail map alpha contribution to diffuse/ambient colour tinting can all be consistent with the apparent wear too.



Last thinking, maybe the lerp from normal map > mesh normals could be exponential in effect, so it's only possible to get a totally smooth looking surface at the very far end of the gloss, but we can get a fairly significant appearance of wear at mid values of gloss.

I'd have a play with that as I think it helps get things looking more right... maybe that worn down area needs to look more visually flat for the other elements like higher gloss to look appropriate?
For now with some basic changing of the lerp normal map > mesh normals function I'm getting some more convincing looking aspahlt :D



It's definitely heading the right way imo, with the AO done my way... based on your observation of the missing ingredient (micro occlusion of all elements, especially specular), this seems to be the best way to do it?


Ambient specular/envmap is still a tough one, but I'm generally happy with it for now actually.

I just want to look at that inverse function thing for how ambient reflection changes from gloss > matte...

Hmmmm, all good. Maybe we can get onto making that track soon at this stage hehe :D



asphalt6.jpg


All I've changed here is the AO influence on spec back to how I had it, changed the 75 value to 50, and upped the value in the normals blending LERP for the wear map to 3.0f:
Code:
  bumpColor=normalize(lerp(bumpColor,float4(0f,0f,1.0f,sqrt(bumpColor.a)),saturate(3.0f*baseCol.a+bumpColor.a-1.0f)));

The base map is 60 > 85 value range in rgb, alpha is 88 > 140 range.

PS, I added a bit more normal steepness to my detail map (just in layers in PS, by 25%) since I probably authored it too smooth for the new wear to be added over the top.


Here is a screenie of it with wear map at 0 alpha. No change to the diffuse map though which ideally you'd tweak too (maybe we should add some alpha influence of the wear map into the diffuse colour hehe? Maybe later :D )

asphalt7.jpg



To me this is feeling quite natural looking (17:45 TOD at start position, Auto Exposure on), and the authoring of the wear map seems intuitive and sensibly ranged.

Generally the sun specular feels about right too...

The only thing really that is feeling like it needs work for me at least is the ambientSpecular...? More dominant at certain gloss levels, less dominant, wrong colouring? Etc etc...

Dave
 
Hi Stereo,

I'm not sure how Ks propagates through the shader... so can't be sure it's really being multiplied by reflectiveNess again.
Ks isn't used in the litColor output, so where does it get 'into' the specular map? In lightingSun function?

I've been confused by this a bit as the shader has become more complex.

I'm falling asleep soon so can't try the rest of the post out... I'm fairly sure lightingSun is what does it, yeah. I tried your change to reflectiveNess, and even with only the Ks term, it visibly affected the specular colour on the red test track.

For that matter, ambientSpecular should probably have Ks or reflectiveNess multiplied in, for consistency, since it's the same mechanism as specular, I think. What's the justification on ambient specular, anyway? That upward-pointing reflections are gonna hit the general illumination, at ~fresnel strength?

Specular spot looks good at this stage... time to tweak the rest, heh.
 
Well the 1-kd line now has a *0.5 addition too, so maybe that is breaking things for you.

If you go back to my first post I'm not even sure if the 1-kd approach is the right way to go to get the specular colour right to begin with... but assuming it is then it's the power of that map that needs to balance perfectly with the diffuse so it blends seamlessly and the specular is tinted white (or the sun diffuse TOD colours actually, maybe worth setting them to white for the test track?)

I suppose what I need to do is apply the specular occlusion to the diffuse term, then do 1- (all that), so that it's an inverse of the occluded result perhaps?


Hmmm


Ambient specular is basically the specular response of a million million feint lights all over the sky dome.
They are generally tinted blue, very low power, cast a very feint shadow, and have their own discrete little specular too.

ambientSpecular does have the gloss influence via this
Code:
ambient=lerp(ambient,envColor,saturate(gloss-0.5f));

Since we are not really dealing with many individual specular but clumping the entire sky into one, the net result is what we are looking to influence via gloss.

We know (from the blog at least) that as we up gloss we get ambient colour * diffuse intensity (which makes sense from observations, a black smooth snooker ball has a black coloured reflection), and that as we go towards matte we get the ambient intensity * diffuse colour (so just flat black in this case)

Obviously we haven't implemented this fully yet, but I'm figuring the influence is incorporated via that process because that is the only way we can incorporate it. It's actually a fake way to incorporate the millions of sky lights specular effect... the end result appears to be that rule above as a way to treat the environment information to arrive at a nice looking ambient specular result.

The only thing we need to do is apply the fresnel effect I imagine.

How that then should mix with diffuse when looking straight down, and ambient etc, I have no idea haha...

I've tried reading that blog post on the ambient specular matter but most of it goes up over my head, or bits that I do get just feel like random parts against how I'd try plug them into our Racer system :)




But yes, for now the general tuning of the main colour, sun specular and stuff all feels pretty nice and definitely something I'd happily author with for our planned track idea.

Assuming we make good logically made base textures and detail textures to begin with I can't see a problem for the future if we develop the shader more, since it'll hopefully only be a tweak of the curves/levels to get things right again.



I'll go on your call next. Do you want me to basically re-create the current detail texture in double res (why not, for testing at least it might be cool) in DDS format with good mip-maps for both colour and alpha data?

I'll make them in DXT5 if that sounds good to you, the alpha gets really messed up in DXT3.

Cheers

Dave
 
Hmmm, I think right now using lerp for the ambient > ambient envmap vs gloss is what is hurting the ambient specular.

Again we don't see the envmap until high gloss values so most of the time we are just seeing the ambient term... and since this is seemingly too low generally then the effect is too subtle to do much.

Simply lerping from ambient envmap > ambient envmap (super quick fudge fix) gives the road a load more character and apparent realism again.


I'm still not sure why incident ambient (from TOD curves) seems to be so low when used for ambient specular, vs the envmap approach which is a lot brighter.

I'm gonna have a try at the thing suggested several times by now from that blog site and see what happens hehe...

I've got this feeling it might look pretty sweet.


PS, why do we define gloss values within a certain range? I get 0, no gloss at all, labertian surface. But what is the max gloss we can possibly have?
Is 1000 just arbitrary, or can we go to 10,000? Or 100,000?

Hmmm...

Dave
 
PS, why do we define gloss values within a certain range? I get 0, no gloss at all, labertian surface. But what is the max gloss we can possibly have?

Hmm. I just checked the energy conservation and there's no upper limit to what that will output a finite amount of energy, it just gets focused more and more sharply with constant energy.

The point where it'll output something brighter than the original happens around shininess=17 - of course for it to happen,everything else involved would have to be 1 - fresnel, Ks, and so on. That's assuming that the lightColor the shader gets is the brightness of the sun, anyway.

I dunno what I turned off but my Racer RC5 won't tell me how bright the screen is at the cursor. It just says 0 all the time. Sort of annoying.
 
You need auto-exposure on to get the klux readout.


As per the shininess/gloss, I'm a bit confused really at this stage... I'm just building the thing up a bit from the logic of what is already there and how you'd string together a shader in 3DS Max or UDK for example.



Watching more videos today, and looking at photos, a flip way to think about the whole thing is to ignore the entire TOD curve values and specular, and just remember that in reality things just reflect the light around them.

Assuming you have the mie sun back on and the sky dome in a HDR image, you then 'light' the scene with it.
A rough piece of ground would sample the mip map of the environment, while a shiny piece of ground would sample the original environment map direct reflection.

Obviously if you could write a basic illumination shader that used HDR for lighting then you wouldn't need any of the TOD stuff etc to light the road... you'd just use the HDR image basically.

But the obvious issue with that is shadows etc, they'd be soft and car relative and whatever else.


The road is always reflecting the sky, and on an overcast day the road surface is still packed with subtle reflections and speculars, all part of the ambient specular response, or, the sky reflections basically, through rough to smooth ones :)

Dave
 
Didn't see a performance improvement, maybe cause the test track's not a strain on the gpu. But here's a non-dynamic version of the vertex shader.
http://nmurdoch.ca/cg/asphalt1_v.cg
http://nmurdoch.ca/cg/dyn_asphalt1_v.cg (this is just a copy of the original)



You can play with the ambient-specular lerp by changing the constant on 143 - I had it at -0.5 to reduce the influence, but I'm not sure what effect you were going for. Maybe that bit should be
Code:
  #ifdef USE_CUBEMAP_MIPMAPS
    ambient=envColor;
  #endif
I think the lerp was just there because you originally mentioned that it should switch to the envMap on sharper more reflective bits. If it's fine being all envColor then no problem. I feel it's a bit blue but maybe that's down to that ambient colour vs. material colour thing that I still haven't got together in my head. And the pits seem strangely un-blue which probably contributes.
 
Hi Stereo,

I'll try these later. I've been out this morning having my car bumper replaced (some one drove into the back of me so had a new bumper sprayed up) so took the time to go take photos of tarmac. I took into the sun, perpendicular, and away from the sun on loads of surface both with horizontal and vertical polarisation filtering... the results are quite interesting actually and should be useful for thinking how much influence different components really have :D



Yes, the ambient=envColor makes the most sense initially.

It is indeed a bit blue, but my photos from earlier suggest that there is a lot of blue from the sky in road surfaces. I think the big problem here is white balance. Where is Racer's white balance set? Is that in the tone mapper?

Yes, the pits will seem un-blue, because right now we are occluding them.
But maybe the pits are not so occluded and need more blue in them. I was wondering maybe if the detail map alpha needs to be less bright and contrasty, so more dark greys and mid greys for the aggregate and then the odd sharp spot here or there.
This would soften the specular shine across more surface... but the problem I have is that as we spread it the power just seems far too low. Almost like we are conserving energy far too aggressively. Maybe the way Ruud has specified the energy conservation doesn't mix well with our way of using the gloss map (ie, maybe we are getting too much energy conserve?)


My photos are interesting any way. From my perspective the sun specular spot can still be seen at almost 90deg to the sun, where it's pretty much died away but it has a very wide effect... and it's strong too!

We can probably take a look at those and make some decisions before moving forward because it might help us decide on a few things for sure that we know really happen or don't happen.



As per what I described about ambientColor, it's all in that blog I linked to. A full ambient specular approach in a real game engine.

All it's doing is using the envColor and baseMap intensity to determine the reflection value at matte, and then as it goes glossy is goes envIntensity and baseMap colour to determine the reflection value.

So that is:

gloss = 0 >> envColor * baseMap(desaturated) = envColor >> fresnel me
gloss = max >> envColor(desaturated) * baseColor = envColor >> fresnel me

Lerp between the two...

Hmmm

Dave
 
I tracked down the source of using the ambient light for low-gloss and the envmap for highgloss, this comment

Racer doesn't currently use a cubemap for ambient light (if I understand it right, that's where this applies) - which would take care of the 'sky is darker straight up than on the horizon' ambient lighting issues too.

I don't know if Ruud or anyone wants to tackle this problem. It seems like the ambient light should be a better-blurred version of the smallest cube mipmap, basically averaging over the entire half-space that each normal vector direction implies the object is exposed to. As far as I can tell it would be suited to render-once, when TOD changes, and then being used for lighting later. Replacing it with a constant that's used for straight-down light, that then fades in effect as normals drop away seems like a pretty cheap approximation.

Since we don't have the lightmap I think the correct response is to use the envmap mipmap for all ambient light needs (both diffuse + specular) so long as the mipmaps are available and smoothed. Unfortunately the physics-based-lighting post doesn't describe ambient diffuse in detail so I'm gonna try to find some relevant citations and figure out what factors control it.
 
Yeah I think it would be nice to have HDR cube maps... we currently have LDR ones but there is no reason why we can't have Racer render HDR ones and then blur then at TOD change. Obviously it's something Ruud would need to set up for us.

Ideally we'd have something like $carenvmap and $trackenvmap, where $carenvmap is the system we have now, and then trackenvmap is a specified on-track location that a cube-map is rendered at run-time, and updated only at track TOD change.
We can set this location somewhere open with a sensible approximation of the average lighting of the track.

We could then render it at lower res (doesn't need to be so high I guess), and be mipped/blurred relatively cheaply since it'll only be done once, or once every few hundred frames or so with the TOD system running actively.

I suppose when a surface gets really glossy again then we have the water reflect shader (currently not working it seems) to manage that effect in those cases.




I think the two envmaps would work really well.

Right now using the car envmap isn't ideal because if you drive under trees but look at clear road ahead it looks darker... and since it's all changing as you drive around it's not very nice looking.

That is with live mapping any way.

If you want we could try use the LDR cube maps and tweak the resulting imagery and then final output value (reflect > 1) to make it appear HDR.

I suppose if we set up two spheres one using a static live envmap and the other an LDR cube map then I can tinker with values until they look about right.

Not ideal but then again it's what we have right now and also cheaper I guess vs using the mipped envmaps?



Actual game engines like UDK will use many cube maps with blurred mips. It's probably a bit excessive for us in a generally outdoors sun/sky lighting environment to need too much more, but I think one cube map for the track ambient lighting would make a massive amount of difference to realism for us... more so at each end of the day where the lighting can become more dramatic.

Dave
 
Ok, skipped a few days, but here is the latest version of asphalt1_f.cg.

Fresnel scale drops off with gloss as discussed. shininess is now in the range 2 to 2048, although the gloss variable is limited in the same way as before - the main map varies it from 50 to 500. Increasing the range of gloss values would bring the range of possible specular amounts up correspondingly.

Following tweak to shininess range, everything else using gloss now pulls it from the PBR blog post, so it should only be necessary to tweak the constants on the gloss= line to change specular response to the textures.

I felt that line 152 which cuts ambient specular based on alpha channels was reducing it too much, so I changed that mixture.

Might also be worth revisiting the way ambient specular is split between lit/shadow, I'm not sure where the constants came from. To make the shadow look right I agree there should be some going on, just not sure how much.
 
Hmmm, so shininess is now 2 to 2048? I thought it was specular power (intensity?) that had the range of 2 > 2048?

Just to be clear that is all.

We author gloss (or shininess, but best to be consistent and call it gloss all the time?) and our 0 input results in specular power 2, and our 100% input results in specular power 2048?

Or when they say specular power range in the blog do they mean gloss range 2 > 2048?

If our gloss range is from 50 > 500, does that mean we are not actually accessing the full 2 > 2048 gloss range (assuming that is what specular power is?) that is possible simply because of the way we manage the input maps and mix them together?

I'm again confused here. Just to clarify. Gloss = shininess?

Specular power = intensity of the spot of light, not how big/small it is?





I was thinking about ambient specular again.

The reason I did a weird mix was that because shadows will occlude some ambient specular, so taking some ambient specular out of the shadow areas and adding it back in to the lit areas made sense... a fudge factor basically.

I think we just need to make some observations and pick an ok value... I think I just went with about 1/3rd in lit color as a rough starting point just based on instant gut reactions to my early shaders.




As per ambient specular falloff with gloss, does it only effect the scale, and not the bias too?

I assume if that is from the blog then I'll just run with that as correct. I had assumed that a really rough material (0 gloss) would then have 0 ambient specular (and simply be lit by ambient evenly all over as current Racer materials are)...
That would require bias to also drop to 0, not just scale... Hmmmm...



I'll go through the shader and try figure out what is going on.




I still think it might be sensible for us to use a 2nd detail texture at this stage though, then we can author in the IOR greyscale map, an AO map (to multiply perfectly into the ambient/ambient specular outputs), and so on... rather than trying to build them up from our limited set of maps.

That then means the 'wear' map can be more intuitively made, and the detail gloss map can also be made more obviously perhaps?

With the free'd up shininess variable in the shader we could now possibly pass this as a scale on the wear map influence on normal smoothing? Probably not something we need in the end but it might help us more easily tweak shaders to find the right value?



Hmmm

Cheers

Dave
 
Gloss is a [0,1] range value (so it can be pulled from a texture more easily), shininess is the same as in .shd files. When they say specular power they mean shininess - the Fresnel function uses it as a power, (dot(I,N))^shininess. It also happens that the brightness of the central spot is a function of this same variable - due to the equation that's used when energy conservation is turned on. The two are linked together, so that the shininess changes both brightness and size, ending up with a constant total quantity of specular light.

I think a rough material drops off to 'bias' level of specular in all directions, since that's the minimum fresnel will return.

For me, intuitive work on the first texture would be that the diffuse colour basically matches normally exposed photos (to make photo reference easy), and then alpha is just "how worn the pavement is" from 0 (unused) to 1 (as much as possible) - and the detail map, or maps, plus the shader, give a corresponding result in-game which looks nice close up. It's basically working from this that the max of 500 shininess was determined - pavement doesn't get worn glass-smooth so painting the alpha channel shouldn't ever produce impossible asphalt.

If you want to pop a set of test spheres on the track, I can modify standard_bump to take the inputs and leave full control for the user (shininess from 2 to 2048 based on gloss, specular bias from a control map, diffuse colour from a base map, plus the normal map influence as usual) so we can see if the results are coming out right. Then we can consider which channels might be redundant.
 
I don't currently have anything to test it on so it may not work properly :)

Here is my stab at a modified standard_bump_reflect: http://nmurdoch.ca/cg/dyn_pbl_bump_reflect_f.cg
Assuming it works, you have map 0 diffuse, map 1 normals, map 2 specular albedo + gloss, map 3 envmap. As implied by the name it's using physic-based-lighting for fresnel specular responses. see here for definitions of these. specular albedo should be a grey unless it's a metal.

Map 0 and 1 aren't using alpha for anything so you could get transparency on this if you wanted just by blending it that way.

I think typical packing would be to put gloss in map 1's alpha, leave specular albedo as a constant for the material, and then only be using 2 texture maps + envmap. Then, for metallic stuff, add the third map and control specular albedo more finely.
 
Ah ok.

The relationship for conservation of specular power is clear to me, it's just the annotation and nomenclature seems to vary a bit so it's really quite hard to read.

Again, I'll just run with it for now.

If the shader is basically as per the blog, but we force the mixed detail gloss and wear map to only provide values to cover a certain range of gloss values then that makes sense for now.





So right now we can have a base asphalt freshly laid. The detail gloss map should be 0 > 255 in intensity because the base gloss is always 50, even at 0 input.
The 255 intensity should then (imo) run all the way to 500 gloss. This means our detail gloss map is authored perhaps with only low range values in it (maybe 0 > 50 for some fresh tarmac surfaces?)
Then when the wear map is overlaid it is a pure addition and simply pushes up all areas of the gloss result towards 255...

That makes sense to me, then we can author in super glossy elements even on fresh asphalt that won't intensify with more wear which for me seems quite important. We don't want authors to find they are getting too much gloss on worn areas with no way to reduce it without making their un-worn areas then look too rough by reducing gloss value in the detail map.


The only thing I'm thinking about then is how we smooth the normals. I'm sure some asphalt might go smooth looking (ie, worn down) while the gloss is still quite low, while others can gloss up more perhaps?
In those photos I took a while back it was clear some asphalt could get pretty smooth with regards to aggregates wearing flat against the tar, but not have high gloss values at that stage still.

Again maybe that is a factor we need to find but I think we need to be easily able to scale that (drop a 0...1 value in somewhere to tweak so we can find the ideal best fit setting for all aspahlt?)

I think an exponential function might be the best there so we approach totally smooth but very rarely reach it without a white value?



I guess a 2nd detail map would be quite easy here, just a one channel DDS with ambient AO for example... it might give us the detail we need in the most proper way.

It also seems common in many of the PBR materials I read about to produce micro-occlusion maps so maybe it's not just us that are having problems and feeling we need this element introducing?


Still lots of thinking but I'm generally ok with the direction this is going.



I take it the logic is to still turn off the mie sun (to avoid doubling up on energy from the envmap), and that varying mipped envmap ambient is used on the ambient specular?



Hmmm

Dave
 
I don't currently have anything to test it on so it may not work properly :)

Here is my stab at a modified standard_bump_reflect: http://nmurdoch.ca/cg/dyn_pbl_bump_reflect_f.cg
Assuming it works, you have map 0 diffuse, map 1 normals, map 2 specular albedo + gloss, map 3 envmap. As implied by the name it's using physic-based-lighting for fresnel specular responses. see here for definitions of these. specular albedo should be a grey unless it's a metal.


OK so I assume I use the specular albedo map is linear, and my authored values are 0...255 > 0...1.0, so albedo for asphalt at 0.058 or so is going to be 15rgb...?

So RGB is coloured spec albedo, and alpha of that same map is gloss. Makes sense. I suppose for dielectrics we could just shunt spec albedo into R, gloss into G and then use B for some other property, maybe an AO map etc!?


I'll try throw together a building for Exeter Road using the shader then you can see it working in practice... hopefully :D


Cheers

Dave
 
Probably best to use it linear, yeah, that's what the feeding the materials post provides as numbers so it's easier to be certain it matches up that way.

Mostly see this shader as a sanity check that the code's all responding to the variables properly, can compress it back into material constants later.
For something like a concrete wall, I'd expect
diffuse rgb: colour of the material
normal rgb: bumpmap of concrete
specular rgb: 0.04( #0a0a0a, 10 of each channel)
specular a: 0.0 (rough) to 0.7 (scraped smooth)

Whereas for copper,
diffuse rgb: black or near black - only brighter if it's dirty and nonspecular
normal rgb: aluminum texture (could be brushed metal, could just be flat, could be whatever shape it's cast into)
specular rgb: 0.955008 0.637427 0.538163 (243,163,137) - or darker if it's dirty
specular a: 0.2 (rough) to 1.0 (polished).

Since this includes all the variables as textures, you could have both in one sheet and it would come out mostly ok (might artifact a bit around the borders, since specular's brightness changed a fair amount)
 

Latest News

How long have you been simracing

  • < 1 year

    Votes: 218 14.5%
  • < 2 years

    Votes: 154 10.2%
  • < 3 years

    Votes: 149 9.9%
  • < 4 years

    Votes: 115 7.7%
  • < 5 years

    Votes: 216 14.4%
  • < 10 years

    Votes: 179 11.9%
  • < 15 years

    Votes: 118 7.9%
  • < 20 years

    Votes: 80 5.3%
  • < 25 years

    Votes: 65 4.3%
  • Ok, I am a dinosaur

    Votes: 209 13.9%
Back
Top