The shader thread?

[Mr Whippy]

I'm messing with shaders a bit right now.

Right now I am looking specifically at adding control for specular to the existing reflect shader... on Deyan's Murcielago the unified wheel/tyre texturing poses some problems.

I have to control reflection strength with an alpha map, so use the old trick of adding a syntax in the reflection shader so if we define reflection = -1, the baseCol.a is used to control reflection strength.

ambientColor=FresnelMix(ambientColor,envColor.rgb,(Kr>0?Kr:-Kr*baseCol.a),fresnel);


The problem now is that I have no spare texture slot for specular/shininess control.

So I have added this little fragment of code (from the bump speca shader)

Ks=baseCol*Ks;

This now allows the colouring of the outside of the tyre in the diffuse (rgb) channels, to do some work.



However, because the tyre is still dark in the diffuse texture (near black as it is a tyre), it doesn't have much effect on it's own.

I need to somehow increase the brightness of the texture so Racer pumps up the specular we see.

So I added a *5 multiplier to the Ks as you can see in the image attached.

Now what I don't understand is why the two images look different.

First case:
Ks in car.shd is 8, while Ks = baseCol * Ks * 5 essentially gives us Ks = baseCol * 40

Second case:
Ks in car.shd is 40, while Ks = baseCol * Ks essentially gives us Ks = baseCol * 40


Now, I don't get why they look different. Ks is meant to control the size of the specular too, but in either case they both calculate out to a peak shininess of 40, because the baseCol lookup isn't changing.
The specular settings remain the same.

It appears that multiplying by 5 in the shader means the specular level is pumped up 5x, while the shininess (size of the specular) is retained at 8 in the car.shd...

That is the effect I wanted to achieve, pumping up the actual output of the specular blob, while keeping it soft at a value of 8, but it seems un-intuitive/wrong because the value that really needs bumping up is the specular value, not shininess? (though the specular being multiplied by 5x (2.5 2.5 2.5) looked awful)

Am I missing something obvious here?




Ideally I'd like to control reflection amount, specular AND shininess using one shader here...

Probably using rgb.a for diffuse.reflection strength, and then another 3 channel texture for spec/shine and leaving another slot free for something else (perhaps transparrency?)

Specular/shininess maps add so much to these kinds of materials, so it is a shame that they haven't really been considered in the default shaders very much. I think they should almost be defaults in all materials that err away from being generally reflective (ie, using the envmap)


Bodging in the code I have for the Lambo works quite nicely in this case, but it's obviously not ideal to use the diffuse channel to control specular in this way.



Hmmmm

Dave

 

[Ruud]

Ruud, I noticed that Racer detects 32 pipelines on my video card but only uses 8, have you considered some sort of system scaling to allow for more pipelines if the card supports it?

That's just texture units. More than 8 units is not supported for ATI (by ATI it seems) and materials with >8 textures seem a bit excessive currently. So it's not really pipelines, I think there's around 240 pipelines (cores) on cards these days btw, although there's always a bit of magic so you never really know.

 

[Alex Forbin]

That's just texture units. More than 8 units is not supported for ATI (by ATI it seems) and materials with >8 textures seem a bit excessive currently. So it's not really pipelines, I think there's around 240 pipelines (cores) on cards these days btw, although there's always a bit of magic so you never really know.

I can't imagine needing more than 8 textures for any material. Thanks for the reply.

Alex Forbin

 

[Mr Whippy]

1
diffuse rgb
transparrency a

2
ambient rgb

3
reflection fresnel params? rgb
reflection amount a

4
specular rgb
shininess a

5
normals rgb


Yep, finding it tough to need EIGHT or more for a real time sim at least

Dave

 

[gtpdzbiz]

Hmmm...eight textures for a material??...that's insane...many of them can be group together to reduce the precious texture bandwidth though.

Anyway, here's the alpha version of the dynamic sky:

It takes advantage of racer's atmospheric scattering system so the colors are pretty good specially at dawn/dusk. And it's fully animated so you can watch the cloud scrolling across the sky with different shapes.

material:

vf_cloud
{
vertex_shader
{
file=clouds_v.cg

}
fragment_shader
{
file=clouds_f.cg

}
}


shader_cloud~vf_cloud
{

sky=1
cull=none

casr_shadow=0

layer0
{
map=cloud_normal5.dds

depthwrite=0
blendfunc=blend

}

}



It use a cloud dome so you got to modify geometry.ini too.

download:http://www.mediafire.com/?b4ma5hjse26mogb

 

[Mr Whippy]

Sweet, will try out later

So, what can it do, and what doesn't it do?



Dave

 

[gtpdzbiz]

It can generate dynamic clouds, with scrolling and dynamic shape, the cloud color is adjusted with atmospheric scattering (may need some tweaking though). And it can actually block the sun

It can't however...generate shadow, or alter the sun diffuse/ambient

 

[Mr Whippy]

Sounds good.

So when it does block the sun, we lose the sharp reflection in the car body, but still retain the diffuse illumination and the shadow because of that.

Doesn't sound so bad as a start!

Certainly nice to get dynamic clouds too, since texture based ones that are nice and sharp seem to require a great deal of texture detail (ie, huge textures) to look good!

That said, procedural stuff isn't always ideal, but I think it's probably the direction such things will go in, especially for such dynamic things as clouds.

Dave

 

[gtpdzbiz]

It's some how a little bit procedural, cuz it tiled a noise texture 4 times to generate random clouds, which doesn't require huge textures I think. But if you are aiming for ultra realistic, I would still suggests using a highres Hdr sky.

Cloud shadow is another story...

 

[Mr Whippy]

Does the sky texture need to be HDR, since Racer generates everything but the clouds now (ie, sky texture is just cloud colour (rgb) and cloud alpha (a))...?

I think it would be cool to have cloud normals in rgb, and alpha for the clouds in the alpha channel, and then have a shader colour them (like yours above), and also light them based on normals... Ruud suggested something like that eventually, but even right now your method above tied into the current sky shaders would be better than anything. That way we would get clouds lighting properly and nicely.


Hmmm

 

[gtpdzbiz]

Lol...That's exactly what my shader do...rgb for normal and a for alpha... Then
Caculate cloud color with atmospheric scattering and mix them using normal map, so the color are all hdr and the shader can handle that by itself. The texture is just a normal Perlin noise texture though...

I mentioned hdr sky map is because at the moment the result is not as good as real photos,
next time try it out and you will get every piece of infor you want

 

[Mr Whippy]

Is there any way to tie your shader above into the existing 'texture' based sky?

Then we can basically change our cloud texture maps to normal maps with alpha opacity maps?


I'll try yours anyway of course, and it's a cool direction to go in longer term imo, but also would be cool for fixed TOD tracks with dramatic clouds to use a texture still (ie a cool sunset type )

Thanks!

Dave

 

[Ruud]

The cloud shaders we had used a texture and no matter the geometry, it would map the texture coords to a virtual plane at cloud height. Also enabling cloud movement. But no normals. I'll have a look next week.
BTW There's a v0.8.18 uploaded if correctly at http://www.racer.nl/download/racer0.8.18.zip, but I was at the DTM weekend all day, no chance to really release it.

 

[Bram Hengeveld]

Got some spare tickets for DTM ?

 

[Mr Whippy]

The cloud shaders we had used a texture and no matter the geometry, it would map the texture coords to a virtual plane at cloud height. Also enabling cloud movement. But no normals. I'll have a look next week.
BTW There's a v0.8.18 uploaded if correctly at http://www.racer.nl/download/racer0.8.18.zip, but I was at the DTM weekend all day, no chance to really release it.

That is nice.

Now the problem is that the sunrise/sunset occur different to the 'night' curve, and also the intensities are a bit off too.

I guess ultimately the intensity of the sun could be defined by a fixed method (ie, the diffuse values), since the tinting and sky intensity (sun_intensity) are impacted more by cloud cover, mie, rayleigh etc...
Afterall, in upper orbit the sun intensity is near fixed, so it's mainly clouds, mie and ray that adjust the intensity, colouring etc.

So I guess eventually we may just have a few curves.

Cloud cover, mie, ray, and the extinction one, and perhaps a few other control curves, with most of the stuff being calculated back from those, or forward from the sun position in the sky...


Either way, really nice work so far on that.


One thing I will say dead quickly, the exposure control seems ok in 1600x900 here, BUT, even in older versions and still here in 0.8.18, it seems to respond oddly.
If the sun spot is in front of you, the screen goes very dark (a problem, but not the problem here). If the sun spot is in front of you but in the top left corner it seems to respond better (not go as dark) to if it is in the top right corner when it goes even darker than dead ahead, and makes driving a bit hard

Hmmm

Dave

 

[gtpdzbiz]

The exposure problem has something to do with the screen resolution, in README Ruud stated it may not work well with non-power of two screen resolution because of rounding problem in glGenerateMipmap(), looks like it have to use the traditional way to calculate luminance with a shader.
Also be careful to set min & max exposure in racer.ini, where the min exposure decides how dark the screen goes in bright situation(i.e. looking at the sun), and the max exposure decides how bright the screen goes in dark situation(i.e. at night), set it at min=0.05
max=6.0 for a start...

 

[Alex Forbin]

The cloud shaders we had used a texture and no matter the geometry, it would map the texture coords to a virtual plane at cloud height. Also enabling cloud movement. But no normals. I'll have a look next week.
BTW There's a v0.8.18 uploaded if correctly at http://www.racer.nl/download/racer0.8.18.zip, but I was at the DTM weekend all day, no chance to really release it.

I'm having an odd problem. The brakelights seem to be somehow attached to the wheels now,as
I drive they flip around the wheels.??? Weird.
I did check the wheel models and they are fine. The phantom polys will disappear or appear when you press the brake, they don't show but they will cast shadows.

Alex Forbin

edit: It appears that it's actually all of the lights.

 

[Mr Whippy]

The exposure problem has something to do with the screen resolution, in README Ruud stated it may not work well with non-power of two screen resolution because of rounding problem in glGenerateMipmap(), looks like it have to use the traditional way to calculate luminance with a shader.
Also be careful to set min & max exposure in racer.ini, where the min exposure decides how dark the screen goes in bright situation(i.e. looking at the sun), and the max exposure decides how bright the screen goes in dark situation(i.e. at night), set it at min=0.05
max=6.0 for a start...

Hmmm, was that the case even 12 months ago though?

It's a problem I notice mainly on my hilly road track since dawn/dusk is driving into the sun depending on direction, and the brightness seems to vary depending on which top corner of the screen the sun is in.

Either way, the new HDR values and all that stuff are working really nicely, the auto exposure works nicely too. I'm just looking forward to it all being refined now, via good real values all round and knowing how different variables scale relative to each other, ie, sun_intensity for the sky intensity vs the sun position and kLux values, along with the cloud values too.

All good!


Will test your min/max values, thanks!

Dave

 

[Mr Whippy]

Here is an example of it at work.

The view is darker when the sun moves to the top right, than when it's in the top left of the screen.

I tried it in 1024x768 and it did the same, 1024x1024 it seemed to stop happening, or was maybe doing it very subtly by now (was hard to tell!)


Would be nice to have some weighting to determine the right exposure anyway, ie, the lower half of the screen gets 75% of the weight for optimal exposure, top half 25%... I dunno... either way I'm glad my eyes don't expose for the sun otherwise I'd not get anywhere


Dave

 

[Mr Whippy]

Hmmm, noticed that the CTRL-2 debug screen shows the scene intensity, and it works ok with pwr.2 resolutions, but clearly is showing badly with other resolutions.


As per skies generally, I've just created new curves for my track and all is fairly good. Just I'm wondering what are good sun_intensity values to use. It appears that around 10% of the sun diffuse intensity works well here through the main part of the day, but at dusk/dawn the curves clearly need to be really well controlled. Through the day 1hr intervals is ok, but around 30mins before/after sunset/rise you really need 10min intervals, if not closer, to really get the intensity balances really nice!


Slowly getting there, just very hard editing these finer details with both curved and the TOD editor in Racer (all too easy to create a new point rather than move an existing one )

Dave

 

[QuadCoreMax]

I wanna see some perfect TODs loops now, I remember in Crytek, I use to enjoy it a lot...