Specular Too Strong?

[Spooks]

I've noticed that even if I have nospecular on a big light, there's still an awful much of fresnel reflections going on. I was going to reopen http://bugs.thedarkmod.com/view.php?id=4292 but after double checking the test map I uploaded back in '16 I see that no, the nospecular argument actually does work. It's the default specular you get with Enhanced Interaction Shader. Disabling that fixes the issue.

 

I definitely remember the fresnel not being as strong as it is now, can somebody (thinking either nbohr or duzenko) check if the default values in the shader have been altered or otherwise messed up?

[nbohr1more]

I'll double check but I recall Ungoliant complained about this when we originally released v1.03 (HDR-lit, Enhanced Interaction, etc).

One thing I would check is the alpha channel of your specular, it seems that Doom 3 has always had the ability to change specular

strength based on the alpha channel but nobody has been using it.

 

Other than the above? Perhaps some of Bob Necro's textures came with new speculars?

[nbohr1more]

SVN shows no changes to the test_direct.vfp program since 2012 and test.vfp in 2014 (pre v2.03)

[Springheel]

Do you have an example of where this is happening? I'm wondering if it's related to something I've been noticing.

[Spooks]

As I said, I tested it on the testmap I uploaded in the aforementioned bugtracker. If you focus on the walls of the testroom and not the floating cubes, you can see that the light that's supposed to have nospecular still provides quite a strong shine.

[nbohr1more]

Hmm. It was working when I closed that ticket.

 

The shader wasn't where I solved it though.

 

It was where the engine branches to decide which tris get specular passes.

 

There was an uglier solution which would require creating multiple vfp versions for specular vs non-specular but I wasn't looking forward to that one.

(Though it would potentially perform better.)

 

Edit: Code is still there, so nothing got clobbered during the commits in v2.05:

 

 

 
case SL_SPECULAR: {
                    // ignore stage that fails the condition
                    if ( !surfaceRegs[ surfaceStage->conditionRegister ] ) {
                        break;
                    }
                    // nbohr1more: #4292 nospecular and nodiffuse fix
                    else if ( backEnd.vLight->lightDef->parms.noSpecular ) {
                        break;
                    }    
                    else if ( inter.specularImage ) {
                        RB_SubmittInteraction( &inter/*, DrawInteraction*/ );
                    }
 

[nbohr1more]

OK, so the test shows that when I set all lights to nospecular, the heavily shiny specular texture with the writing disappears.

 

So the functionality is there.

 

Now, I do see that there a baseline amount specular no matter when is being projected.

 

That was an artistic decision by JC Denton to try and elevate the quality of our asset look rather than

making the TDM team need to redesign all their materials for v1.03.

 

I guess I can go the hard route and make the nospecular really strict by making vfp versions for it.

[duzenko]

I guess I can go the hard route and make the nospecular really strict by making vfp versions for it.

[chanting] GLSL! GLSL!

 

No, really, I think rewriting that shader in GLSL should happen soon anyway, so why do extra work?

[Spooks]

That's the thing, I do know of the baseline level of fresnel but I never remembered it being this strong. Memory's a poor judge, so if all the numbers are the same, it must be fine. As for splitting the specular into separate glprogs, I can't give an opinion on that, but duzenko's right in that we should be transferring to GLSL in general. I remember him saying he finally added support for it in #4431.

[nbohr1more]

[chanting] GLSL! GLSL!

 

No, really, I think rewriting that shader in GLSL should happen soon anyway, so why do extra work?

 

Yes, the proper way to do this is to take advantage of shader branching. I remember looks at the backend awhile back

and seeing that it creates black textures for any stage not supplied in a material so that the ARB shaders always have a texture input...

(and I thought that was pretty dumb).

 

Branching would also solve the issue were TGA normal maps require a different interaction than RGTC or other compressed formats.