[ 2.10 ] New Frob Shader

[Araneidae]

11 hours ago, duzenko said:

Pity, I grew fond of the new frob visuals

Me too, I think there's nothing wrong with it: keep it!

[Guest]

14 hours ago, cabalistic said:

It's one of those things that appears to be simple to do, but really isn't.

Hmm, upon closer investigation, it's not like AAA titles handle it in a 100% consistent way either. For example, Dishonored 2 dropped the outline for doors altogether:

And for windows, it's often visible only after you open them:

 

Edit: I guess the reason for not having super tight outline system is that they might have been relying on an interaction prompts more (which I turned off and forgot about it):

Edited September 5, 2021 by Guest

[HMart]

Good thing that I'm using good old simple crosshairs for my game interactions...

But Is a pity this is such a hard problem, such a "modern" effect that new gamers automatically think your game is cooler because of it.   

I certainly comprehend Cabalistic frustration, so much work for in the end, not have good feedback because of the glitch's and no easy solution in sight, demoralizes anyone.

But like the others, please don't remove it from the engine entirely, if that is what you guys are thinking, if so please make it optional, no matter the glitch's, imo why have so much work coding this, for in the end throw it all away and if you guys don't want to spend time, messing in the menu code to support a half broken feature, just leave it has something for players messing in the game console to discover, is always cool to open games consoles and find things that the developers left in disabled, to me is a game in it self.

[cabalistic]

I'm not frustrated, I am not emotionally attached to the feature in any way. It was an idea that was suggested to check out, and I did. Learned some things in the process, it's all good

But I'm strongly opposed to leaving a broken feature in the game. We already have enough obscure features that are prone to break because they are not commonly used. If the feature isn't suitable for widespread adoption, then it's better to remove it and keep the code base clean and maintainable. How much time I did or didn't spend on the feature doesn't matter - that'd be a sunken cost fallacy.

[OrbWeaver]

18 hours ago, cabalistic said:

• 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.

What would happen if you:

• ignore Z depth entirely
• render the frobbed object occluded by other objects into the colour buffer, then performed the image processing operation on the visible portion

?

Would this not solve the problem of the highlight making things visible that should be invisible, because the image processing effect would only be applied to the part of the frobbed object which was already visible?

The downside I suppose it that it might look weird to have just part of an object outlined.

[wesp5]

1 hour ago, cabalistic said:

But I'm strongly opposed to leaving a broken feature in the game. We already have enough obscure features that are prone to break because they are not commonly used. If the feature isn't suitable for widespread adoption, then it's better to remove it and keep the code base clean and maintainable.

Nobody ever asked for this feature to be removed completely. Some people like it, others don't. So we should do what was already suggested, replace the "frob helper" option which probably nobody ever uses with a "frob outline" option which is default off and everybody should be happy and no work has been wasted!

Edited September 5, 2021 by wesp5

[cabalistic]

1 minute ago, wesp5 said:

Nobody ever asked for this feature to be removed completely. Some people like it, others don't. So we should do what was already suggested, replace the "frob helper" option which probably nobody ever uses with a "frob outline" option which is default off and everybody should be happy with nothing have been wasted!

If it were just personal visual preferences, sure. But if it being on actually impedes mappers due to stuff being visible that shouldn't be, then making it optional does not in any way solve that problem. Therefore I consider the feature broken.

[HMart]

40 minutes ago, cabalistic said:

...

But I'm strongly opposed to leaving a broken feature in the game. We already have enough obscure features that are prone to break because they are not commonly used. If the feature isn't suitable for widespread adoption, then it's better to remove it and keep the code base clean and maintainable. How much time I did or didn't spend on the feature doesn't matter - that'd be a sunken cost fallacy.

I certainly comprehend that stance and see the advantages of it, more clean code means, less clutter and so better readability but if idSoftware add the same opinion, we wouldn't had found some of the cool stuff they let in the engine disabled, like the mega texture stuff that even thou unfinished, was a way to learn about it and that someone made work, partially, the ability to read MD3 files and animations that is now a option to use in TDM for "cloth" effects, the liquid surface class that someone, more or less, also made work, the disabled item highlight that I'm even using for some effects and many other stuff they let in and didn't bother to clean from the source, like a extra more realistic player motion.  

But you guys do what you think is best in your case. 

[MirceaKitsune]

The frob highlight is very complete as far as I can tell. There might be little issues here and there but it works just as intended for me. Not sure why it could seem otherwise, we have a great new feature for the next release which deserves to be cerished.

[duzenko]

Is there a simple way to reproduce the whatever bug some people think the frob highlight has?

[geegee]

4 hours ago, duzenko said:

Is there a simple way to reproduce the whatever bug some people think the frob highlight has?

It isn't a bug, it's a feature.  With the frob highlight on as currently set default in the 2.10 dev builds, you can see it thru' desks, walls, etc.  So if this is implemented in the final build I'll have to go through my wannabe FM taking this new feature into account, relocating switches, loot, readables etc., or covering the entities with target_set_frobable, or whatever else that'll work to make it play right.  The game is a THIEF homage, and there's stuff that's supposed to be hidden from thieves, not telegraphed through walls etc.  That's the whole point of the game.

I never made TDM - I'm late to the party - so I'll go with whatever and do so thankfully because I appreciate the work, the result, and it's great fun working with DR then checking it out in a great game engine.  Going thru' my wannabe FM to redo things to account for this feature won't be much problem, the time spent a drop in the bucket compared to the time already spent learning tricks.  

But what about all the FM authors who're no longer here, who's going to fix up their FMs to put back the mystery.

[geegee]

11 hours ago, OrbWeaver said:

What would happen if you:

• ignore Z depth entirely
• render the frobbed object occluded by other objects into the colour buffer, then performed the image processing operation on the visible portion

How about, if an object isn't visible at all to the player, then no frob outline at all is drawn.  The old frob highlight works like that:  there is no highlight on frobable objects that aren't visible to the player, so the player doesn't see highlights floating in some x-ray vision. 

[MirceaKitsune]

35 minutes ago, geegee said:

How about, if an object isn't visible at all to the player, then no frob outline at all is drawn.  The old frob highlight works like that:  there is no highlight on frobable objects that aren't visible to the player, so the player doesn't see highlights floating in some x-ray vision. 

The new highlight should definitely only trigger then the old one does IMO. I thought this was already the case.

[geegee]

4 minutes ago, MirceaKitsune said:

The new highlight should definitely only trigger then the old one does IMO. I thought this was already the case.

No, the problem I have with the highlight at default (where r_frobIgnoreDepth = "0" isn't set) is that it can be seen through walls, desktops, etc.  See my earlier post in this thread where I set up a simple situation with hidden note under a backgammon set on top of a desk, and a hidden button underneath the desktop.  I posted a series of screenshots.

In my wannabe FM I first noticed the problem when I had a secret door in a wall, a somewhat hidden switch in the room, and a switch beside the door in the secret room.  The switch in the secret room didn't need to be hidden since the door was necessarily already opened.  With the default frob highlight the switch in the other, secret, room was immediately visible as the player wandered around - and the immediate instinct of any player would be to frob it since, after all, that's exactly what the frob highlight is begging the player to do.

[OrbWeaver]

6 hours ago, geegee said:

How about, if an object isn't visible at all to the player, then no frob outline at all is drawn.

There is no quick and easy way to determine if an object is visible at all to the player. In order to accomplish this, you need to render the object with full occlusion by other objects, then determine how many pixels from the object make it into the final render.

What I'm suggesting is that once this screen-space render is done, the resulting image is then used for the highlight processing, so only the visible parts of the frobbed object become highlighted. As a consequence, an object which wasn't visible at all would not be highlighted at all.

6 hours ago, geegee said:

The old frob highlight works like that:  there is no highlight on frobable objects that aren't visible to the player, so the player doesn't see highlights floating in some x-ray vision. 

That's just a consequence of the way the highlight is rendered (it brightens the object's own texture then renders it in 3D space as normal). As far as I know there is no specific test for whether a frobbed object is visible. Most likely the invisible frobbed objects are being highlighted, but you can't see it because brightening the texture of an occluded object does not make it shine through other objects.

[wesp5]

16 minutes ago, OrbWeaver said:

Most likely the invisible frobbed objects are being highlighted, but you can't see it because brightening the texture of an occluded object does not make it shine through other objects.

If that is true the current frob helper dot should still light up, so replacing it with the frob outline would be more obvious, but basically have the same result so it would be a good replacement.

[duzenko]

16 hours ago, geegee said:

It isn't a bug, it's a feature.  With the frob highlight on as currently set default in the 2.10 dev builds, you can see it thru' desks, walls, etc.  So if this is implemented in the final build I'll have to go through my wannabe FM taking this new feature into account, relocating switches, loot, readables etc., or covering the entities with target_set_frobable, or whatever else that'll work to make it play right.  The game is a THIEF homage, and there's stuff that's supposed to be hidden from thieves, not telegraphed through walls etc.  That's the whole point of the game.

I never made TDM - I'm late to the party - so I'll go with whatever and do so thankfully because I appreciate the work, the result, and it's great fun working with DR then checking it out in a great game engine.  Going thru' my wannabe FM to redo things to account for this feature won't be much problem, the time spent a drop in the bucket compared to the time already spent learning tricks.  

But what about all the FM authors who're no longer here, who's going to fix up their FMs to put back the mystery.

What are the steps for me to reproduce?

[geegee]

30 minutes ago, duzenko said:

What are the steps for me to reproduce?

put a "secret" switch under a desk.

[duzenko]

1 hour ago, geegee said:

put a "secret" switch under a desk.

In DR? Didn't you say the existing missions break with frob outline? I'm interested in that

[geegee]

2 hours ago, duzenko said:

In DR? Didn't you say the existing missions break with frob outline? I'm interested in that

I use DR.

I suppose some existing missions put buttons under desk tops, etc, to hide them.  If not, then it wouldn't be a problem.  I'm not going thru' them all for you.

Also, you asked, specifically:  

"What are the steps for me to reproduce?"

Edited September 6, 2021 by geegee

[Dragofer]

On 9/5/2021 at 9:15 PM, duzenko said:

Is there a simple way to reproduce the whatever bug some people think the frob highlight has?

It's important to distinguish between 2 different things being discussed in this thread:

1) What geegee mentioned in the recent posts: the new frob outline makes it easier to find items that are hidden behind other items. It's mainly a concept problem: the outline should use a depth test, but cabalistic says it's either too expensive or too work-intensive to implement that. The alternative would be to implement a depth test for frobbing, but imo that would break a TON of missions since you're probably not always going to have a line of sight when trying to frob something in i.e. a frobable chest.

2) Visual glitches like what MirceaKitsune recently posted on Discord:

As far as I can remember, most mentions of such visual glitches in this thread were only vague and without reproduction steps.

[AluminumHaste]

I've never seen that in hours and hours of testing the frob outline.....

It looks like there's a square patch there, maybe he should look at the model to see what's there.

[geegee]

4 hours ago, AluminumHaste said:

It looks like there's a square patch there, maybe he should look at the model to see what's there.

That appears to be models/mechanical/gears/gear_metal_fancy.ase which sandwiches the model between two square patches that have the spoke pattern texture.

Also, in my WIP I struggle with framerates and I get much the same results as you, tho' I use the TDM frame rate counter which bounces around a lot and doesn't do decimals.  There's virtually zero difference in fps between 1/0 on the showdepth hack, and I REALLY DO like the outline with r_frobIgnoreDepth = "0"

Edited September 7, 2021 by geegee

[duzenko]

It’s a little crazy

We talk about broken missions as a critical bug but still no mission name and getviepos coordinates

[Dragofer]

@kingsalrecently noted that the frob outline made the secret switches in his Volta 1 more visible than intended. I don't know the coordinates for them, but there's an AI (IIRC with a scroll on his belt) who patrols to all the switches. One of them was in the big library. Well, maybe kingsal can get the actual coordinates?