[ 2.10 ] New Frob Shader

[duzenko]

I think it's time to replace the frob material stages with a shader (probably add a param to the existing ambient shader)

There is more than one angle to this issue but I am mainly concerned about too many stages in materials that are somewhat taxing in terms of performance.

Imagine rendering of 3K surfaces interacting with 3 lights in average and using materials with 7 stages in average.

The renderer loops through every stage for every surface making it ~ 20K checks per loop.

It has to happen during the depth stage, then each light and then the ambient pass resulting in 100K checks.

It makes sense to try to reduce this load, especially considering that the frob stage is relatively rarely invoked and the checks happen on the backend making it hard to parallelize the computation.

 

I am thinking adding a top-level material keyword that would apply as frob color and get passed to the ambient shader when the surface is a part of a frobable entity.

 

I would like to hear your thoughts from the mapper/designer POV.

[RPGista]

Thats great to hear! Anything that goes in the direction of better performance and efficiency is really welcomed,as the game remains notoriously heavy. Visually, at least for me, the frobbing mechanics have always felt like it works (the highlighting, etc) but nothing really unique, so theres room for improvement or change without much of a risk in terms of loss of identity or something. Im not sure you meant if this is an opportunity of also revising it in visual terms (as well as the egineering), but if so, Im sure there are more people who have played newer games and can come up with examples of cool options for the highlighting shader that would fit tdm.

 

PS: Did you have a visual concept in mind? Or you fell it should remain mostly the same?

Edited March 3, 2019 by RPGista

[VanishedOne]

My previous comment: http://forums.thedarkmod.com/topic/18990-custom-frob-idea/?do=findComment&comment=412240

Which links to: http://forums.thedarkmod.com/topic/11359-textures-that-need-love/page-2?do=findComment&comment=253435

 

If a new highlight couldn't be tweaked per material, cases like the dark bottles should be checked for visibility.

 

Can you give an example of how the new syntax would look? A 'top-level material keyword that would apply as frob color' sounds as though it takes a colour as a parameter. On the other hand STiFU wanted a globally player-configurable frob highlight.

[duzenko]

PS: Did you have a visual concept in mind? Or you fell it should remain mostly the same?

I'm not artistic. Without public consensus on visual changes I'd leave it look the same.

 

Can you give an example of how the new syntax would look? A 'top-level material keyword that would apply as frob color' sounds as though it takes a colour as a parameter. On the other hand STiFU wanted a globally player-configurable frob highlight.

It's still "per material", just not a separate stage

materialname
{
// this part goes
    {
        if ( parm11 > 0 )
        blend       gl_dst_color, gl_one
        map         _white
        rgb         0.40 * parm11
    }
    {
        if ( parm11 > 0 )
        blend       add
        map         models/md5/environments/rope_d
        rgb         0.15 * parm11
    }
// replaced with
    frobColor 0.15
}

The "0.40/_white" stage could be user- or mapper- configurable.

[peter_spy]

In its current state, frob shader isn't performance-heavy, as it adds stages and drawcalls only when activated, you can check it with showprimitives command. IMO the art/visual side of the frob is more problematic. It's time to ditch simple solid color solution and replace it with something more contrasty, working in all lighting conditions. Both cubemap and blend add + solid color solution are not enough, as they're washed out by bright lights.

[duzenko]

In its current state, frob shader isn't performance-heavy, as it adds stages and drawcalls only when activated, you can check it with showprimitives command. IMO the art/visual side of the frob is more problematic. It's time to ditch simple solid color solution and replace it with something more contrasty, working in all lighting conditions. Both cubemap and blend add + solid color solution are not enough, as they're washed out by bright lights.

Right, it does not send anything to GPU but see my OP - it makes the CPU do too much constant work when it filters the stages to decide if it has to send anything.

[VanishedOne]

materialname
{
// this part goes
    {
        if ( parm11 > 0 )
        blend       gl_dst_color, gl_one
        map         _white
        rgb         0.40 * parm11
    }
    {
        if ( parm11 > 0 )
        blend       add
        map         models/md5/environments/rope_d
        rgb         0.15 * parm11
    }
// replaced with
    frobColor 0.15
}

The "0.40/_white" stage could be user- or mapper- configurable.

With e.g. Judith having already raised suggestions about how to revise the look of the frob highlight (and the old frob.vfp having demo'd an alternative), I'm a little concerned about designing a syntax around the current set-up and its assumptions, like the assumption of a blend gl_dst_color, gl_one stage with _white and a blend add stage with the diffusemap. (tdm_pagan_orb_glow uses the standard 0.15 but applies it to _white. wbottle01 uses no multiplier at all in its first frob highlight stage - it just uses parm11 alone - and uses gl_one_minus_dst_color, gl_one with the diffusemap. In its second stage it uses 0.03 but with textures/darkmod/sfx/grey_mid.) The only thing you can really do with a single parameter is change the brightness multiplier, so we'd better be sure that's sufficient.

[Springheel]

I'm not artistic. Without public consensus on visual changes I'd leave it look the same.

 

It's still "per material", just not a separate stage

materialname
{
// this part goes
    {
        if ( parm11 > 0 )
        blend       gl_dst_color, gl_one
        map         _white
        rgb         0.40 * parm11
    }
    {
        if ( parm11 > 0 )
        blend       add
        map         models/md5/environments/rope_d
        rgb         0.15 * parm11
    }
// replaced with
    frobColor 0.15
}

The "0.40/_white" stage could be user- or mapper- configurable.

 

Would the old method continue to work for custom materials in missions? A lot of mappers include unique textures that need to frob.

[duzenko]

 

Would the old method continue to work for custom materials in missions? A lot of mappers include unique textures that need to frob.

The question is are willing to drop the frob stages in standard materials? If so, then those custom materials will work. Otherwise all parm11 stages have to be ignored.

[New Horizon]

As long as it looks nothing like the Deadly Shadows from. A mix of the classic Thief look with more attention brought to detail, rather than washing it out would be cool. Bringing attention to the edges of the item so it pops out of the background more.

[STiFU]

As I have already been cited here, I don't think I have to reiterate how I am all in favor of this undertaking. It is long overdue!! Thanks for diving into it. The first step should definitely to maintain the old look. Then when could add other alternatives that have improved visibility etc.

 

As long as it looks nothing like the Deadly Shadows from. A mix of the classic Thief look with more attention brought to detail, rather than washing it out would be cool. Bringing attention to the edges of the item so it pops out of the background more.

What you describe sound like a Deadly Shadows Frob Highlight minus the blue tint. :-)

[peter_spy]

IMO mappers should retain ability to write their own frob shaders. I had some fun with it, I'd love to experiment further with its look, and I only know the shader code, no programming language. TDS frob highlight is basically a cubemap overlay with blue tint, that can be useful if toned down a little. Without any color it actually looks like silver. But it does go away if there are strong lights around. Blend add stays there, but if it's a solid color across an object, you can't see it well either. You either need some kind of pattern, maybe like those diagonal stripes in Superhot shaders, or a "real" outline that is based on object shape and depth test. But isn't it even more expensive?

 

http://www.michalorzelek.com/blog/tutorial-creating-outline-effect-around-objects/

 

[peter_spy]

One thing I managed to do with existing code was to improve cubemap frob visibility a bit by using a slow pulse in alpha stage. Whether this is good or too in-your-face is another thing

 

https://www.dropbox.com/s/vvwiyyhmjr47a8e/frob2.1.mp4?dl=0

table frob_pulse { {.4, .6} }

(...)

	{
		if ( parm11 > 0 )
		maskcolor
		map makealpha (_white)
		alpha .5 * frob_pulse [time * .5]
	}

Edited March 4, 2019 by Judith

[Springheel]

The question is are willing to drop the frob stages in standard materials? If so, then those custom materials will work. Otherwise all parm11 stages have to be ignored.

 

It shouldn't be too hard to remove those stages from materials...just a search/replace for each file. It's an issue we'll have to solve one way or another though, as it's fairly common for missions to have their own textures, many of which need to have the frob stage.

[VanishedOne]

There are at least two materials that don't quite fit the standard pattern (and presumably there are reasons for that; in the case of the dark bottles, apparently it's for visibility), so a search script would hopefully be sophisticated enough to catch such cases.

 

At any rate, so long as the existing method still works, once those unusual materials are identified they can just be left alone.

[stgatilov]

In its current state, frob shader isn't performance-heavy, as it adds stages and drawcalls only when activated, you can check it with showprimitives command. IMO the art/visual side of the frob is more problematic. It's time to ditch simple solid color solution and replace it with something more contrasty, working in all lighting conditions. Both cubemap and blend add + solid color solution are not enough, as they're washed out by bright lights.

Maybe measure it?

Choose a room full of frobable stuff and quicksave there. Ensure high and uncapped FPS.

Then see FPS with current code, and FPS with all frobstages disabled.

I think it would be easier to add a hack in the code which ignores these stages on load, than to remove it in all materials.

Maybe run the profiler also if the picture is not clear enough.

I'm afraid the effect is hard to see directly by profiling, but in comparison it should be evident.

 

My guess would be that it does not have much impact, but I won't bet on it.

If artists want to change how frob-highlight looks, it would be great to do that at the same time.

[duzenko]

Maybe measure it?

Choose a room full of frobable stuff and quicksave there. Ensure high and uncapped FPS.

Then see FPS with current code, and FPS with all frobstages disabled.

I think it would be easier to add a hack in the code which ignores these stages on load, than to remove it in all materials.

Maybe run the profiler also if the picture is not clear enough.

I'm afraid the effect is hard to see directly by profiling, but in comparison it should be evident.

 

My guess would be that it does not have much impact, but I won't bet on it.

If artists want to change how frob-highlight looks, it would be great to do that at the same time.

I estimate the actual cost to be <1 fps but it's still nicer to to have two fewer stages in all frobable materials.

This might reduce the materials load/parse time by as much as 20%.

And fewer looped random memory reads in backend is never bad.

 

In the meantime I added a new cvar r_newFrob. SUDDENLY I discovered an existing, old-enough frob shader that @stgatilov luckily had just ported to GLSL 140.

It seems to work however looks more or less like the standard frob stages.

 

Anyone wants to play with it?

[peter_spy]

If artists want to change how frob-highlight looks, it would be great to do that at the same time.

 

Well, both yes and no. I mean, it would be great to have one material that works consistently for all objects, and in all lighting scenarios, but that never works in practice. I imagine that depth-test shader might be universal enough, but if you want to use a cubemap overlay, you'll often need two versions of a frob, one for total darkness, and one for brightly-lit setup. Same goes for blend add stage.

 

Cubemap reflection will look the same across all models. But if you plan to use e.g. a pattern with blend add stage only, that will depend on texture resolution, so you'd have to adjust it per object. I know that using frob stage per every individual material is tiresome, but it's also super flexible, and paradoxically, allows for greater consistency, if you know what you're doing.

[VanishedOne]

In the meantime I added a new cvar r_newFrob. SUDDENLY I discovered an existing, old-enough frob shader that @stgatilov luckily had just ported to GLSL 140.

It seems to work however looks more or less like the standard frob stages.

 

Anyone wants to play with it?

Would that be a port of frob.vfp? The reason it's unused is this bug: http://forums.thedarkmod.com/topic/10129-tdm-commands-and-variables/?do=findComment&comment=199639

[duzenko]

Would that be a port of frob.vfp?

Exactly

 

The reason it's unused is this bug: http://forums.thedarkmod.com/topic/10129-tdm-commands-and-variables/?do=findComment&comment=199639

How do I repeat it? That post does not go into details and it's been what - 10 years now?

We have seen ARB2 shader bugs disappear after porting to GLSL (as close to original as possible).

[VanishedOne]

How do I repeat it? That post does not go into details and it's been what - 10 years now?

We have seen ARB2 shader bugs disappear after porting to GLSL (as close to original as possible).

You'd use it in a material that's using a TGA as its diffusemap, and see whether you get a green tinge. I tried it at some point and the green was pretty obvious. I don't seem to have a record of which TGA texture I tried though.

Edited March 9, 2019 by VanishedOne

[duzenko]

Fixed the conflict with decals

I think this is ready for creative ideas

[stgatilov]

The r_newFrob 1 mode now uses the following formula:

Color += (0.7 + 0.3 * sin(time)) * (1 - cos(angle))

Where time is in seconds, and angle is the angle under which viewer sees the surface.

So the full strength varies from 0.4 to 1.0 with period of 6.28 seconds, and there is additional multiplier depending on angle.
If the surface is directly in the front, orthogonal to view, then multiplier is zero, and highlight disappears.
However, it is very strong on places which you see under low angles. Which is... pretty weird.
And if you look at large door, then you see a dark spot at the point you look at, which moves as you rotate camera.

I would say, this new frob looks and works completely different from the old one.
I understand the desire to "upgrade" something that was originally limited by closed engine, but in my opinion integrating something like this would mean retweaking a lot of existing materials.

[stgatilov]

Also it seems that the way it is integrated has its issues.

These things on the door must not be black.

[nbohr1more]

Thanks for the improvements. This type of effect "could" work but the strength needs to be toned down.

Coincidentally I fiddled with just a simple color = color + 0.04  shader and it looked sorta close to the current design but still had the strange hinges

and other textures. It seems to have trouble with specular materials?