 |
If the current highlight behavior is retained during the move to GLSL, we should make sure that SSAO is multiplied to the result. The current highlight overrides SSAO shading in most cases. |
|
|
Duzenko already did some work on this. See the "r_newFrob" cvar and commits 8051, 8052 See also: https://forums.thedarkmod.com/index.php?/topic/19915-208-new-frob-shader/ |
 |
Big burst of development (almost completely by Cabalistic): https://forums.thedarkmod.com/index.php?/topic/20878-new-frob-shader/ Frob-highlight outline was added in commits: r9290. Add Frob outline stage. r9291. Move gaussian blur shader to general utility shaders r9292. Migrate Bloom stage to fullscreen tri r9293. Migrate AO stage to fullscreen tri I believe the first commit changes behavior, while all the rest are some refactoring. For the development & testing period, the frob-outline is controlled by many cvars starting with "r_frobOutline". Forum posts: https://forums.thedarkmod.com/index.php?/topic/20878-new-frob-shader/&do=findComment&comment=459046 https://forums.thedarkmod.com/index.php?/topic/20878-new-frob-shader/&do=findComment&comment=459060 And one more minor commit: r9324. Frob outline is now full-white + disabled shader-based frob highlight. |
|
|
Picked up the torch, trying to make a bit less hacky depth-aware outline (and hopefully a bit more subtle). In fact, I restored and slightly tweaked the older prototype which Cabalistic created. First of all, let's draw outline for translucent surfaces. r9603. Do not drop translucent surfaces from render order, do not default diffuse map to white if not set explicitly. Because we cannot rely on surface highlighting for them, it usually has no effect (no diffuse map or black map), see e.g. atdm:moveable_flask1. As for the reason to default to black instead of white, check atdm:moveable_hourglass --- it gets full-white color otherwise. Added code path for new outline: r9605. Restored and tweaked a purely geometrical outline under "r_frobOutline 2". And improved the look of alpha-tested objects: r9607. Do not draw outline of an edge if its middle-point fails alpha-test. See e.g. atdm:moveable_food_turnip or atdm:moveable_gear_metal_fancy. Minor stuff: r9604. Forked frob_silhouette fragment shader into frob_flat and frob_modalpha. r9606. Fixed r_showTris with r_frobOutline 2. |
|
|
More changes: r9614. Support alpha-tested objects in image-based outline (r_frobOutline 1). |
|
|
Assigned to myself, because I'm still working on the outline. And the end goal (deleting material stages) is still far away. |
|
|
Two more fixes for image-based outline. I noticed that outline width was capped by edges extrusion, depending on resolution, so fixed it the right way: r9615. Use precise formula for extrusion radius for "r_frobOutline 1". Also changed the way how pixels on extruded edges and alpha-failed parts are treated: r9623. Major refactoring of frob-highlight + changed depth-aware image-based outline. |
|
|
Quick switching between many modes of outline that we have: r9626. Added r_frobOutlinePreset command, set hard geometric outline as default. Also fixed the problem of hard geometric outline with bloom: r9641. Added proper hard mode to geometric outline to avoid bloom sparklies due to overly high alpha. |
|
|
As of yet, the most popular option is the dark outline but there is no consensus. The real technical challenge still lies with transparent objects. The flask models ( for example ) do not highlight. This might be remedied by ensuring that the frob shader brightens the sampled reflection cubemap. In other words, the new frob will need to be both aware of: 1) multiple material stages ( brighten each and divide the brightness by the number of stages ? ) 2) OpenGL blend modes 3) Cubemaps vs 2D textures Probably much easier to add a keyword that allows asset authors to define what happens when these materials are frobbed { frobmap darkmod/textures/glass/example1 rgb 0.5 alpha 0.5 } Moving to 2.11 |
 |
I tried the new frob outline and for some reason it interferes with drawing func_beam. (You can see this under the floor grate in In The Black's chapel.) |
|
|
Svn rev 10139 implements conservative approach to frobhighlight stages problem (I call then "frobstages"). It does several things: 1) Added a few macros for typical frobstages, so that mapper does not need to write lots of stuff in material even if he wants to customize frobhighlight. 2) Warn about some unwanted behavior around frobstages. 3) If no frobstage is specified explicitly, then default frobstages are added implicitly. The macros look like this: frobstage_texture textures/darkmod/sfx/whiteglass2 0.15 0.4 Here we specify the image/image program to be added, then coefficient to multiply it on, then plain added color. frobstage_diffuse 0.15 0.4 In most cases diffuse texture is used for highlight, and this macro should be used then (less error-prone if you change diffuse texture in future). frobstage_diffuse (0.15 0.35 0.15) 0.4 Both multiplicative and additive color can be specified as RGB components, but then they must be encloses in parentheses. Note: negative values probable won't work =) frobstage_none A hack for the rare cases when author wants to frob-highlight on some surfaces of a frobable item. I'd say: never use it =) Speaking of warnings, let's introduce some rules: 1) A material stage is called "frobstage" if it has a condition with parm11 used in it. 2) Frobstage is said to have standard frob condition if its condition is exactly "if (parm11 > 0)". 3) Surface is called interactive if it has one of the following stages: bump, diffuse, specular. Note that in a typical case there are technically two frobstages (and the macros listed above usually add two). The conventions are: 1) You should not reference parm11 outside frobstage, otherwise you get a warning (but it still works as expected). This protects us from frobhighlight code which always works, i.e. which eats performance despite having no visual effect. 2) You should use standard condition in a frobstage, otherwise you get a warning (but it is still treated as frobstage). Now the last point is the main goal of this issue: *) If material is interactive but has no frobstages, then default frobstages are added. Default frobstages are equivalent to "frobstage_diffuse 0.15 0.4". Note that non-interactive materials don't get frobstages added. This is important e.g. for shadow meshes, which are normally not visible, but start being visible as black opaque if we add a frobstage. |
|
|
Fixed a bug in the code which broke all the macros: r10145 Fixed bug in frobstage_xxx parsing. Then cleaned core macros: r16633 Replaced (parm11 >= 0.5) with (parm11 > 0), removed commented ifs. r16634 Deleted test_frobhilight.mtr r16635 Added script for replacing frobstages with "frobstage_texture" macros. r16636 Applied remove_frobhighlight_1_texture.py: use frobstage_texture where possible. r16637 Added script for converting frobstage_texture to frobstage_diffuse and implicit frobstages. r16638 Used the second script to convert frobstage_texture to frobstage_diffuse and implicit frobstages. r16639 Added third script which deleted empty lines at the end of material definitions. r16640 Deleted empty lines at the end of every material. As you see, the cleaning consisted of three steps, with a Python script for each step saved to 'devel' directory. Manual intervention was only necessary at the beginning: to fix/delete non-standard frob conditions. The .mtr files are much more compact now, since all materials with "default" frobstages have zero text about them (they are added implicitly). Now we can search for keywords: parm11 frobstage_texture frobstage_diffuse And see if these materials intentionally use some special frobstages, or they are just buggy. |
|
|
A small bugfix here: r10145 Fixed bug in frobstage_xxx parsing. |
- Anonymous
