[2.08] New frob shader

[stgatilov 1127]

I'm sorry to be ignorant about the topic. But to me the only annoyance is a lot of copy/pasted text in materials. And the fact that if mapper forgets to copy/paste it, then the object won't frob-hightlight even if it is frobable. I don't want to spend much time on it, tweaking it, fixing FMs, arguing with mappers, etc. Just wrap the mess and go away

And I agree with @peter_spy that customization must be preserved. And the current system seems to work fine in this regard. And saving its behavior exactly has a major benefit that all the tweaks applied by authors to specific materials will continue to work as before.

The easiest solution would be to introduce FROB_MACRO(alpha, beta), which would simply be replaced with these if-s by engine on load (just like there is DECALMACRO). alpha and beta are the coefficients 0.15 and 0.40.

It is harder to add frob highlight by default to new materials and maintain custom-tweaked material at the same time.

[STiFU 728]

10 hours ago, stgatilov said:

I'm sorry to be ignorant about the topic. But to me the only annoyance is a lot of copy/pasted text in materials. And the fact that if mapper forgets to copy/paste it, then the object won't frob-hightlight even if it is frobable. I don't want to spend much time on it, tweaking it, fixing FMs, arguing with mappers, etc. Just wrap the mess and go away

And I agree with @peter_spy that customization must be preserved. And the current system seems to work fine in this regard. And saving its behavior exactly has a major benefit that all the tweaks applied by authors to specific materials will continue to work as before.

The easiest solution would be to introduce FROB_MACRO(alpha, beta), which would simply be replaced with these if-s by engine on load (just like there is DECALMACRO). alpha and beta are the coefficients 0.15 and 0.40.

It is harder to add frob highlight by default to new materials and maintain custom-tweaked material at the same time.

I don't get it. Why should the MAPPER decide how the frob highlight looks? It is basically a GUI-feature that communicates to the player whether an object can be interacted with or not. With regards to accessibility, it should totally be up to the PLAYER to pick a frob highlight that works well for them. Also, if frob highlight is changed, it should definitely be changed globally and not on a per-material level. Imagine one door having our old frob highlight and another having a new crazy TDS-like frob highlight. That would be totally unprofessional and every player would ask "WHY? Just Why?"  Frob highlight is not something artistic, but a GUI-Feature that must be consistent.

The current frob highlight also has severe problems, as @peter_spy also said himself: In a bright scene you cannot (or just barely) see if an object is highlighted. That's the main reason, why we need a customizable new frob highlight. To my knowledge, there also have not been any customizations of the frob highlight other than making it brighter or darker, to account for this exact problem I just described.

Custom-Materials in FMs etc. can be handled by simply ignoring the frob highlight stage in all parsed material definitions. It can be identified via the parm11 reference.

[Dragofer 1348]

I think a frob macro would be a good intermediary and seemingly time-efficient solution for making our material system more user-friendly. I'd still note that it should probably also include a reference to the diffusemap and maybe _white, in addition to alpha and beta values.

A more definitive, material-free solution that also addresses the visual problems with our existing system would be best, of course, but it's clear it's not straightforward.

As for mappers using custom frob highlights in existing missions, I'm not really aware of that having happened to date. IIRC peter_spy's custom Builder assets have some specialised frob highlights and they were used in a couple missions, i.e. Skulduggery 3.

[OrbWeaver 617]

I too am rather skeptical of an ongoing need for per-material frob customisation, but ultimately I am not a mapper and if experienced mappers say they have needed it, I can't really contradict them.

Nevertheless, for the main bulk of materials which do not need per-material customisation, I don't understand what benefit a macro (which the material author must remember to manually include in every material he creates) provides over simply doing what the macro would do in the C++ code, automatically, for every material. This would not even prevent the use of customisations: the behaviour could be to implement the basic frob for all materials automatically, unless specifically overridden with a material stage or keyword (e.g. override_frob { ... }).

[Springheel 4628]

1 hour ago, OrbWeaver said:

I too am rather skeptical of an ongoing need for per-material frob customisation, but ultimately I am not a mapper and if experienced mappers say they have needed it, I can't really contradict them.

Are there any mappers making that claim?  I can't think why that kind of support would be needed either, other than perhaps the ability to choose between two different pre-provided types of frob (if we decided one day to give loot objects a different type of frob effect).

[Dragofer 1348]

2 hours ago, OrbWeaver said:

Nevertheless, for the main bulk of materials which do not need per-material customisation, I don't understand what benefit a macro (which the material author must remember to manually include in every material he creates) provides over simply doing what the macro would do in the C++ code, automatically, for every material.

My main concern is shortening or eliminating the repetitive frob stages from every material, so both approaches would work. A macro would probably make it easier for mappers to modify default behaviour by just changing the numbers or the texture path, but I'd prefer to just have a wiki entry describing how to get custom behaviour.

 

1 hour ago, Springheel said:

I can't think why that kind of support would be needed either, other than perhaps the ability to choose between two different pre-provided types of frob (if we decided one day to give loot objects a different type of frob effect).

The default frob highlight is basic & generic, so I can imagine mappers wanting to get different effects the same way they would want a custom menu cursor or background. Really they should be able to add any kind of material-based effect they want - i.e. animated textures, pulsating intensity - using the same rules as the rest of the material system.

 

Perhaps the main issue why frob highlights have rarely been changed so far is that it could only be done on a per-material basis. This makes a global change to frob highlighting completely impractical. Perhaps the most mapper-friendly approach could be to implement default frob behaviour as an own material definition, which applies to to all materials by default and can easily be changed by a mapper. If a mapper wants multiple types of frob effects, it'd be good to allow him to make new frob materials and apply them either to materials or to entities (as spawnargs).

[STiFU 728]

1 hour ago, Springheel said:

(if we decided one day to give loot objects a different type of frob effect).

That would be the ultimate goal, yes!

https://bugs.thedarkmod.com/view.php?id=5428

[Springheel 4628]

7 minutes ago, STiFU said:

That would be the ultimate goal, yes!

https://bugs.thedarkmod.com/view.php?id=5428

Personally, I'd be interested in looking at new frob visuals...I don't think any kind of brightening effect is going to solve the problem of seeing the effect in bright rooms.  A subtle outline might be the way to go, and we could colour code it....white for regular objects and yellow for loot, for example.

[STiFU 728]

2 minutes ago, Springheel said:

Personally, I'd be interested in looking at new frob visuals...I don't think any kind of brightening effect is going to solve the problem of seeing the effect in bright rooms.  A subtle outline might be the way to go, and we could colour code it....white for regular objects and yellow for loot, for example.

Yes, that too, of course. I already outlied above how the current frob highlight is problematic.

[Filizitas 108]

It is very subjective if you say that the frob is boring, i personally like it just fine.

You shouldnt give this to authors, go to the top floor and give it directly to players.

Make an option in the settings for different frob options.

I can say these things because critics of my work have spoken to me, about my frob highlight and so i decided to implement a setting row for the user, in the settings menu.

[STiFU 728]

Peter_spy just sent me a PM:

1 minute ago, peter_spy said:

I was about to reply to the thread but it was moved while I was writing.

I just wanted to say that I agree with your notion that maybe frob code should be taken away from mappers. I remember one mission using my Builder Compound assets, where mapper didn't bother to remove my custom frob, so there were two frob systems in place It was also weird that testers didn't report it.

I'd vote for that outline in the video I posted, that should work in most lighting scenarios. Just choose some light grey/ash white outline and lock it, something in RGB 192-224 should work nicely. Or, maybe let people change it via console command.

As a bonus, I'd leave an option to make your own frob code to those who know what they're doing, i.e.:

1) If there's no frob code in the material, use the default one.

2) If someone uses if ( parm11 > 0 ) clause in their stage, let it overrride the defaults. Or something like that.

You can copypaste all this in the frob thread if you want to

 

[cabalistic 736]

If no one else wants to, I could look into creating an outline effect for highlighted objects. Probably after 2.09, though, or as a "late" addition to the beta, at best.

[stgatilov 1127]

11 hours ago, cabalistic said:

If no one else wants to, I could look into creating an outline effect for highlighted objects. Probably after 2.09, though, or as a "late" addition to the beta, at best.

You are really welcome.
As far as I understand, the outline effect cannot be implemented with a material shader alone, and requires some C++ support.

To be honest, I have a feeling that any type of single-color brightening will be hardly visible under some conditions.
Either mixed brightening + darkening or multi-color brightening is needed to cover all cases.

[STiFU 728]

13 hours ago, cabalistic said:

If no one else wants to, I could look into creating an outline effect for highlighted objects. Probably after 2.09, though, or as a "late" addition to the beta, at best.

As a first step, though', we should try to achieve feature parity between the material-hack and the new GLSL implementation, so we can finally get rid of that hack. That means 1) to create the same look as the one created by material defs and 2) make sure all attachments (hinges in screenshot) are also highlighted. @duzenko, did you maybe just forget about the attachments?

I would love to see a cvar for choosing from multiple frob highlights as there are some thief fans that don't like fancy frob highlights, so I would like to retain an option for them to keep the original frob highlight.

Something else to consider is a rather simple TDS-like frob highlight. It utilized the normalmap to add a blue-tint from the left side of the object. I know back in the days it got a lot of hate, but it actually worked well in many lighting situations. I can also see a mixed brightening and darkening with this approach, as @stgatilovsuggested.

[peter_spy 1529]

Oh, I have access to the thread again.

I'd suggest starting with something simple, and not considering all the possibilities that arise in our heads.

First off, a simple color outline. That kind of thing is used in Dishonored for example, and it looks decent in all lighting conditions. If that's not enough, then you can worry about the next steps. From what @cabalistictold me, the video example I provided is a post-process effect, so that may solve the problem of different lighting setups.

Edited December 13, 2020 by peter_spy

[duzenko 654]

2 hours ago, STiFU said:

As a first step, though', we should try to achieve feature parity between the material-hack and the new GLSL implementation, so we can finally get rid of that hack. That means 1) to create the same look as the one created by material defs and 2) make sure all attachments (hinges in screenshot) are also highlighted. @duzenko, did you maybe just forget about the attachments?

It's one of those alpha bugs, things that get fixed after someone notices and reports it

[peter_spy 1529]

.

Edited December 13, 2020 by peter_spy

[peter_spy 1529]

Tried changing frob code for door_104x56_2hinge, which also uses alphatest hinges:

This is one object with multi-material setup (annoyingly enough, it uses 4 materials in 2 different material files ), but it works correctly.

[Springheel 4628]

Quote

there are some thief fans that don't like fancy frob highlights,

 

I think that's true for the majority of players, Thief and TDM.