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.

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.

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.

It depends what you want to do and what inputs you need. Depth of Field might be doable that way, not sure. Motion blur is absolutely not doable that way or even at all, right now.

Yeah, and I just don't think this by itself is interesting. Again as a reference, in Phasmophobia it is potentially interesting because you talk with the Ghost during normal gameplay and also with your team in Coop, so there is a clear incentive to use voice. Furthermore, there is at least a potential for jump scares that may get you to accidentally make a noise during the parts you are supposed to be quiet. In contrast, when playing a game like TDM on your own where there is little incentive to talk, I imagine most people will be silent, anyway, and the probability for making an accidental noise that isn't triggered by external circumstances (e.g. a room mate asking you something, noise from the street etc..) is, in my opinion, fairly low. OpenAL, to my knowledge, is a pure output library and has no microphone handling. Would require at the least a new library, possibly even separate handling per platform. Definitely not an afternoon project.

Voice input can be an interesting game mechanic, but in my opinion there needs to be an actual incentive to use your voice in the game in the first place. This works great in games like Phasmophobia, for example, because you need to use your voice during gameplay to accomplish objectives, but then during ghost hunts you need to be quiet to not die. With this proposal, I'm skeptical that distracting guards is a good enough reason to use voice. Plenty of ways to distract guards, already, I'm not sure voice adds enough here. And since the majority of the game time you are trying to be stealthy (unlike in Phasmophobia), I think it would mainly punish the player / force them to be quiet most of the time, anyway.

This unfortunately misses the point a bit. The problem is not the open source license, per se, the problem is that Valve requires (or at least required?) a legal party or entity that is responsible for the app/game. So if any legal challenges about TDM (e.g. assets that we did not actually have permission to include) reach the Steam platform, Valve can offload them to the legal entity. But TDM doesn't have a natural legal entity, and so far no individual has stepped forward to take on that role. Nor would I advise anyone to, because it is potentially tricky and not without risk. I imagine this is going to be similar for any other store, as well. And that's why there has not been any progress in getting TDM on Steam or any other store, and I don't think that's likely to change.

The drawback is that it has a fairly huge performance cost, and yeah, that the depth will block it. Inline is theoretically possible, but not trivial, and will not resolve the issue in all cases.

You can go that route, but two things that are important to point out: 4 words may be cutting it close, probably better to choose 5 to 6, at least for important accounts. you must not pick the words, they must be chosen randomly! If you pick the words, there will be patterns in the sequence which significantly weaken the strength of the password. I know it's in the name of the method and you're probably aware, but many people still have a tendency to try to pick or "massage" the generated words, so I wanted to emphasize it Still, remembering too many of those phrases simultaneously is not an easy feat, so I'd still recommend a password manager, even if it's just a backup for your memory...

It's not uncommon. Drawing outlines is one of those things that sounds like it should be pretty simple, but is actually technically difficult. Even harder is drawing outlines that are properly occluded by depth. The option `r_frobIgnoreDepth 0` is a total hack that has numerous drawbacks, but it is also the only method I'm aware of doing it without spending an obscene amount of time on the implementation.

I said backed up, not stored, didn't I? My Keepass file is automatically synced with cloud storage, and as a consequence I have multiple fairly recent copies on my laptop, PC and my server. You do still have the problem that you need different passwords for different accounts. If you use the same encrypted passwords for all your accounts, that is most certainly not secure. I guess you could just use the domain name in your scheme, if your encryption is strong enough. You'll just have to hope that the websites didn't put some braindead rules for passwords into place that your encrypted output doesn't conform to

You should seriously reconsider that stance. Passwords that you can remember are very likely not secure enough, particularly because you probably share them between accounts to some extent. Good password managers encrypt your passwords securely so that you can easily back them up to cloud storage.

And that's the point, isn't it? The frob highlight isn't designed to be some obscure optional feature that players can enable if they like it. Highlighting the selected object is a necessary part of the game interface, because otherwise you can't really properly interact with the game world. Does the highlight have to take the form of a shining outline? No, of course not. There is a technical reason that we need to replace the current highlight system, which is going to happen one way or another. Since we are replacing it, anyway and since there have been more than the occasional complaint that the existing highlight is barely visible depending on the scene lighting, an outline was suggested as a possible alternative that we could try. If the outline isn't popular, it can be removed again, that's perfectly fine. I'm not attached to it in any way. We'll just have to find a different new implementation that more closely resembles the existing highlight. But it is *not* the goal to have several different highlights that the players are meant to choose from to their liking. We already have too many obscure options to maintain for too few developers, I don't want another unnecessary choice on top. So let's agree on an actual highlight a majority can live with instead of putting a controversial option behind an obscure menu entry.

But you CAN turn it off. Just not via a menu option. And I would argue that those other options don't belong in the menu, either.

I'm honestly not convinced this belongs in a menu option. You can always change or disable it via cvars as an advanced user, but menu entries should be limited primarily to those options that have the most use to the majority of players, otherwise the menus just get overloaded with a plethora of options nobody will fully understand. If we conclude that the majority of players actually has a use for turning the highlight off, it would be better to kill the feature.

Can a moderator please lock this thread? It has run well past its usefulness.

Careful, assertions and exceptions are meant for very different things, and you shouldn't mix those. Assertions are meant, for example, to check preconditions and contracts for your code, where a failing assertion almost certainly means a programmer error. Exceptions, on the other hand, are one way to perform error handling during runtime, where errors can occur due to user input or system failures and different reasons. And yeah, exceptions certainly have their problems and, outside of Python, should not be used for simple flow control. But the alternatives are not any less controversial, either.

Unfortunately, it looks like it depends on the implementation: https://ddanilov.me/std-async-implementations/ In short, MSVC appears to use a thread pool, GCC and LLVM do not (at least at the time of that blog post).

Ok, that's quite enough now. I don't want to hear another word on light entities and LOD unless someone has an actual showcase demonstrating the usefulness or absurdity of the feature. This "discussion" is getting nobody nowhere fast. What's done is done.

Hm, if the format is signed, that would require a different path in the shaders. That's not a straightforward fix.

I attempted a fix, but it didn't actually fix the issue, it just made it somewhat less visible. Previously, the AMD shader compiler confused diffuse and normal map lookups, which is very noticeable due to the green/red tint of the normal maps. Now, it confuses diffuse and specular lookups, which is not as obvious, but it's still just as wrong, unfortunately.

Nope. There is no shader branch since 2.09. All shaders expect red-green-encoded input, normal map texture format is either GL_COMPRESSED_RG_RGTC2 or GL_RG8, depending on image_useNormalCompression. So presumably RGB normal maps would have to be converted upon load, though I'm not sure if/where that happens in code. In either case, precompressed textures should be uploaded as they are and not be affected by image_use(Normal)Compression. Edit: actually, no conversion should be needed as long as the RGB textures were normalized, I guess. They just get their B channel cut off, which is then recalculated in the shader.

Less expensive, possibly, but again, it would depend how many pixels actually benefit from the less expensive model and what kind of effort you'd have to take to make the blend between the two not pop out too much. And exactly how much the difference between the lesser and the full model really is. As for rendering fewer pixels in the distance, that's not really possible, because GPUs traditionally don't really work that way. Or rather, it would require a very new feature called variable rate shading that is only supported by RTX and RDNA 2 cards. And only RTX cards support it for OpenGL. Don't think it's worth to implement for those cards alone

No, I would argue that in most instances, steps 8 and 9 (or the alternative GPU operations for shadow maps) are more expensive than the rest, unless perhaps you have a very strong GPU or use a very low rendering resolution. Yes, you might potentially be able to create scenes which are CPU-limited rather than GPU-limited due to poor visportaling or some very particular circumstances, but in the majority of cases that I have seen, GPU time at least matches and usually overtakes CPU time at the moment. Therefore, if we want to find ways to reduce overall frametime that is as generically applicable as possible, then right now we need to find ways that reduce GPU time at least as much as CPU time.

I'm afraid you're not. You are showing a standard scene and just hide a lot of its lights. It's very clear that this gives a performance boost, nobody doubts that. It's just also completely meaningless, because doing so alters the entire scene. And so it becomes a completely different scene and not merely a "performance optimized" scene. As such, it is *not* suitable to determine whether culling lights by distance is an actual usable performance optimization. As I already explained on the Discord, the influence of lights on performance correlates with the amount of pixels it touches, because the most expensive parts of lights are the calculations done in the pixel shader. As such, the amount of tris is not as important, so you are looking at the wrong numbers. However, this is also the issue: when a light is sufficiently negligible to a scene that culling it could actually be an acceptable performance optimization, it will invariably also be touching a lot fewer pixels to begin with. Certainly a lot fewer than in your test scene. And that changes the whole equation, because if it's touching fewer pixels to begin with, it will have less benefit to not render the light. All we are asking here is a demonstration that in a situation where a light is barely noticable (visually), it is still sufficiently impacting performance that implementing a distance-based culling system for lights would be worth the (potentially considerable) development effort.