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

 

[Mr Whippy]

Hmmmm,

I'm really wanting a shader for trees (a fair way in the distance), that billboards them and always points them at the camera...


Ones that I get close to can then turn to X type trees, and really close can be polygonal and planar ones. But for ones a mile away but very 'obvious' (ie, on the horizon line that you drive past etc), are wasting polygons and not looking as sweet as ones that are just a single plane pointing at the camera.

Is this a possibility straight via the shader language in cg files?


Hmmm

Dave

 

[DavidI]

Imho that'd look kinda spooky, sorta like that cooked fish with eyes that always looks like its looking at you.

 

[Mr Whippy]

As said, it's for trees a good distance away, so you won't really be able to tell, but there are lots of them so they may as well be facing looking their best, and being quicker to render, than X type trees slower to render, looking less nice, taking up more polygons

http://maps.google.co.uk/maps?hl=en...d=9p89qTVLX31PkR0HtvrRbg&cbp=12,33.23,,1,2.47

Trees you won't ever get near off in the near distance there, but you'll travel past them as a whole. So planar ones won't work, and X type ones won't look as nice... facing planar ones will look nicest and be fastest, and easiest to author too


I guess this is maybe done via the vert shader and transforms, maybe?? But I have no idea where to start in this regard... Mitch is probably the man?

Dave

 

[DavidI]

I don't think poly's are a problem anymore in respect to shader complexity. On any hardware that is Cg capable, if u turn off shadows*, you get 100's of fps on any current track, even my 80x 240poly trees & 30x 150poly half trees on Mugello . Even double the trees doesn't hurt fps. With some custom mods to the flat treeline that make it more 3d and some halve'd 'real' trees around merged with the treeline, and the 'real' trees around is looking quite convincing.

My point I suppose is that the bar has been raised a bit, we can use more polys in tracks than we have been. The penalty comes now in the form of what shaders we use on them and how many 'processing heavy' shaders we do or don't apply to how many poly's

* imho current shadowmapping needs optimising, I believe it is at least twice as hard on the GPU as it could be, so when it is optimised that'd be 50-100's of fps with shadows depending on the GPU.

 

[Mr Whippy]

Yeah I guess so.

I'd rather be able to use both and see though... just to be happy with my final soltuon

I still believe the X type trees are ultimately not as nice looking, nor needed at a long distance. Hmmm...

Dave

 

[Ruud]

For far-away polygons that might not be too bad. It would be a mix between the particle billboarding and regular tree shading (taking care of the lighting normal, but that's details). I might have a look later...

 

[Mr Whippy]

Cheers Ruud!

I'm not sure it'll be ideal yet for intended purpose, but I want to try them out. I have this feeling it'll look better for the distances and volumes of trees I will need to fill in the large landscape that is visible on my new track!

Here is a quick pic to show the scope so far.

The circles are 2500m radius, just to give an idea of coverage... 7.5km from start to finish, going between 125m > 250m above sea level over it's length.

http://www.gowhippy.com/racer/img/test_01.jpg

Basically, there is a LOT to look at, and it's all rather nice looking too (area of outstanding natural beauty)... What looks a long way away is where you end up in around 3-4 minutes of fast driving, so it's important that what you see looks nicer as you get closer and closer

Ergo, trying out these tree types

Dave

 

[Stereo]

* imho current shadowmapping needs optimising, I believe it is at least twice as hard on the GPU as it could be, so when it is optimised that'd be 50-100's of fps with shadows depending on the GPU.

Don't know how much more I can optimize, but I'm working on the shadowmapping.cg.
Sticking with the default Carlswood/Murcielago combo, checking FPS around the start line. I have a 9500GT which is way below what you really need for Racer nowadays I guess. But it fully supports cg, so I can at least optimize things a bit.
0.8.21 default shadowmapping: 13.5fps
0.8.21 my tweaked shadowmapping: 17fps
0.8.21 no shadowmapping: 33fps
So far I've stuck to optimizations that don't impact visual quality in any way. Not sure how much of the 50% of GPU time is necessary for shadow rendering - it is after all doing a fair number of things in that time.
Plus, without blurring - makes visual artifacts visibly worse - but still gives shadows -
0.8.21 tweaked shadowmapping + [iSqrtSamples = 0]: 21 fps



Primary improvement I did was rewriting CheckCoords to eliminate branching:

bool CheckCoords(float4 shadowCoord,out float z)
{
  z=shadowCoord.z;
  return (shadowCoord.x >= 0.001f && // Check if we are inside the projected area
         shadowCoord.y >= 0.001f &&
         shadowCoord.x <= 0.999f &&
         shadowCoord.y <= 0.999f) ;
}

This accounts for >3 of the 3.5 fps difference. Other stuff I've done so far has barely affected it.

 

[Mr Whippy]

Hmmm, that code change didn't see any improvement here for me...


On a seperate bench mark, I go from 90fps > 80fps > 75fps as I go from 0 > 1 > 2 iSqrt samples.

I'm currently using 0 samples and 1024 sized maps and am fairly happy. The effect isn't perfect of course, BUT, I'm more looking for my senses being fooled, not a perfect reproduction... for racing at least.

For all the screen shot fanatics, can't we have a system that renders a higher quality shot at pressing of F12? Ie, AF goes up, DOF is added, loads of samples and map size for the shadows etc etc?


Dave

 

[DavidI]

Stereo, that does improve things for me, maybe +15 fps on average.

 

[Ruud]

Don't know how much more I can optimize, but I'm working on the shadowmapping.cg.
Sticking with the default Carlswood/Murcielago combo, checking FPS around the start line. I have a 9500GT which is way below what you really need for Racer nowadays I guess. But it fully supports cg, so I can at least optimize things a bit.
...

bool CheckCoords(float4 shadowCoord,out float z)
{
  z=shadowCoord.z;
  return (shadowCoord.x >= 0.001f && // Check if we are inside the projected area
         shadowCoord.y >= 0.001f &&
         shadowCoord.x <= 0.999f &&
         shadowCoord.y <= 0.999f) ;
}

This accounts for >3 of the 3.5 fps difference. Other stuff I've done so far has barely affected it.

Nice. It raised it from about 73fps to 84fps in my case. I've further optimized it as CheckCoords() is only called once; you can chuck out the 'out float z', and in the call to CheckCoords() also skip the z<1.0 check and put that in CheckCoords. Got me to around 87/88 fps. Will be in v0.8.22, thanks.

 

[Mr Whippy]

Ruud...

I'm not sure if you know the answer, but if I have terrain that is visible out to 20km from my track, and it's modelled in one giant object that is only about 5000 polys large, is it still worth cutting it up for faster rendering, so if you are say looking North, you only render 1000 polygons worth... or does that kind of thing not matter as much any more?

Ie, do we cut up to make any given Geob small in vert count, or do we cut up to actually allow unseen objects to not be included in the entire render pipeline at that frame?


Dave

 

[Ruud]

Ruud...

I'm not sure if you know the answer, but if I have terrain that is visible out to 20km from my track, and it's modelled in one giant object that is only about 5000 polys large, is it still worth cutting it up for faster rendering, so if you are say looking North, you only render 1000 polygons worth... or does that kind of thing not matter as much any more?

Ie, do we cut up to make any given Geob small in vert count, or do we cut up to actually allow unseen objects to not be included in the entire render pipeline at that frame?


Dave

I think these days the 5000 polys might be faster if just used everytime. use_vbo=1 normally so it's all on the card anyway. It seems the fewer batches the better. If a test is feasible, try splitting using a split size of around 600 meters. Still, with only 5000 polys it might be worth it.

 

[Mr Whippy]

Yep, I'll do lots of testing over the next few days. I want to see the impact of this huge vista I am rendering. Is there any way I can set the normal draw distance to 5000m, but have these long-distance polygons always drawn like the sky dome...? Ie, a flag I can use to extend the draw distance for said objects?


I could really do with starting to blog the build as reference for others at this stage, since I'm having to consider so much and it's worth me noting it down for others to just use I think.


Is anyone on here really good with phpUBB/hmtl/css to just help me get my web page/forum bloggy thing working right? Beer tokens in it for anyone willing

Dave

 

[Stereo]

Documents say sky=1 in the shader increases viewing distance to 10km. I haven't tried it myself though. Might also be flags=1 in geometry.ini to turn off distance/direction culling.

 

[Some1]

Is anyone on here really good with phpUBB/hmtl/css to just help me get my web page/forum bloggy thing working right? Beer tokens in it for anyone willing

Dave

www.blogspot.com not good enough?

 

[Mr Whippy]

www.blogspot.com not good enough?

Not sure...

I just wanted to throw it all up on my own forum, then I can do what I need with it, post up materials and host them there, all that kinda stuff...

I'll have a tinker and see what I come up with shortly

Dave

 

[Some1]

Not sure...

I just wanted to throw it all up on my own forum, then I can do what I need with it, post up materials and host them there, all that kinda stuff...

I'll have a tinker and see what I come up with shortly

Dave

Well, Wordpress is pretty neat software for personal websites and blogging. I'm going to use it for my own personal site soon...

 

[boomer541]

Got rid of the problem with car shadow flikering on/off some distance behind car when viewed with track camera by mucking around with the constants.cg variables and racer.ini split distances. Still have a problem with far distant shadows not rendering.

 

[DavidI]

I worked out how to have Cg scripts in track/cg folder without having to copy the atmosphere.cg etc.
with shader_f.cg in track/cg folder,

any includes in shader_f.cg must be

#include "..\\..\\..\\renderer\\shaders\\atmosphere.cg"

with

file=cg\shader_f.cg

in track.shd

I guess it'd work also for cars too.