Jump to content
The Dark Mod Forums

[ 2.10 ] New Frob Shader


duzenko
 Share

Recommended Posts

1 hour ago, wesp5 said:

Another argument to replace the frob helper with the frob outline option as the former never made much sense to me.

Indeed, Why do you need an extra dot on an already highlighted object.

"Einen giftigen Trank aus Kräutern und Wurzeln für die närrischen Städter wollen wir brauen." - Text aus einem verlassenen Heidenlager

Link to comment
Share on other sites

The frob helper is an aiming helper that makes it easier to correctly aim at small objects, either to frob them or in other circumstances like throwing objects (e.g. knocking the key down from the window ledge at the beginning of St Lucia). It doesn't provide any benefit when you've already highlighted something, but I don't think that's its intention.

I hope the frob helper is not removed, but it might be appropriate to rename it to something like "Aiming helper".

  • Thanks 1
Link to comment
Share on other sites

1 hour ago, OrbWeaver said:

The frob helper is an aiming helper that makes it easier to correctly aim at small objects, either to frob them or in other circumstances like throwing objects (e.g. knocking the key down from the window ledge at the beginning of St Lucia).

Is throwing in TDM so linear that an aiming point can help or do you mean it's like a crosshair for the bow? I never use it and with the box-while-frobbing-info from above it could indeed be renamed to crosshair or similar.

As for r_frobIgnoreDepth 0, this should indeed be the default as it gets rid of the worst of the not-antialiasing artifacts. I still think there should be an option to turn the outline off completely, for visual and gameplay reasons.

  • Like 2
Link to comment
Share on other sites

I've just been trying 2.10 (specifically 16342-9552) with my FM in progress, and have some concerns about the new frob highlighting, which I rather liked on first impression -

- I went to some effort to hide loot items behind movables, and now they are instantly exposed. Ugh. It is not enough to say, well, the player can set "r_frobIgnoreDepth 0". I want the mapper to have more control. One way would be to have frobIgnoreDepth 0 as the default. Another would be to have a new spawnarg available (maybe "frobhaloclip 1"?) that the mapper could set on an occluding entity, that would override frobIgnoreDepth 1 just for that object. Or generalize to also blocking the frob itself through that object (then maybe "frobstop 1"?). I'm aware of frobblock, but not sure that's practical with non-chest movables.

- I'm seeing a severe, distracting visual artifact when a frob halo is active (and at certain angles/distances). Other entities in the scene often have rapidly pulsating textures. For example, instantiate the prefab furniture/tables/desk3_old.pfx. As you frob the openable drawers, these items will exhibit the problem: feathers of pen quills, translucent glass panels, sails on ship model. I have also seen this with the backwall of bookcase models. One hypothesis is that two-sided shaders on patches are particularly prone to this; are they z-fighting with themselves? (If you don't see this, maybe its just my graphics hardware.)

Edited by Geep
Add "non-chest" as qualifier
Link to comment
Share on other sites

On 8/20/2021 at 3:45 AM, Geep said:

 I'm seeing a severe, distracting visual artifact when a frob halo is active (and at certain angles/distances). Other entities in the scene often have rapidly pulsating textures. For example, instantiate the prefab furniture/tables/desk3_old.pfx. As you frob the openable drawers, these items will exhibit the problem: feathers of pen quills, translucent glass panels, sails on ship model. I have also seen this with the backwall of bookcase models. One hypothesis is that two-sided shaders on patches are particularly prone to this; are they z-fighting with themselves? (If you don't see this, maybe its just my graphics hardware.)

Do you have stencil shadows enabled?
Does the flickering go away if you switch to shadow maps?
If you KO a guard and frob-highlight the body, do you see same flickering?

I had such issue with guard bodies, and did a small fix which (for not very clear reason) fixed the problem for me. I guess I'll publish a new dev build soon.

 

As for the ease of discoverability of secrets, that's an interesting question.
Somehow, we thought it is not a big problem, and in fact can be a benefit (detect items frobable through walls and such), but now it seems to be a real issue.

By the way, when I could not find something, I often walked around the rooms of interest while constantly frobbing all walls/tables/everything...

  • Like 1
Link to comment
Share on other sites

About the visual artifacts. Yes, this is with stencil shadows.
Will try the experiments you suggest in a while.

BTW, I mentioned limitations to my graphics hardware, that could be related. Details below.

Spoiler

I have an Intel NUC box for development (specifically, NUC5i7RYH), which has an embedded (non upgradable) Intel Iris graphics chip. I'm thinking Intel has stopped updating OpenGL drivers for this chip.

Relevant console messages under 2.10 dev (2.09 is similar), comments in []:

Checking optional OpenGL extensions...
X GL_EXT_depth_bounds_test not found
X GL_ARB bindless_texture not found
X GL_ARB_campatibility not found
[X= failed. All other required & optional extensions OK]

Linking GLSL program shadowMapNG...
Warning: Linking program shadowMapNG failed:
The fragment shader uses varying texCoord, but previous shader does not write to it.
Out of resource error

About the ease of discovery, I was looking into if any existing geometry or texture could block frobbing of things behind it, without itself being frobbed. Evidently not. If something new were to be created, my thinking now is that, rather than "frob shield" texture or class, better would be a special spawnarg (say, frobstop 1) that could be applied to any non-frobbable object. In the code, it would initially act as if the object *were* frobbed, except it wouldn't highlight or do any frob actions.

Maybe it could be applied to worldspawn too, but then would affect all worldspawn.

Not quite making this a "feature request" in the bug tracker yet. Depends on what others think.

Link to comment
Share on other sites

@stgatilov, when I knocked out my smuggler and highlighted him, I did see pulsating on certain metal or shiny parts like teeth, buttons, belt buckle. And nearby bushes made of patches. When I switched to shadow maps, all that pulsating went away! So sounds very much like what you were seeing.
 

Link to comment
Share on other sites

1 hour ago, Geep said:

Maybe it could be applied to worldspawn too, but then would affect all worldspawn.

But this would not help the hundreds of already existing missions where the new highlight could reveal secrets the authors were hiding on purpose. If this can't be fixed by setting r_frobIgnoreDepth 0 as default I don't think the highlight should be included at all! I still remember how the core team refused to include exstinguishable oil lamps because this might affect existing missions. This seems to me much worse...

  • Like 2
Link to comment
Share on other sites

I agree that the default should be either the existing highlight or the new highlight with r_frobIgnoreDepth 0.

I was thinking beyond that, if the player can override the default in favor of r_frobIgnoreDepth 1. Then the mapper might want to selectively override the override with frobstop.

Link to comment
Share on other sites

16 hours ago, stgatilov said:

By the way, when I could not find something, I often walked around the rooms of interest while constantly frobbing all walls/tables/everything...

Just turn on the wireframe and you will see the switch on the underside of a desktop as a blob of tiny tris... 

Link to comment
Share on other sites

Time I think to revisit the debate: set r_frobIgnoreDepth to 0 by default?  I say yes, please!  I see nothing wrong with the new frob highlight with this setting, and I think there are a lot of words above to the effect that 1 is troublesome.

  • Like 2
Link to comment
Share on other sites

1 hour ago, Araneidae said:

Time I think to revisit the debate: set r_frobIgnoreDepth to 0 by default?  I say yes, please!  I see nothing wrong with the new frob highlight with this setting, and I think there are a lot of words above to the effect that 1 is troublesome.

I don't mind either way as long as the effect is on by default from here on. But as I said this will cause the highlight to be covered, affecting doors sitting in door frames and so on: It needs to be carefully verified which option looks better.

Edited by MirceaKitsune
Link to comment
Share on other sites

Here are my latest settings:


    r_frobHighlightColorAddB = "0.00001"
    r_frobHighlightColorAddG = "0.00001"
    r_frobHighlightColorAddR = "0.00001"
    r_frobHighlightColorMulB = "0.3"
    r_frobHighlightColorMulG = "0.3"
    r_frobHighlightColorMulR = "0.3"
    r_frobOutlineColorA = "0.4"
    r_frobOutlineColorB = "0.4"
    r_frobOutlineColorG = "0.4"
    r_frobOutlineColorR = "0.4"
    r_frobOutline = "1"
    r_frobDepthOffset = "0.004"
    r_frobIgnoreDepth = "0"

This produces a more subtle frob that more closely resembles the original version but has a slight glow due to the frob outline.

  • Like 1

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

On 8/17/2021 at 12:48 PM, greebo said:

This problematic situation was there right from the start, I think Fidcal solved in Thief's Den by adding trickery to the chest lid, like triggering the contents to make them frobable as soon as the chest is opened. Something similar could be applied to the situation of the secret lever that is frob-highlighted unintentionally: The thing that is obscuring the lever might need to be moved away first to reveal the lever and make it frobable at the same time.

This has been implemented in a few missions where items like loot are set to frobable after a drawer is opened. But there's an occasional bug where the item does not become frobbable and then you're screwed until you restart the mission or load a previous save.

  • Like 1

I always assumed I'd taste like boot leather.

 

Link to comment
Share on other sites

r_frobIgnoreDepth 0 isn't a good idea for a default setting. As stated before, it's a rather expensive hack, and it can produce visual artifacts (of the kind where the outline is partially leaking into depth-occluded territory) that are not fixable.

If the outline is so controversial, better to remove it entirely than enable it with that hack.

  • Like 3
Link to comment
Share on other sites

2 hours ago, cabalistic said:

If the outline is so controversial, better to remove it entirely than enable it with that hack.

Or at least make it optional. Why is it so hard to get that through to the core developers?

  • Like 2
Link to comment
Share on other sites

20 hours ago, cabalistic said:

If the outline is so controversial, better to remove it entirely than enable it with that hack.

Yes, I'm afraid our expectations regarding player feedback were wrong, and we should disable the outline.

I'd suggest to:

  1. Enable Frob Helper by default (that's a tiny little dot in the middle of screen which appears when you look at things) and remove its setting from the menu.
  2. Disable frob outline by default, and add an option for enabling it back to the menu.

Also, I'd agree with @Gin that if default highlight is not enough, then dark outline works the best. But it should be very thin to avoid that "surrounded by void" feeling. Anyway, it means serious modifications to the code which no one is going to do now, and it is also likely to receive bad feedback...

Link to comment
Share on other sites

I don't really understand what's wrong with the new frob highlight, just so long as it's allowed to be hidden by occluding objects (r_frobIgnoreDepth = "0").  The frobbable object lights up as I think it always did (maybe I'm only looking in dark places so far), and the outline is ok, even if sometimes not fully visible.  What's wrong with it?

I think I'm missing the heart of the controversy, somehow.

Link to comment
Share on other sites

37 minutes ago, Araneidae said:

I think I'm missing the heart of the controversy, somehow.

I think there are two issues: 1) the outline is rather bright compared to the rest of the game and thus kills the atmosphere for some players, like myself. It's nice for a modern game like Deus Ex, but looks out of place in a medieval setting. 2) more serious is that the outline can reveal items that were hidden by the mappers on purpose. This can be somehow be fixed by r_frobIgnoreDepth 0, but this seems to take a huge toll on the frame rate. I completely agree with stgatilov's suggestions!

Edited by wesp5
Link to comment
Share on other sites

Well, in my short testing, r_frobIgnoreDepth 0 does indeed get worse performance.......by 0.3 fps.....

In bakery job, the front door open and highlighted, I get 153.3 fps with it set to 0, and 153.0 fps with it set to 1........

Is this really what expensive hack means?

 

Looking at the door THROUGH the fireplace with it set to 1 gets me 143.1 fps, with it set to 0 I get 142.9-143.0 fps.......

 

The only issue I see here is that there are some visual glitches on the door when it's closed, but they're liveable.

  • Like 1

I always assumed I'd taste like boot leather.

 

Link to comment
Share on other sites

1 hour ago, wesp5 said:

2) more serious is that the outline can reveal items that were hidden by the mappers on purpose. This can be somehow be fixed by r_frobIgnoreDepth 0, but this seems to take a huge toll on the frame rate. I completely agree with stgatilov's suggestions!

This was also an issue in Thief 1 and 2, if you had an inventory item selected it would shrink and stop spinning when you had something highlighted. Made finding hidden switches a lot more trivial.

EDIT: also see my previous post on HUGE toll on frame rate. Unless there's other situations where this would be a lot worse, it seems to be a non issue.

I always assumed I'd taste like boot leather.

 

Link to comment
Share on other sites

I wonder why this is such a huge issue. Such outline is being used in tons of both AAA and indie games nowadays, and it works correctly. I bet it's something you can either find for free, or buy in a Unity or Unreal Marketplace for a few bucks.

Link to comment
Share on other sites

25 minutes ago, peter_spy said:

I wonder why this is such a huge issue. Such outline is being used in tons of both AAA and indie games nowadays, and it works correctly. I bet it's something you can either find for free, or buy in a Unity or Unreal Marketplace for a few bucks.

It's one of those things that appears to be simple to do, but really isn't. At the end of the day, there are really only two ways to do it:

  • Mark the highlight mesh in the stencil buffer, then draw an extruded version of the mesh, skipping any pixels marked in the stencil and thus producing the outline. Works with depth out of the box, but will typically produce a hard border, not a soft glow. However, creating the extruded mesh is not a trivial thing for any non-convex mesh. Might be that Unity has tools for this, but we don't, and spending the time to implement something like this for an effect that's already controversial, anyway, seems like a huge waste of effort. There are some techniques with geometry shaders that can be used here, but you still need to preprocess the mesh data for them to work.
  • Do an image-based effect. Draw the object to a separate color buffer, then blur it to create a soft screen-space silhouette. Can then be applied to the original buffer, again using a stencil mask to cut away the insides of the object. This is what TDM currently does, it looks pretty decent and is relatively easy to do. However, it has no concept of depth, at all. I've tried some hackery on top to get it to respect depth, which is what r_frobIgnoreDepth 0 does, but it's not pretty. Might be able to do better, but that would eat more development time with uncertain outcome.

In the end, the current implementation is what you can do in TDM with moderate effort. Anything better requires significantly more effort, and given the lukewarm reaction to the feature, I really don't think it's worth that development time.

  • Like 3
Link to comment
Share on other sites

  • nbohr1more changed the title to [ 2.10 ] New Frob Shader

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share


  • Recent Status Updates

    • irg

      Watching warmly for The Black Parade, The Broken Goddess and Blood Death Wish Ep.4. Sometimes the best things in life actually are free.
      · 0 replies
    • STiFU

      We are taking our son on his very first holiday trip to see the sea for the first time. 🙂 Will be back in a week.
      · 0 replies
    • Gilkar

      When I was a young man my father was so ignorant I could hardly stand to have him around. As I grew older I was amazed at how much the old man had learned in such a short time.
      · 1 reply
    • jaxa

      RTX 3090 Super, RTX 3070 Ti 16 GB, RTX 2060 12 GB
      https://wccftech.com/nvidia-launching-rtx-3090-super-rtx-3070-ti-16gb-and-rtx-2060-12gb-by-january-2022/
      · 0 replies
    • duzenko

      CPU benchmark time - compiling DarkRadiant (2nd run)
      i5 8600K 6C/6T@4.4GHz DDR4 2x2133MHz 9MB cache
      Parallel builds: 1. 3:57 Parallel builds: 6 (default). 2:28 r5 1600AF 6C/12T@3.3GHz DDR4 1x2666MHz 16 MB cache, temp folder on HDD
      Parallel builds: 1. 5:05 Parallel builds: 4. 2:47 Parallel builds: 6. 2:55 Parallel builds: 12 (default). 2:57
      · 6 replies
×
×
  • Create New...