The shader thread?

Mr Whippy · Jun 17, 2010

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 · Jul 5, 2010

The Cg shaders generate the sky colors, that is a 'generated' texture if you will. The sky.tga is just overlaid using its alpha channel, but generally you want to avoid the blue color in the sky map since that would overrule the sky color that was calculated in the Cg shaders.
You can use panoramic sky images, but if you include sky colors in that image, you lose the ability to have TOD (not necessarily a bad thing; sometimes a photograph looks better than the generated sky. You can do both).

sky_daynight_*.cg is still unchecked, I'm not sure if they work correctly, but probably currently they use alpha in the day/night textures differently from sky*.cg.

Mr Whippy · Jul 5, 2010

Ah, day/night still not 100%... I've been using those (as per Carlswood), so I'll revert to using the ones as per the racer.nl documentation for now!

May have been making a difference to the way things looked if they have not been updated/checked etc.

Thanks

Dave

boomer541 · Jul 6, 2010

Version 0.0811 works well with skies that I made using both panoramic and hemispheric textures on a sky dome. The day/night shader only has one problem, imho, the sun s/b on the outside of the sky dome! Is that due to the x,y,z values used? Carlswood uses tens of meters, I usually set the sun coordinates at least x00000000 meters away but the sun is still close.

TOD works reasonably well for me, the sun tracks well and there isn't a second one!

Thanks for the sky changes in v 0.0811 Ruud!

Mr Whippy · Jul 6, 2010

I think the sun x.y.z are just inputs for the point in space, so 1,2,3 == 1000,2000,3000

I'm guessing Ruud forces the sun to be essentially at infinity, so the x.y.z given are just for the gradient/angle of the sun relative to the world!?

TOD does seem to work nicely, around sunset/sunrise and so on, but as soon as the day gets around 11am > 5pm the colouring and intensities just feel all wrong. Far too much yellowy tint to the light at midday etc, and too much ambient fill etc (the values may be right outright (well they are nothing like HDR values), but without exposure control working the scenes just look un-natural)

All good though, it's generally robust which is the main thing. I'm still unsure if I get some weird refmap issues though, like the cube edges become visible in the reflection in the car sometimes.

Dave

boomer541 · Jul 7, 2010

Sun coordinate guide:

Mr Whippy · Jul 7, 2010

Thats a handy little diagram

Thanks!

Ruud · Jul 8, 2010

boomer541 said:
Version 0.0811 works well with skies that I made using both panoramic and hemispheric textures on a sky dome. The day/night shader only has one problem, imho, the sun s/b on the outside of the sky dome! Is that due to the x,y,z values used? Carlswood uses tens of meters, I usually set the sun coordinates at least x00000000 meters away but the sun is still close.

The sun 'position' is more a direction. Setting it to extremely high values might just mess with floating point precision. Keep it under 1000 or so. It's only the direction that counts, since the sun is a parallel light from the Earth's perspective.

I'll have a look at the day/night shader today, move it towards what sky_*.cg is doing.

Mr Whippy · Jul 9, 2010

Hmmmm,

Currently trying to make a nice set of tree lines that cascade (ie, you can see ones behind others into the distance a bit)

Right now I can't seem to get transparency to work unless I use the standard_tree_v/f shaders

When I do use those shaders, the problem is they are only good for X type trees, but tree lines which DO need to be shaded depending on their normal (ie, dark on the back, lit on the facing side)

Is there a shader that is designed for tree lines?

I tried using standard_v/f but no transparencies seemed to work.

Also, if you can see items through the transparent edges of these tree lines, then the edge is clearly not so nice quality (looks fairly fat and grey)... is there no way to make the blend better despite a cost of speed?

Also, in reflections I need alphafunc=gequal 128(or any normal number) so that reflections of the tree lines show up with transparency in my envmap.

Generally not THAT bad, but you can just see the stippling effect for transparency at a larger distance, rather than a nice smooth blend that we used to have. Do CSM really cause such big problems for a blend? Can CSM not use gequal 128 (like envmap rendering?!), and then we get to see a nice smooth blend instead?

No idea how it all works really. I'm sure in 1600x1200 it'll not look so bad, but in the lower resolutions (that many may use with CSM since I've had to drop to 1024x768 on my current gfx card), it does look a bit pants vs old style

Hmmm

Thanks

Dave

boomer541 · Jul 9, 2010

I still use large values (about 1000000) for the sun position and have had no problems with floating point precision, afaik.

The current sky.cg shader doesn't allow the night image to be seen and the sky_day/night one does, that's why I use it and it works quite nicely. My only problem is with the sun not disappearing when it gets behind mountains or such in the sky image.

Perhaps a proper alpha channel value could be used to block it when making the sky/day/night.tga images, hmm.

Ruud · Jul 9, 2010

Mr Whippy said:
Currently trying to make a nice set of tree lines that cascade (ie, you can see ones behind others into the distance a bit)

Right now I can't seem to get transparency to work unless I use the standard_tree_v/f shaders

Try standard_transparent_f.cg, which passes the alpha to the framebuffer (and use standard_v.cg for the vertex side).
And indeed, blending is a problem in any deferred-type renderer...

Mr Whippy · Jul 9, 2010

Ah cool, thanks for that Ruud.

I honestly am getting so mixed up with what shader to use for which thing. Some shaders need the v one, others don't have a v one so I use another one etc etc

I'm definately in the camp of needing a picture of what I want to do, which shaders to use, and what the syntax and texture should look like

(like the current sky example on racer.nl

)

I'll give that a go tonight.

Deferred shading... grrr... no way to not deffer shading for certain items? They are casting shadows way outside where you will notice them anyway... not a huge issue just a question really.

also is there any way to tell an item to not cast a shadow? (ie, using the above tree shader for grass (like on swiss stroll) is leaving shadows everywhere and they look rather ugly here)

Many thanks

Dave

gtpdzbiz · Jul 10, 2010

Mr Whippy said:
Ah cool, thanks for that Ruud.

I honestly am getting so mixed up with what shader to use for which thing. Some shaders need the v one, others don't have a v one so I use another one etc etc

I'm definately in the camp of needing a picture of what I want to do, which shaders to use, and what the syntax and texture should look like (like the current sky example on racer.nl )

I'll give that a go tonight.

Deferred shading... grrr... no way to not deffer shading for certain items? They are casting shadows way outside where you will notice them anyway... not a huge issue just a question really.

also is there any way to tell an item to not cast a shadow? (ie, using the above tree shader for grass (like on swiss stroll) is leaving shadows everywhere and they look rather ugly here)

Many thanks

Dave

Add a depthwrite=0 to a shader, then it won't cast any shadow, though it have some issue with Z-sorting~

Mr Whippy · Jul 10, 2010

Is depthwrite = 0 the 'proper' way to disable shadows?

Problem is for grass that sorting is probably quite important, just I don't want the shadows...

I did notice in trackEd some flags that could be set for casting shadows or not (a geometry.ini flag entry?!), not sure if they mean anything or not

Dave

gtpdzbiz · Jul 10, 2010

Mr Whippy said:
Is depthwrite = 0 the 'proper' way to disable shadows?

Problem is for grass that sorting is probably quite important, just I don't want the shadows...

I did notice in trackEd some flags that could be set for casting shadows or not (a geometry.ini flag entry?!), not sure if they mean anything or not

Dave

Those flags have been there for a long time~probably for the old stencil shadow. The depthwrite=0 was mentioned by Mitch before, maybe it's just a temp solution.

Mr Whippy · Jul 11, 2010

Just trying to make some decals on my track work.

vf_transparent
{
vertex_shader
{
file=standard_v.cg
}
fragment_shader
{
file=standard_transparent_f.cg
}
}

shader_runway_decal~vf_transparent
{
layer0
{
map=runway_decal.dds
shininess=1
specular=1 1 1 1

alpha_to_coverage=1
depthwrite=1
alphafunc=gequal 128
}
}

Everything looks fine with these settings until a shadow is thrown into the mix. The car shadow isn't cast onto the decals.

Also, there is some flickering from the helicopter view, which I thought wouldn't be evident when the runway being opaque and thus depth of 300, and alphafunc blends being at a depth of 500.

I wonder if the standard_transparent_f.cg is working properly or not... not sure... quick look in the shader and there is nothing obvious

Are the above settings right for an on-track decal?

On a side note, I also used flags=0 and flags=6 with no difference except I could feel the slight kick as I drove over the flag=6 ones (and also got their material at the wheel patches)... if you can get the decal polygons very low (ie, 0.5cm above the track surface or less), then you could have a lower friction material for them (ie painted road markings), which might make things more fun to drive on!

Dave

Ruud · Jul 12, 2010

Using depthwrite=1 for the decals means you get shadows (Z-map) and you get Z-fighting. I use depthwrite=0 for the Carlswood decals, avoiding aliasing shadows and flickering better. I've written down to describe the track decals on the shading_tracks page on racer.nl.

As for shadows and grass; I want to add a shader flag: cast_shadows=0, to skip all such materials during the shadowmap generation pass. This is nice for grass - I do want Z-buffering for the grass parts, but avoid the (mostly) unneeded shadows. Will be in v0.8.13.

EDIT: it's online, see http://www.racer.nl/tutorial/shading_tracks.htm#decals

gtpdzbiz · Jul 12, 2010

Some tweaking on sky shader and parameters, the code seems comes from Ogre's SkyX plugin, but seems SkyX uses a different sky dome model and exposure control, things become very nasty when tweaking it. Somehow, after much tweaking and tweaking, the sun color(sky) seems respond to InnerRadius/OuterRadius, Mie, rayleigh and InvWavelength.

This modified atmosphere.cg has changed the atmosphere parameters and the rayleighphase mode, so now the side of sky dome opposite to the sun won't be over lit. Try positioning the sun near ground level(sun.y=3~5) in track's special.ini for a nice sun set. (the attached special.ini is for carlswood_nt, check out post ur screen section for some screenshot)

And there's one more thing~check out the new particle shader for volumetric tire smoke and gravel smoke, with correct shading. (particle_bump_*.cg for particle shader and smoke_fake_lighting_normal.tga as smoke texture)

Ruud · Jul 12, 2010

Nice work on the atmosphere.

I seem to need 'sun intensity 0.5' to get the dusk look though, otherwise it's far too bright.
There's a strange jump at 20:42 -> 20:43, perhaps a result of the revise '1.5-cos*0.5' parts? Perhaps 1.5 should really be PI/2?

SkyX and all the others seem all based on the same papers. I originally got mine from one of the GPU Gems books. But google for 'v3Ray' or such and you get a slew of projects using the same system. But some use funny atmosphere thicknesses like '1'. Hm.

I'll have to check your volumetric smoke as well...

Mr Whippy · Jul 12, 2010

Ruud said:
Using depthwrite=1 for the decals means you get shadows (Z-map) and you get Z-fighting. I use depthwrite=0 for the Carlswood decals, avoiding aliasing shadows and flickering better. I've written down to describe the track decals on the shading_tracks page on racer.nl.

As for shadows and grass; I want to add a shader flag: cast_shadows=0, to skip all such materials during the shadowmap generation pass. This is nice for grass - I do want Z-buffering for the grass parts, but avoid the (mostly) unneeded shadows. Will be in v0.8.13.

EDIT: it's online, see http://www.racer.nl/tutorial/shading_tracks.htm#decals

Hmmm, my decals don't seem to be picking up the shadows from the car...

Also, I'm still not sure what depthwrite does, but shouldn't we just use a sort_offset to assure the decals are rendered after the track itself?

Also, how come we don't need to use alphafunc=gequal 128 for the decals? Without this set my decals in the envmap are not blended, but with that set then they are visible blended in the envmap.

Also, I still get some flickering with the depthwrite=0, should that occur? They are 5mm above my track surface (very close), so not sure if that makes a great deal of difference?!

Dave

QuadCoreMax · Jul 13, 2010

Mr Whippy said:
...Also, I'm still not sure what depthwrite does, but shouldn't we just use a sort_offset to assure the decals are rendered after the track itself?

If decals are just offset polys in Racer, they're always rendered on top of terrain, so no worries. I'm thinking more about projecting/painting my HM (heightmaps) with some decals & then split/optimize the scene for track export in Modeler/Tracked. That's really what Ruud was advising earlier.

Good question, in which order 3D objects are rendered in Racer for cars (in cockpit / outside) & tracks ?