Tippis

A lot of focus is on the VR dot thread now, and this is more for the pancake solution since that's easier to calculate, but as a reference and illustration for the problem we're having, I made this: The graph shows three lines: blue is the naive geometric solution for what kind of footprint a head-on F-16 should have (or, more accurately, its bounding box — a fair percentage of that should be empty, but that's a later precision that can be added). The orange line is what is usually the case in DCS, as people scan around at full zoom. The green line is some pseudo-ideal solution of what we probably should be seeing to make the whole thing properly realistic. Next to the area axis are illustrations of what a dot of that same footprint would look like. Note that about 20 pixels, it has transitioned in this graph from a dot to an actual “model”, with all the fuzziness this entails — in an actual implementation, this transition need to happen much sooner than that, at maybe 6 or 8 px². This all assumes that we've tweaked our setup so that 1px = 0.3 mils, i.e. the smallest thing the naked eye can see. Ultimately, with the way the aspect should be a lot less visible than the full bounding box would suggest, this graph actually overstates how visible the plane would be, and obviously, you can always “cheat” by sitting too close so as to make the individual pixels more clearly visible. But in a way, this overstatement actually drives the point home further… What the graph shows is why we can't have dotless solutions: because the 3D model reacts to zoom, and because it actually becomes more visible than the data suggests that the brain (rather than the eye) can handle. Ideally, a plane of this size should be all but invisible at 10nm. The raw 3D model solution would still render as a very visible 2px blob at this point. This means we can now zoom in, and suddenly, that 2px dot grows to a massive 12 pixels. Once seen, it can be fairly trivially be tracked out to 20+ nautical miles. The unzoomed model suffers a similar problem but in the opposite direction. At ranges where a pilot should be able to track the target and determine its general aspect, the resulting rendering is still too small and dot-like to convey that information. And of course, then there's the issue of what zoom as a function is there to provide: the ability to focus on details in and outside the cockpit, but also give a full wide FoV on the outside world, but also to let you do both at once without any substantial loss of information. It's a player convenience to compensate for how you can't do everything at once on the screen, even when you should be able to. So a couple of things are needed to make spotting work properly. One is to almost constantly and dynamically counteract zoom. Zooming in should not allow you see further. Zooming out should not make you lose “obvious” contacts. That orange curve needs to be massively flattened on this end, but almost inverted on the bit that falls outside of the top of the graph. There should be a maximum range at which a target of a given size will be rendered at all. Definitely for the orange (zoomed) curve, but as we can see, the same actually applies to the blue “1:1” curve — it, too, needs to be hard clamped much closer in than the trigonometry suggests. To achieve the green line, we need two facilities: a dot to take over before we even get to 10km so it can be forcibly hidden at a controllable range (and being controllably faded out to that point). A scaling function to counteract zoom as we transition from dot to 3D model, but also to provide the detail we still should be seeing, and which zoom would normally provide, but which needs to be toned down significantly from that extreme. …and then, of course, all of that needs to be scaled and faded appropriately to match other resolutions and screen distances (i.e. anything from VR to a good old 1080p monitor at arm's distance). Unfortunately, only through the use of scaling can the rendering be good and realistic. Without it, the model will be both massively too large and far too small depending on the range segment. We can't rely on trigonometry alone to make the full range of spotting sensible.

The reason you are wondering this is because you don't want to read the explanations why it is the only way it will work. There are at least three more states that you are wilfully ignoring: If the 3D model is too big for how visibly it should be rendered at that range, the dot can replace it and be set to be appropriately visible. If the 3D model is too small for how visibly it should be rendered at that range, the dot can replace it and be set to be appropriately visible. If the 3D model is at such a low LoD that out-of-game parameters such as resolution start to affect how visible it is in-game, the dot can replace it and make it uniformly visible. Basically, the flaw is that you incorrectly assume that the 3D model will always be the right size, and is universally rendered the same size on different hardware. The reason we have dots is because at beyond maybe 3-4nm, it isn't. Since the 3D model cannot be relied upon to show a correct and uniform size, something more controllable needs to be used. The dot is that something.

Thank you. That at least makes it look like the “centre” might be the centre of the bounding box for the model rather than what one might intuitively think of as as the centre of the aircraft. So the tail fin pushes the whole thing up a meter or three, and the dot is projected in the middle of empty space. At least that kind of sort-of-correct-but-not-what-you'd-expect maths would explain why it's offset. Hmm… time to experiment.

Good news: the spotting dots are intended to get rid of exactly that kind of thing, and going back to the old state when this was standard is not exactly going to solve anything. It was even worse before. Again, there's a reason why some people want to go back to that state so they can get their nonsensical advantages back. Nice! Thank you. That's a pretty good illustration even if it doesn't fully match the HMD optical effect. Do I understand it correctly if the darker upper/left dot is the label, and the faded lower/right one is the spotting dot? It looks like they are doing what they should in terms of general appearance — the right colours, very different fading schemes etc. It's just that the alignment is way off on the label. I'm beginning to wonder if maybe the alignment sits on the wrong plane in the binocular rendering, so it gets confused about what point in space it should be centred on. It's a tricky question, and I understand if it's too fine a detail to really tell, but would you say that the mirror picture is more like the right or the left eye? Just theorising, really, but still… And I suppose we could also get back to that age-old question of what even counts as the centre of the target itself. If it's trying to pick the cockpit as a centre point, that would of course also shift the dot, but it shouldn't be by that much. Could you check what your DCS World\Config\Views\Labels.lua file looks like, and in particular the block defining local function NEUTRAL_DOT? In particular, there should be a line that sets the actual dot that says res[last_x] = {"·","CenterCenter",0,opacity,0,2}. Or does yours say anything else? Because everyone is posting images from when the target is far off in the distance. You say there's a huge problem when they're close-up as well, and it would be nice to see an illustration of that, especially since neither labels nor spotting dots should even show up at that distance. But as YoYo's picture shows, they are a bit aggressive close in so the question is one of exactly how close is that still the case? As such, it's important to figure out of those are out of whack or if you're seeing some other kind of artefacting or rendering error. Thank you. That's horrible. And very different from what I'm seeing. So yay. Yes, there really doesn't seem to be any need for a dot at all at that range. I'm guessing this is with labels off from the colour and shape of that dot so we're not dealing with any interference from that? And no generative rendering like DLSS?

Heh. Again, this is for the neutral dot labels, since there's some confusion as to what those dots are supposed to look like in comparison to the spotting dots. It gives us a very clear definition that lets us say if and when we're seeing those labels rather than some other dot. A lot of this discussion seems to devolve into “what is it we're looking at here, really?”, and here we have one thing that we can very clearly identify. I don't think there's anything positive to gain from removing dot labels.

Again, this sounds an awful lot like you're coming across some pretty odd rendering error, possibly triggered by the spotting dot functionality, but ultimately a different matter. Based on that description, we can rule out labels — they don't appear that close and should disappear much farther out. They shouldn't be spotting dots, since those should not appear that close. Could be LoD issue where the model is either picked from the wrong level, or rendered wrong, or just gets some good old broken poly errors. The problem is that you think I have a problem, and you're inserting yourself in conversations as if they were directed at you and discussing the problem you're having rather than the problems the other guy is describing. If you are not talking about neutral dot labels — the thing we were talking about — then your particular issue is not related to the quote you were answering. And again, based on your description, you aren't because what you're seeing doesn't fit the behaviour of neutral dot labels. I am simply trying to figure out what is going on with all the disparate reports of what are supposedly the same dots come about. In particular, I'm making clear the differences between the various dots the game uses, with how they behave in response to parameters such as range and resolution, so as to figure out exactly what is going wrong with which part. So, to clarify a few things: How large are your black squares? Are they actually black (I'm not being facetious here — it's an important distinguishing observation)? Do they change size? Are they aliased or faded in any way, in whole or around the edges? At what ranges do they appear? (I suppose this has mostly been covered, but if there's a difference in any of the above as range changes, that's an important observation as well.) What's your resolution and does the problem persist at different resolutions? Does the resolution alter the size of the squares? Good for you. No-one is disputing this. But you need to be a bit more precise in your description (and if possible with unaltered png screenshots to support them, preferably of multiple contacts at different ranges) so we can try to figure out whether it's the dots that are screwing you over or something else.

Can you catch a screen shot, preferably showing different contacts at different ranges and sizes? And as png. I wonder if there might not be yet another rendering error that is making the rounds that is making it even more confusing as to what spotting dots are and look like.

It's not really trolling to simply question his interpretation of the images he provided, seeing as how they don't really seem to show what he says. You'll note that you then seem to offer the same differing opinion as to what we're seeing… Ok… and? That sounds like you're talking about the spotting dots, in which case, see the above question about what ranges we're talking about. How large do they get? And if if you're talking about the spotting dots, how does that relate to anything in the post you quoted? We're talking about the appearance and position of the neutral dot labels, and the way they're behaving. It's particularly fun to do so in relation to how that label is defined by default in the DCS install where, as mentioned, they don't change size (the label system simply doesn't allow for it), they should stay centred (but that will depend on where DCS thinks the character block centre is relative to the actual centre of the “·”-character used to draw that dot), they have a ridiculously long range (32km before the label shows nothing for airplanes) and a rather annoying close-in range (they start being rendered only 500m out). Oh, and according to the definition, they're supposed to be a 30% dark grey (close to this) rather than black. Now, the question is, do they actually show up like that for the client? If they don't what has happened between the definition file and the actual rendering? Is the neutral dot defined internally, in spite of also appearing the labels.lua file? Is it overwritten by a player preference file? Is it overwritten by a file included in the mission? Or is this a file that doesn't get updated properly so different installs have different definitions?

They also apparently change in size which doesn't happen unless you alter them since they're defined as text overlays of a fixed point size. They also don't seem to cover the aircraft, but it's hard to tell with the jpeg artefacting. That's part of why you don't use jpeg to show off pixel-level details.

If we look at the LEVEL_NEUTRAL_DOT definition, they're placed with the alignment “CenterCenter”, so they should be pretty much right on top. Of course, there's also the “LEVEL_DOT” (which is a funny name for it doesn't even use dots for most range segments) and those are aligned with the dot_symbol function, which places them as “CenterBottom”, so there's a lot of dot definitions to keep track of. The labels file is just a mess of different-generation legacy codes and comments for how stuff is defined. That said, if the dot labels are jumping around even with that specific alignment, we might have another fun bug on our hands. Or, worse, it differs from one upgrade path to another, or from one install to another, so the supposed default appearance actually… isn't. That would explain a horrible amount of things as far as how differently people feel about the dot labels… Brrr…

The solved problem is that the comment is not being reductive when applied in a particular instance, and when there the options available are not reduced to just one. The “constant stalking” is making sure that his constant bad-faith arguments from (wilful) ignorance, misdirections, and self-defeating claims are shown for what they are. He has also been shown to fabricate “proof” on numerous occasions. Again, he has a long history of actively trying to sabotage any attempt at improving the game. In this particular case, he doesn't want dots to be improved to where they work — he wants spotting to return to a known broken state. I know he claims he has me blocked. I also know that he has claimed this on multiple occasions before and then turned right around and started to argue against what I'm saying. And when that backfired, gone back to claiming he has me blocked. So like with everything else, I take what he says on that particular point with a quarry full of salt.

It has been explained in full. Try reading. Also, try looking at your own images, the differences are glaring, without even going into the whole issue of your choice of jpeg over png. You should probably also try to create reproducible results, rather than images that suggest wildly different zoom levels and/or ranges, making it anyone's guess why things are bigger or smaller. Let's see if you can spot the problem with using these examples of yours for comparative purposes. They've all been cut out with the same margin and enlarged 4x without interpolation to show the details in… well… detail. There are a couple of things in this supposed same setup, other than dots and labels on and off, that you need to explain…

I don't think “users” are of that opinion. I know for a fact that Sharpe is of that opinion. I know this because there's a lot of history behind his objection to this particular improvement to DCS (he is always against improvements to DCS — there's a lot of history there as well), in that he was perfectly fine with the old system that let him see targets from outrageous distances where others couldn't see him, and he expressly thought that they should just git gud (or git gudder equpment). But when the exact same system was proven to give advantages over him to other players, it was suddenly the worst thing imaginable and needed to be fixed immediately. The people who gained that (well know, but not by him) advantage were all of a sudden horrible cheaters who used an “exploit” to beat him in PvP (this was never proven), whereas when he used his advantage given by the exact same system, it was all natural and normal and as it should be. Since then, he has vacillated wildly as to what he thinks about the spotting dots. Whenever he believes that they have solved his old vexation and robbed others of their advantage, it is good. Whenever he understands that the advantage (or just plain parity) is there, it is bad. And all the while, he's begging for the return of a system where he gets a clear and unambiguous advantage over other players. His entire line of reasoning and rationale for his complaining about (and occasionally praising) the system is “I used to have an artificial advantage over others, I want it back, and also they should have their advantage over me artificially removed”. This is him, and no-one else (or… well… a few more, but they have learned not to expose themselves as clearly) — definitely not all users who aren't satisfied. Hell, I'm not satisfied, because the dots can still be a whole lot better (and supplemented by other systems). I just recognise that it has solved a lot of issues with the old system, and robbing Sharpe of his favourite unfair advantage is icing on the cake. Don't apply comments directed at others to yourself. Problem solved. And if it does apply to you, my comment isn't reductive. Problem still solved. If you actually read many of my posts, you will find a number of different categories that you may find yourself in. You'd know that I don't think people complain “only because” of some perceived loss of advantage. If you want to speak about reductive arguments, look no further than your own claim.

1. Don't play in portrait mode. That's not how your eyes are situated. 2. Don't use jpeg — it removes the detail we're looking for and creates artifacts that hide the very thing you're trying to show. Since you revealed that your dot labels are misaligned, the difference is obvious if you know what to look for. This has been explained in full: because one is a UI option, and the other is part of the simulation You can enforce the former much like you can some other UI elements such as the BDA indicator. You can't enforce the other, much like you can't turn off explosions. Your “perspective” is objectively wrong. It's not even a perspective. It's an incorrect assumption based on a refusal to understand the purpose of the features you're discussing. Just because the two convey related information does not mean they're duplicates of each other. Explosions do not duplicate the BDA window. By very definition, they cannot be an exploit. It wasn't an exploit when you were able to spot targets at 40nm either. It was just silly and as such, the new system had to be put into place to curb that excess and unrealism. Just because it's in a bad place for you right now doesn't mean people who temporarily get an advantage over you (and the number of people who do can be counted on the toes on one of your hands) doesn't mean they always will or that there is any cheating going on. You're just on the other side of the fence from where you want to be in this iteration phase. That is a you problem, not a game problem.

Eh, no. The point of using a dot instead of the model is that the model can't be guaranteed to be of a particular size. Using both is largely pointless because if it's just a dot, you don't need the model; if it's large enough to not be a dot, you don't need the dot. It's not that the dot doesn't make sense — it's that your assumed use case and application is nonsensical. Dot labels should cover the aircraft. If yours have been adjusted to not do so, then that's the label maker's fault and you can adjust it back to be in the right position (or pick a different dot symbol that is properly centred).

Are you quite sure you're not actually seeing a label?

The thing is, when we're talking about “spotting” (as defined in that whole spiel) they should be dots. They're the smallest thing the simulated pilot's eye can even pick up. There's no other way to sensibly represent that point-shaped object but with a dot. It only gets weird because of how it should look the same(ish) for everyone, where particularly high-resolution displays would have to render it using multiple pixels. This intuitively defies our understanding of a “dot” to some degree, but then again, a period is also a dot — we're just used to the way that particular dot looks (also, we want that particular dot to be a bit bigger so we can actually see the end of the sentences we denote with it). We rub against the limits of realism because modern displays, when you're not rubbing your nose against them, are capable of displaying smaller details than the player's eye can resolve. Representing the pilot's eye on such a screen will almost by necessity make it larger than a single pixel, which may feel like it doesn't match the whole “smallest thing possible” notion. So yes, it would be realistic, and the problem is more in the physical setup of your gaming area. Dots also offer a rather important benefit in that they are trivial to fade into the background. The pop-in issue is real, again because of the resolutions we have these days, and it's a whole lot of work of questionable value to make a 3D LoD model that is only ever meant to be rendered as maybe 3 pixels, and then to also make that 3D model transparent on the fly. Compare that just just filling in a few pixels with an RGBA value, where the Alpha in particular is what makes it fade in a controllable manner. Representing them as dots also rather neatly circumvents the zoom issue, where the player tool to overcome the limits of how much (or little) of the pilot's field of view actually fits on the screen should not somehow make that simulated pilot see more than they should be able to. If you do it with a 3D model, you need to scale it down to counteract zoom to make sure it's always that “smallest thing”, whereas with a dot, it's… well… still just the same dot, even when you narrow down your FoV. To make it sensibly and realistically continuous, it pretty much needs to be a process of: Fade into dot -> fade into scaled down model -> scale into oversized model -> scale to 1:1 model. All to overcome the detail capabilities of the display systems but also to properly model what the brain can fill in if it has enough to work with.

Yay!

…and let's not forget what seems to be a favourite: 7. Amputate the leg. Since it can't be fixed here and now, it's best to get rid of it altogether.

You can also generally wreck the place with destruction zones, although they have a history of being a bit unreliable and wonky.

You know that “compression” does not mean “data loss” right? And that you can turn it off? And that you can view a 4k image on a 640x480 display? And that the problem you want people to document and report has been documented and reported extensively? So no, no, and no, in roughly that order. It has gotten to the point where, if you state that the sky is blue, the immediate response would be to pull out the colorimetric instruments and double-check the calibration to make sure they still work properly. You most certainly are. If you weren't, you'd suggest something that pretty much all bug reports related to graphics should contain, as opposed to something that inherently can't convey the issue (and which you don't understand how to capture to begin with).

Neither do exaggerations. DCS is fully usable. Whatever small sample size you used does not qualify as “most players”. That sounds a lot like you are having issues with a very different gameplay option, not with spotting dots. No, it doesn't. That's the problem with all your blame-shifting: you think that if it works one way for one person it must by necessity work that way for everyone, so if someone says something else, it must be a problem with the person, not the game. In spite of having been shown (which shouldn't even be necessary if you understood how computers work) these differences, you cling to that ridiculous notion.

That goes both ways. It was appropriate for the exaggeration.

It's not really for his benefit, but for people who might believe anything he says has any connection any know reality. Citation needed. And he showed you exactly what you asked for. You just moved the goalposts because reality once again did not align with your assumptions. And what you're asking for now has also been shown — you just choose to ignore it and try to blame the players for what the game is showing.

Funny how you miss things if you don't read them. This has been explained before, no guesswork required. …not consistent with how VR works. That's why you shouldn't guess. We know it's the game. You know it's the game because this is an ancient issue that has plagued 2D as well. in fact, if you remember, it was this very issue that made you post your 40nm screenshots to try to prove that spotting was fine, actually, and it was just players not being able to see things. You know, that post that finally tipped the edge and made it abundantly clear that spotting was broken and exploitable, because you had just tried to use that state of affairs to utterly fail at your intention to demonstrate how realistic and functional it was. Then, like now, you didn't read what people actually told and showed you, and rather than disproving them, you accidentally showed that it was just as broken at the other end of the spectrum, thereby driving the final nail in the coffin of the exploit you wanted to keep around. Then, like now, you tried to support your self-defeating argument with guesswork and reality-defying assumptions because it had to be reality that was wrong, not your unfounded speculations.