The shader thread?

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.

shader_01.gif




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
 
Hmmm, I'm pretty sure the normal map shader in 089 bends reflections...

I have it on the side of my M3 which is 'flat', yet the normal mapping over the handle means the top-half reflects the sky but the bottom half doesn't...

Hrmmm, will take a look again :D


Dave
 
btw, I've a realy stupid question LooL
Is there any way to convert easily an .cg file to csm, because yet if I want csm in my cars I've to use the default cg files and I loose the metalic effect :(
 
Maybe a difference between csm and non-csm shaders??

I put a quick test pattern on the Lamborghini's roof, you can see the specular and diffuse are acting right, but the reflections are ignoring it (white line just follows the edge of a cloud from windscreen to roof)

The normal map is used to calculate fresnel values, so it will boost the reflection strength, but not what is reflected.

I'm using dyn_standard_reflect_v/f for the body, and dyn_standard_window_v/f for the glass.


Not really related but I gotta give thumbs up to Ruud for the bloom scaling factor in racer.ini, cutting the bloom map size helped my FPS a lot without disabling bloom completely. It's just a little blurry now:redface:


hopefully I can run down to the shop tomorrow while it's open and get a NVidia card so I can test CSM :D
 

Attachments

  • racer-refl-089.jpg
    racer-refl-089.jpg
    115.5 KB · Views: 262
Hmmm, I'm so sure I had it working.

I tried again last night and trying to use bump mapping at all on my M3 made it go transparrent or not render the refmap right... weird.

I'm so sure I had it working here... maybe it was in 088?!


Also, again, there were no docs on how to do it right (ie, in car.shd), so I had to look in the Lambo car.shd, which is far from nice as reference material.

Is it diffuse map, normal map, reflect map in layer 0, 1, 2 respectively?

Dave
 
On dyn_standard_bump_reflect_v/f and reflection bending, you can see in the vertex shader:

OUT.R=reflect(I,n);

So it's mostly interpolated across the polygon, not taking into account the bumpmap. In the fragment shader then:

float4 envColor=texCUBE(envMap,IN.R);

But notice that both I and n are available in the fragment shader. So putting the texCUBE() behind the 'N=expand(...)' and recalculating a per-pixel 'R' should do the trick. I'll try that for v0.8.10 (out this afternoon if all goes well).

For the texture layers, I've made a note to expand the documentation to include that information.

edit: unfortunately the 'R' above then needs transformation along the TBN matrix. Doesn't work that quickly. :(
 
Ruud, what was the rationale behind changing the sun intensity scaling?

I am confused what sun intensity actually is right now... what is this value actually relating to in the 'real world'

All I can see it do is alter the intensity of the sky-box texture... which then impacts the intensity of the env map...

It also feels like everything is reflecting blue now too, or the sky is far too bright...

What was the factor of scaling for the sun intensity? 2000 x less (ie, 2000 is now the equivalent of 1?) Or is it a different 'normalisation'

Just trying to get the same 'look' I did before and it's proving hard work (another change that should really have been better explained/documented as yet again I'm wasting hours re-setting lighting/mie/rayleigh/sun intensity and so on, on my tracks which I have setup nicely for setting up car shaders hehehe )


edit:hmmm, the ambient lit areas still seem really really dark. Also, wouldn't it make some sense to link sun intensity to the diffuse variable. When I set "sun diffuse 0" there is still a sun spot there...

This sky thing is just getting too messy now.

sun=-50000 15000 -12000
{
intensity=0.75
enable=1
ambient=0.35 0.375 0.4 1
diffuse=0.75 0.75 0.75 1
specular=1 1 1 1
global=0 0 0 1
}

sun needs to prefix the braces to make the contents of them work, which is kinda odd (as all other headers to sub-sections are not also data inputs)
intensity is a sun variable
enable seems to be the same as intensity =0 (off) or if greater than 0 (on)
ambient is a function of the sky
diffuse is a function of the sun
specular (may as well be linked to diffuse (it is in the shaders anyway isn't it?))
global, hmmm


Not better to have

sun
{
location (xyz)
intensity (rgba)
}
sky
{
intensity (rgba)
}

Right now I feel like I am doing the same things several ways. The sun is a single light, does it need to have it's intensity defined twice, with an rgba for it's output intensity and colouring AND another intensity value that is un-intuitive to set? Surely the two are linked somehow, or should be?

I don't know, it just feels hard to set. Right now your TOD defaults are rather poor (far too much sun colouring, not enough ambient tinting), and ambient generally feels really dull now. I also have no idea what kinds of values to use for sun intensity, mie, rayleigh or if we should use anything but 1 for extinction factor...

TOD doesn't seem to adjust "sun intensity" but it does adjust the suns actual colouring intensity via 'diffuse', which seems a bit wrong?




Also, just a quick one, do lens flares scale with field of view? Should they? You can set them to work really nicely on an 'outside' car view, but then the next minute from a track camera they blow out the car for example... they seem to just be useless here except for one camera view which you tweak them to look good from?!


Any help with values or logic of how to set stuff up would be much appreciated :D

Dave



EDIT EDIT,

Are reflections been rendered in the shadowed areas anymore?

If I turn diffuse to 1, ambient to 0, and have a low sun, the sky reflection is very strong at the lit side of the car, yet it is literally black at the other.
Has the reflection calculation (or fresnel factors) been messed up a bit?!?

Dave
 
Lastly lastly, I'm just getting really confused now.

Does the Lambo in it's current state represent any kind of 'best practice' for shaders.

In the shader folder there is... dyn_standard_reflect_window_f/v.cg



How is it meant to be used?

The default shaders might work, but without the exact syntax of how we use them per-car, and what the rgb/a channels are meant to do, they are hard to use.
Ie, do we use the reflect variable 0...1, do we use sort_offset, depthwrite toggle, and so on.

Just trying to work from first principles as a car creator and there just isn't anything that says "this is how to make glass look like glass on a car"

Thanks

Dave
 
I'm having trouble with the sky and sun on ver 0.0810. On older tracks other than carlswood the sky is JUST TOO BRIGHT and I can't figure out how to get the intensity down.

The racer.nl page for ver 0.09 has info about making skies which I'll look into.

The old way of doing skies work very nicely, can't see why they were changed!

I also don't like Bloom and that csm_f.cg doesn't seem to do anything when I put it into the "filter 1=" variable.

Mr. Whippy, cars need a different shader setup than what worked in earlier versions, make like Lambo.
 
It appears to be the rayleigh and mie settings that effect the sky intensity. I tried the blend_track from racer.nl for ver 0.09 and set the two values to 0.0008 to get a nice blue sky but that doesn't appear to work in ver 0.089.
 
It appears to be the rayleigh and mie settings that effect the sky intensity. I tried the blend_track from racer.nl for ver 0.09 and set the two values to 0.0008 to get a nice blue sky but that doesn't appear to work in ver 0.089.

They probably haven't been normalised, so perhaps they are now much more sensitive?

Ie, if as Stereo said, 1000 >> 1, then if that value was multiplied by rayleigh/mie at all, then we need values 1000 time smaller for mie/rayleigh than before?!

All depends how Ruud normalised it?

As for intensities, I found 2500 quite a reasonable setting for a bright day.

Ruud really needs to clarify what he has changed here, speculation isn't ideal because it could be buggy, or it could be that we need to rethink the magnitude of mie/rayleigh?!

Also, of what importance is extinctionfactor? Should this always be 1, or is it another value like mie/rayleigh that is set to preference?

Dave
 
Ruud, what was the rationale behind changing the sun intensity scaling?

I am confused what sun intensity actually is right now... what is this value actually relating to in the 'real world'
...
What was the factor of scaling for the sun intensity? 2000 x less (ie, 2000 is now the equivalent of 1?) Or is it a different 'normalisation'

edit:hmmm, the ambient lit areas still seem really really dark. Also, wouldn't it make some sense to link sun intensity to the diffuse variable. When I set "sun diffuse 0" there is still a sun spot there...

sun=-50000 15000 -12000
{
intensity=0.75
enable=1
ambient=0.35 0.375 0.4 1
diffuse=0.75 0.75 0.75 1
specular=1 1 1 1
global=0 0 0 1
}

enable seems to be the same as intensity =0 (off) or if greater than 0 (on)
ambient is a function of the sky
diffuse is a function of the sun
specular (may as well be linked to diffuse (it is in the shaders anyway isn't it?))
global, hmmm


Right now I feel like I am doing the same things several ways. The sun is a single light, does it need to have it's intensity defined twice, with an rgba for it's output intensity and colouring AND another intensity value that is un-intuitive to set? Surely the two are linked somehow, or should be?

I don't know, it just feels hard to set. Right now your TOD defaults are rather poor (far too much sun colouring, not enough ambient tinting), and ambient generally feels really dull now. I also have no idea what kinds of values to use for sun intensity, mie, rayleigh or if we should use anything but 1 for extinction factor...

TOD doesn't seem to adjust "sun intensity" but it does adjust the suns actual colouring intensity via 'diffuse', which seems a bit wrong?

Also, just a quick one, do lens flares scale with field of view? Should they? You can set them to work really nicely on an 'outside' car view, but then the next minute from a track camera they blow out the car for example... they seem to just be useless here except for one camera view which you tweak them to look good from?!
Are reflections been rendered in the shadowed areas anymore?

If I turn diffuse to 1, ambient to 0, and have a low sun, the sky reflection is very strong at the lit side of the car, yet it is literally black at the other.
Has the reflection calculation (or fresnel factors) been messed up a bit?!?

You ask too many questions in 1 post. ;-)
On atmosphere shaders, it is all based on this: http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter16.html
The actual code with that doesn't work on my machine (nVidia GTX285) but the idea is used in a lot of software.

I'm hesitant to modify the sun parameter ini definition too much; atmosphere should get a proper overhaul in the future to make HDR more logical. In that light, the sun intensity was indeed scaled by 2000 inside the shaders. So if you had 3500, now use 3500/2000= 1.75.

How the sun works: 2 different areas, the atmosphere (sky) and all the track/car objects. The Cg sky shaders create the sky colors out of rayleigh/mie and intensity. On the other hand, the non-sky objects are lit using diffuse/ambient/specular. 'Global' is obsolete, forget it.
Check the renewed information on http://racer.nl/tutorial/shading_tracks.htm#skies also. (you may need to use F5/refresh)

The unlogical thing is thus that the sky shader calculates its values for diffuse/ambient (zenith) color, and applies a brightness to it according to sun/vertex position. The sun.diffuse/ambient colors are decoupled and are used on non-sky geometry. I should perhaps try and code the Cg algorithm for rayleigh/mie colors for the zenith in C++ and use those directly. That may be a bit problematic though (too dark, or if you watch mie solely (which is a bit the sun diffuse color) than it gets very very red in the evening. Might not match too great with what you want on the ground geometry.

TOD indeed does not touch sun intensity, just diffuse/ambient. sun.enable isn't recommended (flares) since the C++ sun position doesn't really match the Cg atmosphere shader position (which isn't a position really, but a miePhase which is quite complex).

Not sure about the reflections in ambient areas; I should check.

Fresnel has changed slightly (from bias=0.15, scale=0.85 to bias=0.1, scale=0.9) but you can alter fresnel parameters in .shd files now: see http://racer.nl/reference/shadereng.htm#matglobal
 
Ah thanks for that Ruud.


Scaling the sun intensity seemed a bit of an odd change if it is now simply scaled back up again in the code? I'm happy for that to be the case, but I felt that it implied some more accuracy as in we shouldn't go above a value of 1 (or 2000 on the old system), when it appears that any value is reasonable, just it is now in the 0.5 > 1.5 range, rather than 1500-2500 range or so :)

Happy either way, just good to know the factor!



Sounds like the sky/sun is ok as it is now then. I would be really happy to have some curves to define the parameters as per this thread though:
http://www.racedepartment.com/racer/34292-time-day-thoughts-ideas.html

Static lighting setups are fine, but I really like TOD now with CSM, the scenes feel so much more life like. The missing capability is to tune the sun ambient/diffuse at the same time as mie/rayleigh to get the colourings matching up nicely!
Another sub-question here, should our sky textures have any blue element added now, since this is added via rayleigh? Are we getting too much blue because we are adding rayleigh in the texture, and then Racer is adding it itself once again?

Would there be much use in just having a fully CG generated sky dome for the whole TOD system, rather than us defining textures and generating polygons etc?



Fresnel explains the difference then, 0.15 > 0.1 bias is probably causing the change. Why were the defaults changed? They seemed very natural before for 'car paint' generally. Several of us have noted cars being darker than before. I've been pumping ambient higher than is natural looking to try get my cars looking right again on th shadow side, so I think the new fresnel defaults are not so nice.

Is there any way that these changes can be more explained in the changelog. (ie, scaling for sun intensity normalisation and also the change above to fresnel)... it'd make it much quicker for us to sense check why our content is changing dramatically from version to version, and be able to adjust as necessary to check things still look ok. I know all this is in the shader files but it'd be nice to not even have to check there for changes :D
It wouldn't normally be essential but it would be really helpful!


All generally really positive though. I like where things are going with Racer a great deal!

Many thanks

Dave
 
They probably haven't been normalised, so perhaps they are now much more sensitive?

Ie, if as Stereo said, 1000 >> 1, then if that value was multiplied by rayleigh/mie at all, then we need values 1000 time smaller for mie/rayleigh than before?! All depends how Ruud normalised it?

Only sun.intensity was normalized (by scaling 2000 inside the Cg shader itself). Mie and rayleigh are not normalised, they are values as you can find using Google. I'll keep those. Realistic for rayleigh is 0.0025-0.0035 and mie around 0.001. A rayleigh of 0.0008 would probably give a blackish sky, since it's what goes on near outer space.

Extinctionfactor is purely a scale on the atmosphere fade amount. Use 2.0 and things get blended into atmosphere colors more quickly. Use 0.5 and you get little fog. It scaled Z distance to determine the amount of extinction, nothing to do directly with the other parameters.
 
Something odd going on with the way these values are calculated.

These pictures are same location, same time, same sun intensity.

The difference is the order I set the values. Both started at 18:00 1.0 (track default).

Left: time 10:00, intensity 1.5. Right: intensity 1.5, time 10:00.
 

Attachments

  • darkmorning.jpg
    darkmorning.jpg
    50.6 KB · Views: 257
Lastly lastly, I'm just getting really confused now.
Does the Lambo in it's current state represent any kind of 'best practice' for shaders.
In the shader folder there is... dyn_standard_reflect_window_f/v.cg
How is it meant to be used?

I still need to figure out transparency so that it works ok-ish with shadowmapping. We have a problem there where shadow receiving on transparent shaders is a big problem due to our G-buffer layout (without CSM the problem is not really there).
I will update http://racer.nl/tutorial/shading_cars.htm once I figure out how to give the Lambo a nicely working window shader (that includes reflections).
 
Great to hear from you again Ruud!

Posted in the 0.8.09 thread but unsure if you're checking that with the release of 0.8.10
Also, it's more of a graphics related thing...
Instancing: is this a possibility? Perhaps an instance.ini in the track folder that reads as follows?

Code:
object1
{
[INDENT]file=tree.dof
instances
{
[INDENT]1
{
[INDENT]x=xxx.xxx
y=yyy.yyy
z=zzz.zzz[/INDENT]
}
2
{
[INDENT]x=xxx.xxx
y=yyy.yyy
z=zzz.zzz[/INDENT]
}[/INDENT]
}[/INDENT]
}
object2
{
[INDENT]file=tyre.dof
instances
{
[INDENT]1
{
[INDENT]x=xxx.xxx
y=yyy.yyy
z=zzz.zzz[/INDENT]
}
2
{
[INDENT]x=xxx.xxx
y=yyy.yyy
z=zzz.zzz[/INDENT]
}[/INDENT]
}[/INDENT]
}

I'm sure this is difficult to code but if it was done it would allow MUCH richer environments for racer.

It's also great to see fresnel values moved to the .shd files, I'll need to release some more content soon methinks.

I also agree with Dave that mie and rayleigh would benefit from being defined in a LUT/.crv

Racer's shaping up to be a great v1.0 :wink:
 
Scaling the sun intensity seemed a bit of an odd change if it is now simply scaled back up again in the code? I'm happy for that to be the case, but I felt that it implied some more accuracy as in we shouldn't go above a value of 1 (or 2000 on the old system), when it appears that any value is reasonable, just it is now in the 0.5 > 1.5 range, rather than 1500-2500 range or so :)

Sounds like the sky/sun is ok as it is now then. I would be really happy to have some curves to define the parameters as per this thread though:
http://www.racedepartment.com/racer/34292-time-day-thoughts-ideas.html

Another sub-question here, should our sky textures have any blue element added now, since this is added via rayleigh? Are we getting too much blue because we are adding rayleigh in the texture, and then Racer is adding it itself once again?

Would there be much use in just having a fully CG generated sky dome for the whole TOD system, rather than us defining textures and generating polygons etc?

Fresnel explains the difference then, 0.15 > 0.1 bias is probably causing the change. Why were the defaults changed? They seemed very natural before for 'car paint' generally. Several of us have noted cars being darker than before. I've been pumping ambient higher than is natural looking to try get my cars looking right again on th shadow side, so I think the new fresnel defaults are not so nice.

Is there any way that these changes can be more explained in the changelog. (ie, scaling for sun intensity normalisation and also the change above to fresnel)... it'd make it much quicker for us to sense check why our content is changing dramatically from version to version, and be able to adjust as necessary to check things still look ok.

The sun scaling was done because I find normalized values a nice starting point, esp when you consider that if you talk about lumen, you get very high dynamic ratios which seemingly the floats won't handle nicely. So in the future I need to define a HDR range for all lighting to work in. The 2000 was just an empirical value for the Cg shader to look ok, not any real-life value. For those types, I'd rather use 1.0 and for the future have a nice baseline to work from than a funny scale like '2000' which was based on nothing but just looking at a screen.

I'll think about fully parameterisable TOD curves. Sounds ok.

For fresnel, note that CSM ofcourse adds more shadows than it did without shadowmapping! So the ambient side indeed becomes darker since the shadow is multiplied in combination with lightAmbient, whereas we only have lightAmbient in pure HDR (without CSM). I tend to raise ambient to almost 1 1 1. It's just that without CSM we didn't have the added shadowmap darkening things.
It was changed during a test to get a car here more looking like a real Ferrari car photograph. I would have left the defaults alone if they weren't programmable now.
If you don't think that's the cause, try in the car.shd to add fresnel to see if the originals were better:

shader_x
{
fresnel
{
bias=0.15
scale=0.85
power=2.0
}
layer0
{
...
}
}

Sorry that the changelog doesn't capture all, I'll try to do better.

Other than that, I'm trying to add lots of documentation on the v0.9 state of things, so that all of these questions become pointers to racer.nl. :) Also one of the reasons that I don't want to change more dramatic things like ini paths.

EDIT: oh, the sky. Just updated in the shading_tracks.htm:

"Since the sky Cg shaders take care of the sky color when considered cloudless, texturing the sky should be done with just clouds and alpha to determine where the clouds are visible. Notice the console command 'clouds <n>' with which you can set the amount of cloud dynamically (a scale on the texture's alpha value). So your sky texture should NOT look blue! Just a black & white image of clouds."
 
Something odd going on with the way these values are calculated.

These pictures are same location, same time, same sun intensity.

The difference is the order I set the values. Both started at 18:00 1.0 (track default).

Left: time 10:00, intensity 1.5. Right: intensity 1.5, time 10:00.

Hm, seems ok with Carlswood here...
 
Instancing: is this a possibility? Perhaps an instance.ini in the track folder that reads as follows?

Code:
object1
{
[INDENT]file=tree.dof
instances
{
[INDENT]1
{
[INDENT]x=xxx.xxx
y=yyy.yyy
z=zzz.zzz[/INDENT]
}
2
{
[INDENT]x=xxx.xxx
y=yyy.yyy
z=zzz.zzz[/INDENT]
}[/INDENT]
}[/INDENT]
}
object2
{
[INDENT]file=tyre.dof
instances
{
[INDENT]1
{
[INDENT]x=xxx.xxx
y=yyy.yyy
z=zzz.zzz[/INDENT]
}
2
{
[INDENT]x=xxx.xxx
y=yyy.yyy
z=zzz.zzz[/INDENT]
}[/INDENT]
}[/INDENT]
}

I'm sure this is difficult to code but if it was done it would allow MUCH richer environments for racer.

It's also great to see fresnel values moved to the .shd files, I'll need to release some more content soon methinks.

I also agree with Dave that mie and rayleigh would benefit from being defined in a LUT/.crv

Racer's shaping up to be a great v1.0 :wink:

Theoretically instancing would be nice. But with what editor? Here we have a workflow where artists create the tracks fully in Max. To create trees outside of Max would be costly and a bit awkward since the trees aren't there in Max and you need to place in... TrackEd?
It seems blasting a few hundred polygons to the card is faster these days than trigger a lot of the same geometry. Even in GT5, most trees are only crosses, with a nice shader that is.
 

Latest News

How long have you been simracing

  • < 1 year

    Votes: 367 15.9%
  • < 2 years

    Votes: 255 11.1%
  • < 3 years

    Votes: 246 10.7%
  • < 4 years

    Votes: 181 7.8%
  • < 5 years

    Votes: 303 13.1%
  • < 10 years

    Votes: 260 11.3%
  • < 15 years

    Votes: 166 7.2%
  • < 20 years

    Votes: 129 5.6%
  • < 25 years

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

    Votes: 299 13.0%
Back
Top