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

 

[Raphael Buthmann]

Oo oh gosh lol.
You need to put the speckle_v/f into the shaders folder , not on cg into car folder.

 

[Ruud]

The ddx() did the trick for that xtree shader. You detect UV direction using if(ddx(IN.tc0.x)>0)one_side; else the_other.
Added a small roundness parameter to the tree as well, so normals are not completely bended sideways at the edges. Also added some ambient to Carlswood's Xtree (Racer)shader to simulate a bit of light coming through. Quite nice, although a dot product for the sharpest X tree triangle might be even better, but that requires more scribbling and such. Oh well.
Will post v0.8.29 tomorrow; it seems better also with the controls, and I'm currently fixing replay sounds for the large part. Leaving 2010 with a small software-bang.

 

[Stereo]

Also added some ambient to Carlswood's Xtree (Racer)shader to simulate a bit of light coming through.

Not sure if this makes sense but maybe it should only do this when opacity is less than 100%? I don't expect light to come through the trunk, but I'm not sure if the leaves are solid either (in the texturemap, rather than alphafunc=gequal 128)

 

[camsinny]

Or maybe through the green channel? Bodge some SSS and translucency of the leaves?

 

[Mr Whippy]

Not sure if this makes sense but maybe it should only do this when opacity is less than 100%? I don't expect light to come through the trunk, but I'm not sure if the leaves are solid either (in the texturemap, rather than alphafunc=gequal 128)

I don't get it either.

What is actually happening there Ruud?

It's probably ideal that we pass that to the shader so we can control it per tree type?

Maybe even, as Cam said, just add some yellowy green illumination to the green channel on the side opposing the sun, in relation to the sun diffuse intensity, possibly only on the edges (or normals) at the edges (since outside leaves get lots of light vs the ones in the middle of the tree)

Either way, happy enough for now on these, it's tons better than it was... but obviously still some distance to go on the shader if we want. BUT, that doesn't impede us for now. We don't need to do anything except make nice X tree shaders, and simply think of nice tricks to do in the shader to make them look better later


All good

Dave

 

[Alex Forbin]

I don't get it either.

What is actually happening there Ruud?

It's probably ideal that we pass that to the shader so we can control it per tree type?

Maybe even, as Cam said, just add some yellowy green illumination to the green channel on the side opposing the sun, in relation to the sun diffuse intensity, possibly only on the edges (or normals) at the edges (since outside leaves get lots of light vs the ones in the middle of the tree)

Either way, happy enough for now on these, it's tons better than it was... but obviously still some distance to go on the shader if we want. BUT, that doesn't impede us for now. We don't need to do anything except make nice X tree shaders, and simply think of nice tricks to do in the shader to make them look better later


All good

Dave

Why not just do an ambient level based on the basemaps color? Since we are using photos of leaves they already have the lighting info in them: lighter_color=higher_ambient.

Alex Forbin

 

[Mr Whippy]

Why not just do an ambient level based on the basemaps color? Since we are using photos of leaves they already have the lighting info in them: lighter_color=higher_ambient.

Alex Forbin

Not sure really. Not sure what any of these things will actually do until we see them in action.

On an overcast day the tree appearance should just be the straight diffuse map, equal intensity all over as per any matte ish material.

Add in the sun, and that adds to the sun side of the tree. The issue then is the shaded side. That still gets the ambient lighting from the overcast day now...

If the unlit side gets some extra intensity, it should be emissive related really, since that is what is REALLY occuring. A tree doesn't receive more ambient because it's made of leaves

So if we could, on the back side of the tree to the sun, add an emission value, and as per the curved normals, apply it like a sphere perhaps, so only the edges facing to the sides (perpendicular) to the sun direction get emission. That way, from the back of the tree, we get a halo of light which is passing through and scattering from the leaves around the edges.
On some trees that might be fairly all over, but for a dense thick tree it may be limited to the edges.

Either way, I don't think we should fudge extra ambient in, because it then might do weird things... ie, if the ambient light is really deep blue at a sunset one night, then a trees back side might go bluer than the environment around it and look a bit bodged.
Any extra light on the back side of a tree is powered by the sun only, so any effect needs to be tied to the sun directly, and that light is not ambient based. Power some extra emission from the sun diffuse value? Tint according to the sun diffuse value?




Just thinking out loud. You could maybe use a mip-map of the alpha map (softer and blurred), to power the halo effect on the tree? Use black as a template to add some emission to, and the mip-map will start to capture mainly the outer leaves of a tree.
The thinner the tree coverage with leaves, ie, the more likely sun will pass through and light more up in real life, then more the alpha will blur further into the tree, ergo the more the tree will get emission on the back side. Probably needs to be tied almost to only when you look through the tree with the sun directly behind it (almost total back facing normal?)


Also, just as a note David, currently I'm using CG generated tree textures/alpha maps, so aiming to not really have much natural lighting on them that I don't want. Photo-sourced trees tend to only ever look good when the track lighting matches the day the photos were taken on... not ideal really unfortunately, especially not in these days of TOD and stuff
Plus, getting good overcast day shots + good alpha channels, of trees, is hard

Dave

 

[2o6]

Can I borrow a shader? I'm using the one from the Lambo, and it's much too shiny. I want something less shiny and more akin to a painted surface rather than a colored mirror.

 

[Mr Whippy]

The Lambo is the right shader to use really.

What textures/shader values are you using in the car file itself? Any screen-shots showing the issue?

Thanks

Dave

 

[gtpdzbiz]

Hmm...it's a long time since the last post, here's a shader for headlights/brakelights (trying to mimic different luminance of head light at different view angle.)

Use the dyn_standard_v as vertex shader, then set up some specular and emission parameter in the shd file

i.e.
shininess=50
specular=1 1 1 1
emission=170 170 170 0

 

[Mr Whippy]

Nice work...

Camsinny and I were discussing that a bit, could also be handy for the car flares...

What do shininess and specular do, control the falloff of the light with angle and things?

Very nice if so

Dave

 

[Alex Forbin]

I don't use flares now that we have HDR.


Alex Forbin

 

[Some1]

I don't use flares now that we have HDR.

Well, headlights still create a flare at night even in human eye in real life, don't they?

 

[Alex Forbin]

Well, headlights still create a flare at night even in human eye in real life, don't they?

True,I should say I don't use the old style flares any more.
Try GTPs shader it expands on what I was doing and makes traditional billboard flares irrelevant.
With HDR all you need for flares is to overdrive the emissions, Gtpdzbiz amplified this by making the amount of emission relative to the angle of the normal. (haven't read the shader yet.)

Great job Gtpdzbiz!



Alex Forbin

 

[Some1]

True,I should say I don't use the old style flares any more.
Try GTPs shader it expands on what I was doing and makes traditional billboard flares irrelevant.
With HDR all you need for flares is to overdrive the emissions, Gtpdzbiz amplified this by making the amount of emission relative to the angle of the normal. (haven't read the shader yet.)

Yes, that shader looks very good for rear lights.
But you cannot get something like this with just hdr, can you?

 

[Mr Whippy]

Is the falloff adjustable?

Brake lights for instance have diffusors to help spread the light to be seen from more angles, while headlights are designed to focus the light. The example above looks a bit wrong with one brake light brighter than the other. Still a useful shader, and a great move forward, but we ideally need that tweak factor if possible


As for the flares, totally agree Alex. In real life flares are just the glare, or 'bloom' interacting with lenses.

The lens flare we see in Racer is 6 pointed iirc, so from a lens with 6 blades. To simulate the eye, you'd use an obstruction map more like an ellipse, with intrusions round the edge for eye lashes etc... the resulting blur of the glare would then be different.

I guess for most 'eye' adjustments for glare, the out of the box visuals seen are the most real (ie, in those screenshots)

What you'd need to do for lenses is blur the bloom map according to the blades of that lens.

Maxwell renderer for example, uses obstruction maps to do that, so you can simulate a lens, a dirty lens, video lenses, SLR lenses, wide open eyes, squinty eyes etc, which all make the glare appear differently



One danger of using really high emission values is they will also show up in other cars reflections really intensely, and possibly look wrong.

For brake lights intensity probably needs to be lower and the falloff lower, for headlights intensity probably needs to be high as it is, and a sharp falloff (probably sharper than it is)... afterall, headlights are DAMN bright when you are head on to them (ergo you get blinded)... but I've never been blinded by a brake light

Dave

 

[DavidI]

my issue with the current flares is that they look good at midnight, but at dawn/dusk & daylight they shouldn't be visible.

 

[Mr Whippy]

Yes, that shader looks very good for rear lights.
But you cannot get something like this with just hdr, can you?
View attachment 33632

Thats an 8 bladed aperture lens.

Ideally, I'd only want that effect in replay cameras.

From the driving POV, or 'eye' view, I just want it like in Alex's pictures.


It's a lot down to personal preference and also capability. I've asked that we have a camera 'type' be defineable so we can set things like this (ie, is it a camera, or an eye etc)


In theory, you can modify the glare/bloom pass to represent different patterns of diffusion of the light as it passes into the lens/es... in the train image above, the 8 blades of the aperture cause a pattern like blurring in 8 directions... not sure of the actual physical method, but as in my other post, high end renderers just use obstruction maps to generate these effects from 'raw' glare (what we have now in Alex's pictures, and is probably what is about right enough for a wide open human eye in a realtime game)

Dave

 

[Some1]

As for the flares, totally agree Alex. In real life flares are just the glare, or 'bloom' interacting with lenses.

The lens flare we see in Racer is 6 pointed iirc, so from a lens with 6 blades. To simulate the eye, you'd use an obstruction map more like an ellipse, with intrusions round the edge for eye lashes etc... the resulting blur of the glare would then be different.

Well, ultimately, I think the car maker should just specify where are the head light sources located, where they point, what are the light porperties etc.
And then Racer rendering engine should just create the proper lens flare/light flare according to the camera used in game...

I will stick with headlight flares, if some of their issues can be sorted out (like proper alignment wrt the camera, rotation perhaps, lighting wrt the tod).
The headlight flare shader I created for rFactor looked really good in game actually

 

[Mr Whippy]

my issue with the current flares is that they look good at midnight, but at dawn/dusk & daylight they shouldn't be visible.

They are visible in the daytime etc, they just need falloff applying correctly, and lots of other tweaks to make them work right.

Where GTP's and Alex's pictures/shaders are going is the right path for flares etc imo... the flare effect is a function of that items intensity in the scene at that current time relative to the camera.
All we need is a way to blur the bloom pass appropriately for different lenses, and we have this problem sorted in a way that will mean it's pretty robust (ie, it'll react right in all settings automatically once it's setup right )

Dave