Racer and glass

My QLOG is clear and it's still doing it, so I'm guessing it's something else...


Now I'm having issues with certain shaders not showing up behind glass, despite them working earlier on... I still get mightily confused with how all the transparency stuff works... ie, where to use blendfuncs, alpha to coverage, whatever else etc etc...

Seems overly complex to me still from an authoring POV. I want it see-through, that is all an author should need to worry about imo. The rest should be hard coded in shaders we reference I think.

Dave
 
Well Ruud has offered a fix in the shape of an altered line in lighting.cg which technically should fix the issue generally for any kind of material.

I'm sure that will make it into the next release of Racer.

The problem is basically that shininess can get to 0, and since this shader has a shininess control map that can be set at black it means shininess = 0 and that does weird things with the resulting specular intensity (black hole divide by zero stuff), thus we get a few super black pixels here and there and they then make Racer think it's gone dark even though it hasn't :D



It's starting to make me wonder about the AE systems and metering and how a modern DSLR does metering... perhaps having some kind of multi-point sampling in the view and then have Racer try find the best exposure that way... hmmmm...

Cheers

Dave
 
Yeah, I guess flexibility in the control map (adjusting reflection/specular) means another avenue to impossible values being entered. Good to hear it's fixed now.

It makes sense to do a version of this with just the single texture layer using alpha to key transparency, and a constant reflection/specular across the entire material. Maybe just a tweak to dyn_standard_reflect_window_f - it should produce the most 'glass-like' results from the least author input (ideally, copy "vf_window" from a standard vehicle, input the layer0 texture, and that's it), and anyone who needs more functionality can use the transparency_window fragment shader.

I'm thinking something like
Code:
; standard transparent window shader
vf_window
{
  reflect=1.0
  shininess=20
  cast_shadow=0
  vertex_shader
  {
    dyn_standard_reflect_window_v.cg
  }
  fragment_shader
  {
    dyn_standard_reflect_window_f.cg
  }
  fresnel
  {
    bias=0.04
    scale=0.96
    power=4.5
  }
  layer0
  {
    alpha_to_coverage=1   ; maybe not this line?
    blendfunc=blend
  }
  layer1
  {
    map=$trackenvmap
  }
}

Then the actual shader is as simple as
Code:
shader_matglass~vf_window
{
  layer0
  {
    map=glass.tga
  }
}
 
That is a good idea.

Perhaps we need to start providing or offering 'definition' files so we load those in our car.shd files... there are loads of things that don't really need to be author set for realistic results.
Most of it should just be inputting the textures and/or swatch colours pretty much.


The super fancy glass shader is nice but ultimately it does have a lot of redundancy, I'm not using the tex0 rgb data at all since it's all just straight transparent glass type materials, and the tex0 only has the green transparency channel actually used hehe.

Technically I could get away with a mono channel and set the other params, reflect 100%, specular none, diffuse/ambient none (I think tints are so subtle in practice there isn't much point using them.

Still, in theory we could get rgb.a covering colouring and transparency with a fixed 100% reflection etc.


I'm now doing the black around the edge of glass as a different material, it's probably cheaper as you don't have a big texture with generally the same info all over it, to define what a few polygons and a second shader can do any way.


Hmmm

Dave
 
Perhaps we need to start providing or offering 'definition' files so we load those in our car.shd files... there are loads of things that don't really need to be author set for realistic results.
Most of it should just be inputting the textures and/or swatch colours pretty much.

I have been saying this for years. Have somekind of definition file in data/renderer/materials.ini or something like it which contains the shader settings for each type of shader (for example "vf_window" and then in car.shd we can simply say shader_myglass~vf_window { set textures and other specific blah }. We wouldn't even need to explicitly include the definitions file in the car.shd...
 
Arghhh, Racer and transparency these days :D

In the old shader system it just worked, but now all this alpha to coverage and what not is just so non-sensical I have no idea what it does, despite repeated (and lost) posts by Ruud explaining it all in old threads :(


This is exactly where an author just hits a brick wall when imo it should be easy and intuitive...


OK, any help would be much appreciated.

I am using this new glass shader for glass, great. Works nicely and everything.

But now I'm trying to get my vf_standard (standard dynamic) material to show up underneath the lenses which is using a special blendfunc.
The reason is the items are light glows and I don't want to create a separate map for them, I just want to use an existing one.
Technically new geometry is loaded for lights so you get another render call so loading another texture shouldn't cost extra but hey I'm doing it my way.

So the lights shader is this:

Code:
shader_lights_glow~vf_standard
{
    sort_offset=1
  compression=0
  ambient=1 1 1 1
  diffuse=1 1 1 1
  emission=15 15 15 15
  specular=0 0 0 0
  shininess=12
  layer0
  {
    map=texture\details.tga
    blendfunc=src_color one
  }
}

I had to put sort_offset=1 on the glass shader to make another shader that is under the glass show up which is just a vf_bump_reflect type.

But this glowing shader just won't work and it's basically not working when I turn the blendfunc on... but that is essential to get the map to basically blend according to the pixel rgb intensity which makes loads of sense for emission mixing for glowing lights etc!


What do I need to do to get the shader to show up? sort_offset doesn't do anything.

Is it alpha to coverage but that makes glass look horrible and stippled? Is it something else like depthwrite?

Super confused again :D

Why do things need these special syntaxes to work? Can't all this be done in the main shader itself, or get more intuitive names, ie:
"Make things underneath show up = 1" :D

Dave
 
Arghhh, Racer and transparency these days :D

In the old shader system it just worked, but now all this alpha to coverage and what not is just so non-sensical I have no idea what it does, despite repeated (and lost) posts by Ruud explaining it all in old threads :(


This is exactly where an author just hits a brick wall when imo it should be easy and intuitive...


OK, any help would be much appreciated.

I am using this new glass shader for glass, great. Works nicely and everything.

But now I'm trying to get my vf_standard (standard dynamic) material to show up underneath the lenses which is using a special blendfunc.
The reason is the items are light glows and I don't want to create a separate map for them, I just want to use an existing one.
Technically new geometry is loaded for lights so you get another render call so loading another texture shouldn't cost extra but hey I'm doing it my way.

So the lights shader is this:

Code:
shader_lights_glow~vf_standard
{
    sort_offset=1
  compression=0
  ambient=1 1 1 1
  diffuse=1 1 1 1
  emission=15 15 15 15
  specular=0 0 0 0
  shininess=12
  layer0
  {
    map=texture\details.tga
    blendfunc=src_color one
  }
}

I had to put sort_offset=1 on the glass shader to make another shader that is under the glass show up which is just a vf_bump_reflect type.

But this glowing shader just won't work and it's basically not working when I turn the blendfunc on... but that is essential to get the map to basically blend according to the pixel rgb intensity which makes loads of sense for emission mixing for glowing lights etc!


What do I need to do to get the shader to show up? sort_offset doesn't do anything.

Is it alpha to coverage but that makes glass look horrible and stippled? Is it something else like depthwrite?

Super confused again :D

Why do things need these special syntaxes to work? Can't all this be done in the main shader itself, or get more intuitive names, ie:
"Make things underneath show up = 1" :D

Dave

Dave, firstly, alpha_to_coverage is just a dithered way of blending a texture without doing actual blending. It should mostly used for trees because there are usually many trees behind many trees that all need transparency but blending is too costly and would cause sort issues.

Secondly, try to "sort_offset" all of your shaders and use bigger sort offset values. Also, I don't remember, if this is still the case, but once reordering the shaders in the shd file would also give different sorting results.
 
Hmmm, thanks for the tips there Siim.

I did have some weird results with big sort_offsets. Setting my shader above to sort-offset 10000 made it go super-bright. Setting it to -1000 made it go super black and made the auto-exposure fly right up... so it felt like sort_offset was scaling the output of the pixels... weird! (to do with my blend function?)

I remember Ruud once posted the details of the base offsets for different materials, so say transparents are set 100 above non-transparent materials to start with.


I did try using a control texture and standard shader with blendfunc=blend and emission (like the Lambo lights for example) but even that didn't show up under this fancy glass shader!

I wonder if it's to do with this fancy glass shader? Hmmmm

Dave
 
Using a covered headlight example might help try this...
Chrome_reflector:
sort_offset=0

headlight_glass:
sort_offset=1

Glass cover:
Sort_offset=2
This works fine for me, the offset isn't really a distance (IIRC) but a simple sort order.

Alex Forbin
 
Hmmm, tried that and no luck here hehe.

They are certainly there as if I zoom in then as soon as the glass is clipped the glowing bit appears.


The shiny interior elements of the lights lenses do disappear if I make the glass sort_offset = 0, so only the standard diffuse/spec materials are visible, but setting it to 1 makes the refmap bump mapped details in the headlights appear.

So I think there is something similar happening here but I'm not sure why it's not working with the sort_offsets.

I'll shoot an email to Ruud and maybe he'll give me some clues :D



Has anyone had this fancy glass shader working showing anything underneath it with a blendfunc? It's the only thing I haven't tried to change yet (ie, to the old glass shader)...
The old glass shader is working fine here on the Lambo with lights underneath and the glass shader is the only thing different, hmmmm :(

Dave
 
Hmmm, tried that and no luck here hehe.

They are certainly there as if I zoom in then as soon as the glass is clipped the glowing bit appears.


The shiny interior elements of the lights lenses do disappear if I make the glass sort_offset = 0, so only the standard diffuse/spec materials are visible, but setting it to 1 makes the refmap bump mapped details in the headlights appear.

So I think there is something similar happening here but I'm not sure why it's not working with the sort_offsets.

I'll shoot an email to Ruud and maybe he'll give me some clues :D



Has anyone had this fancy glass shader working showing anything underneath it with a blendfunc? It's the only thing I haven't tried to change yet (ie, to the old glass shader)...
The old glass shader is working fine here on the Lambo with lights underneath and the glass shader is the only thing different, hmmmm :(

Dave

Hmm... I never use blendfunc=blend for glass shaders, since it will spawn an armada of z-sorting issues.
blendfunc=one one_minus_src_alpha works best for me.
 
Yeah, it does work for me. Although only one way (you can see the RX7's glass through the Aronde, not vice versa). Didn't have anything better to test with.
ncPYe.jpg


RX7: default sort_offset, dyn_standard_reflect_window2_*.cg, blendfunc=blend
Aronde: sort_offset=60, dyn_standard_reflect_transparency_window_f.cg, blendfunc=blend

The 'window2_f.cg' the RX7 is using is very nearly a copy of window_f.cg, one line different:
Code:
  outColor.a = baseCol.a
==>
  outColor.a = lerp(1.0,baseCol.a + fresnel - fresnel*baseCol.a,IN.extinction);
I guess this is one of the changes mentioned earlier in the thread. Quite likely it'd be fine to adopt this in window_f.cg.

The blendfunc=one one_minus_src_alpha gave me issues with the sky, I think because it passes a 'wrong' alpha. I do use that for the Aronde's headlights, since the only thing behind them is always going to be the interior mirrors.
 
I'm guessing my "src_color one" blend makes sense to basically "add" a glow for a light based on the glows rgb value.

rgb near 0 = no addition to the existing pixel colour at that point, rgb near 255 means lots of addition, and then the emission value multiplies it even more?

I may just revert to a classical brakelight/headlight texture with alpha to mix on another texture sheet, just seems a waste but I guess technically I have a new shader when lights are active and the light elements are independent geometry too so a new pass will be needed irrespective of the texture distribution. The only real cost is texture space but it isn't really a significant size, maybe 256x128 textures for the lights :D

Hopefully that will then work like any old glowy materials inside headlights... probably also easier to get the right look with an alpha channel and rgb channel vs just using rgb intensity to do the mixing :D

Dave
 

Latest News

Online or Offline racing?

  • 100% online racing

    Votes: 84 7.3%
  • 75% online 25% offline

    Votes: 122 10.6%
  • 50% online 50% offline

    Votes: 167 14.6%
  • 25% online 75% offline

    Votes: 320 27.9%
  • 100% offline racing

    Votes: 449 39.2%
  • Something else, explain in comment

    Votes: 4 0.3%
Back
Top