Why485

FYI what these kinds of edits will do is break the pixel perfect alignment. I've been thinking about releasing an unapologetically non-pixel aligned version of the mod which would produce more accurately sized dots, but it would require MSAA in order to work correctly. This similar to how the first release of the mod worked (albeit unintentionally), but it breaks down quite badly if you don't have 4X MSAA enabled.

That's a very interesting find. I guess the gScreenParams globals are set independent of whatever VR is doing.

As of the patch released today, 2.8.4.39731, this mod still passes IC.

It's not that the mod makes this worse, it's that the mod makes how difficult it is to see the the 3D models more apparent. Depending on the properties of your screen, it's possible that when the dot is switched off (it's controlled by the LOD system I think?) the plane under it is much smaller than the dot was, making it difficult to track. A native ED solution would ideally not have this problem and be able to smooth the transition from the dot to the 3D model.

There is so much variation in what causes the perceptual size of a pixel in VR that I'm not sure how you can compensate for something like that given that you only have screen resolution and field of view to work with. When you can't guarantee the end resolution (as you can in a console game or old DOS game), I think it's difficult to make dots "fair" across resolutions because you just don't have a lot of granularity to work with. You can't have a 1.5 pixel width dot. It's got to be 1x1, 2x2, 3x3, etc. I think there are some interesting tricks that could be used to more closely emulate the forbidden technique, but they are beyond what I can do. Like, for example, maybe you render your mythical off-grid 1.5 pixel dot but force it to be rendered with some kind of forced super sampling or multisampling so that it doesn't flicker the way it normally would.

Yes, both of these are still true. I was addressing just the part where you can specify the labels by target type.

On this specific subject, there actually are, but not by default. You can set up a custom Labels.lua, which is server enforced by the mission as well, to put labels only on air targets, or change how they appear for different types of targets. For example, the Flashpoint Levant server runs their own version of the dot labels which excludes ground units from appearing.

The tiny handful of people I have seen that defend the current state of spotting (and it is demonstrably a tiny handful) have always had expensive high resolution monitors and their reasons for never wanting to improve spotting tend to be completely delusional and in direct contradiction with any facts, convention, or data. I have never seen that opinion come from somebody with average or below average hardware. It makes no sense either, because they would also benefit from a good spotting system. I think the ultimate irony of ED's official stance of "spotting is perfect, your monitor is the problem" is that spotting gets better at lower resolutions due to the dot system. They seem to completely deny the dots exist and how they work, and live in a reality where they never implemented them. Maybe ED should just remove the dots altogether and put us back to square one so at least their arguments can have some basis in truth.

That's simply how dots work. At some point the dot has to disappear, and unfortunately since they are pixel perfect they can be of an inconvenient size relative to the model under them before they disappear. If the shader had more information, you might be able to do some math to make the dot fade based on FOV, distance, etc. but that's simply not available. In either case, this is an inherent drawback of a dot based system. I don't think dots in general handle this transition very well, and are best suited for low resolutions and distant targets. A good smart scaling style system on the other hand, works best at high resolutions and shorter distances. They complement each other well. Unfortunately, ED thinks such systems are heresy and will never, ever implement anything like them because DCS' spotting is already perfect because you have a zoom slider axis and an 8k 80" monitor. What do you mean you don't have one? The only way to improve DCS is to improve your hardware. Not going to upgrade? What are you, poor? Use labels and a magnifying glass then, I don't know what you're complaining about. Lowering resolution makes it easier to see targets? No it doesn't. You're clearly mistaken.

As of today's 2.8.4.39313 hotfix, this still passes IC. I've also added the following question to the FAQ in the OP since it's been getting asked enough that it's worth addressing.

Check the thread once in a while, though I don't have any plans to update it any further. I'm mostly just keeping an eye out for what ED ends up doing and updating the OP accordingly. Every time the DCS Updater patches the game, it'll overwrite the files from this mod, and you'll need to reinstall it. That's really all there is to it if you want to keep it simple. You can use generic mod managers like JGSME to enable/disable the mod between patches but if you're not running anything else and your install is simple, I don't think that's totally necessary.

The missile thing is unfortunately something only ED can fix. The only information I have to work with in the shader is the object's position.

FYI, this mod still passes IC as of today's 2.8.4.39259.1 openbeta patch.

I've released an updated version of the mod. The update can be found on User Files: https://www.digitalcombatsimulator.com/en/files/3330454/ The updated mod (v.1.1) contains two changes: The dots correctly snap to the pixel grid and don't require MSAA to work as intended The near and far ranges have both been adjusted based on feedback and my own experience while testing the mod Corrected dot rendering and no longer requiring MSAA This is the most important change of the update. As I mentioned in a previous post, I had noticed that when playing with MSAA disabled, the dots were flickering and not rendering correctly. The math I was using didn't correctly snap the dots to the pixel grid, resulting in dots which were either misaligned to the grid, or the wrong size. MSAA fixed this issue, but I didn't want the mod working correctly to rely on a very expensive graphics setting. The intended dot sizes are unchanged from the original release, but for reference the maths works out as such for common resolutions: 1080: 1x1 pixel dot 1200: 1x1 pixel dot 1440: 2x2 pixel dot 1600: 2x2 pixel dot 2160: 3x3 pixel dot Adjusted ranges Based on feedback from people in the thread, and my own experience testing the mod in various PVE and PVP servers, I made a few adjustments to the ranges. The near range has been pulled slightly in, as I felt like the fully opaque black dots were a little too easy to see, a little too far away. Meanwhile, the far distance was pushed out slightly. This is a compromise based on discussion that under certain circumstances aircraft should be visible from a further away. I still think a better solution would be some kind of glinting for truly distant spotting, but as I said before that's complex enough that I'm hesitant to put in the work for a mod that will probably be obsolete for MP purposes by next patch due to IC checks. In practice, these adjustments make for a smoother transition between a distant dot being invisible, and a near one being completely visible. More importantly, it makes it easier to approximate distance of a contact, since the curve is more gradual. When WVR (<5 nautical miles) the targets are still clearly visible, which is the area I'm most concerned with. Targets are also visible for slightly longer past the 10 nautical mile mark before they totally fade out with new, more gradual curve. To put numbers to this: Near range: 12km (6.48nm) -> 8km (4.32nm) 50% visibility range: 18000 (9.72nm) -> 18200 (9.83nm) Far range 32km: (17.2nm) -> 42km (22.6nm)

This is unfortunately one of the problems of a pixel dot based solution. The dot will always be the same size, and have the same fade rules regardless of the size of the object under it. However, I do think it's fixable. If an object size was passed into the shader, then the fade distances could be pushed in/out accordingly. This would solve the problem of large aircraft such as C-17s and E-3s being invisible from distances they shouldn't be, and smaller objects such as missile being too easy to see at too far a distance.

This is a very good post.

After reading the thread and some more experimentation there's a few comments I want to make. 1. I played a bit more with settings last night and noticed that the mod only works "as intended" when MSAA is enabled. I messed up the math somewhere, making the dots not perfectly pixel aligned. Without MSAA, the dots can flicker or appear smaller than they're intended to. This can probably be fixed easily by someone with a better understanding of the shaders. If I happen to find a solution to this I'll update the mod. 2. Based on feedback from VR users, the mod's effects are less predictable due to the wide amount of variance in VR optics and display technology. For VR, what matters most is the apparent pixel density, i.e. how many "pixels per degree" you get. On common headsets such as the Quest 2, the mod seems to be working as intended. However for more exotic and extremely high resolution headsets such as Varjo Aero, the mod doesn't do much since pixel density is so high that the 2D formula just doesn't work. On the bright side, headsets like this are at the extreme end of the spectrum of support and very much the exception. What this really exposes though, is the inherent limitation of a pixel based solution. I've said this elsewhere, but dots are really not a great solution to making visibility more realistic, especially in isolation. Dots scale best at low resolutions, and can be useful in creating hard and absolute limits to contact spotting. In my opinion, combining dots with some kind of scaling solution is a much better way to go, as you cover both bases. Scaling the visual models (or some simplified LOD) scales much better with higher resolutions and higher fidelity graphics options, since the actual geometry is still there. Dots meanwhile scale better with low resolutions, and combination of the two means the dots will cover lower resolutions, while scaling covers higher resolutions. 3. There's been some discussion on if the ~10 miles spotting distance is too short. Especially enlightening about this conversation is the comment, "I can see the ISS". I've already stated in the OP why I chose the numbers I did, but I want to expand on that rationale. TL;DR: the numbers are based on the distances at which you should be able to consistently spot fighter sized targets. There are absolutely certain circumstances in which it's possible to see small aircraft from extreme distances. The most common example of this is when the sun glints off something on the plane. The human eye is very sensitive to these sorts of "hot spots." It's why you can see illuminated streetlights and traffic lights from much further than you can make out the actual light/lens assembly itself, why you can see stars and planets in the night sky, and why when a plane catches the sun just right, it appears a bright speck of light despite being tens of miles away. There are some older sims which tried to emulate this idea. I'd give more specific examples but AFAIK that's a bannable offense. Regardless, I think it'd be nice to work out a sensible way to make sun glinting work. I did briefly experiment with this, but I couldn't get it working in a way I thought looked nice, and you also have to be careful to make it somehow never apply to ground units, which is difficult because the shader has no knowledge of the object under it.

This is a fixable issue, but requires source code changes since more information needs to be passed to the shader. The dots have no knowledge of what's under them aside from the world position.

As Sarowa said, this probably comes down to the specific circumstances at which the dot appears/disappears. There's really not much I can do about this because a dot system is so simple, and I don't have enough information in the shader to do some kind of additional fade out when too close, since that distance depends greatly on field of view and model size. Under the right conditions such as a sun reflection, I think that's absolutely the case and matches my own experience. However, I wanted to use a conservative number and go for the average case as indicated by published data for a small (T-38) fighter sized target. 10 miles full opacity felt too far, but I wouldn't be opposed to slightly bumping out the far range. However I think a better solution is to have some kind of glinting calculation which can make the dot visible under certain circumstances and at further distances. I did briefly try to get this working, and had some success, but wasn't able to get it working well enough, and I wanted to keep the edits as simple and straightforward as possible.

I've updated the OP with this FAQ entry, since I've been getting questions about this. Do I need to turn on labels to use this? No, the dot system in DCS is completely independent of labels. There is some confusion around the label system having a couple "dot" settings, but what those do is draw a label with a little . over the target. Labels are (at present) not obscured by clouds or the cockpit frame. The dots in DCS meanwhile are a completely separate function and do not interact with the label system at all. They are always on, cannot be turned off, and cannot be modified by players without messing with the shader itself as this mod does.

Very interesting, thanks for testing this. Funny enough, I got to use a prototype Varjo headset a few years ago, and the resolution was so sharp I felt like I could see further in that headset than I can in real life! The Varjo Aero is such an extreme edge case, especially considering it has that high resolution inset, that I'm honestly not sure what it would do or how it would interact. It's possible that since the resolution is so high, the models don't actually get small enough to become dots before they pass the "too far" threshold and the dot is already invisible.

That's just what missiles look like at 1080p and lower. Unfortunately there's nothing I can really do about that, since the dots are applied uniformly seemingly to any interactive object. To modify dots based on type such as missiles would require source code changes from ED to pass additional information to the shader. Thank you for this.

This is a very old image, but the dot system hasn't changed since I took this screenshot. I think that's bad.

This mod has nothing to do with labels. There is also no reason for labels.lua to be IC checked since its contents are already enforced by the server-side configuration.

This has nothing to do with the labels. It affects the dot. I don't think dots in isolation are a particularly good solution to spotting, but they're all I have to work with. The old impostors were much better, since you could read a silhouette and aspect from them, but we all know how that went. They were flawed, but the problems were totally fixable. It cannot. It's only a shader.