dynamic radar detection/threat zones

A good idea change for the mission editor would be for air defense- detection/threat zones to change size when we have an aircraft selected- based on the altitude and radar cross-section.

The reason this wouldn't happen (i think) is probably due to the fact the RED side would not have access to classified RCS data in the real world?

 

From a balance prospective it probably is intensional so not to have mission designers setting waypoints on the fringe of all threat circles allowing them to fly with higher accuracy past SAM or radar threats for any given aircraft?

 

Form a measurement standpoint Would the RCS of any fighter (although slightly different) really matter to a radar unless it was stealth capable? An F16 or a Mig29 are very similar in size any difference would probably be negligible when you are using miles or Kilometers as your unit measurement. Unless you are using stealth technology then i could see your idea being useful in order to exploit its advantages.

 

Is RCS even used in DCS? or is it just an arbitrary number given to certain plane types?

Edited June 30, 2019 by (504)Blade
spelling and grammer

I personally would think it's just a bit too complicated to implement for rather little gain.

...

Is RCS even used in DCS? or is it just an arbitrary number given to certain plane types?

 

IIRC It is used but it is heavily simplified, i.e all planes are approximated as just spheres of a certain radius, AFAIK this radius is relatively arbitrary as to provide a best guess of RADAR performance against a certain threat. While this could be improved somewhat (i.e use raytracing) to do this accurately for whole aircraft would be insanity (purely due to extremely complex/dynamic geometry of aircraft, think of all the little details, doors etc) and I'm guessing is definitely beyond what consumer hardware can take, and DCS is resource intensive (putting it lightly) as it is.

 

So far the only A/C that has a proper raytracing RADAR is the Viggen (AFAIK) which is A-G but primarily to be used against ships.

Edited July 1, 2019 by Northstar98

The reason this wouldn't happen (i think) is probably due to the fact the RED side would not have access to classified RCS data in the real world?

 

From a balance prospective it probably is intensional so not to have mission designers setting waypoints on the fringe of all threat circles allowing them to fly with higher accuracy past SAM or radar threats for any given aircraft?

 

Form a measurement standpoint Would the RCS of any fighter (although slightly different) really matter to a radar unless it was stealth capable? An F16 or a Mig29 are very similar in size any difference would probably be negligible when you are using miles or Kilometers as your unit measurement. Unless you are using stealth technology then I could see your idea being useful in order to exploit its advantages.

 

Is RCS even used in DCS? or is it just an arbitrary number given to certain plane types?

 

I expect RCs is just an arbitrary number, and at most several numbers I'd expect altitude would work the same way.

That would make it easy to implement. When you are a mission editor you are neither red nor blue so there is no reason to limit you to what one side or the other would know. As for game balance- a mission editor can already make an unbalanced mission. This would simply increase flexibility.

IIRC It is used but it is heavily simplified, i.e all planes are approximated as just spheres of a certain radius, AFAIK this radius is relatively arbitrary as to provide a best guess of RADAR performance against a certain threat.

 

 

I would assume the RCS modeling was a simple decimal where a large bomber without stealth consideration might have an RCS of 1 while an F-117 may have an RCS of .01

I personally would think it's just a bit too complicated to implement for rather little gain.

 

There is already a code in DCS to determine MAX detetion range for a given aircraft. So all you would have to do- is add a line for the methods that are triggered when you select an aircraft to get that bit of code and change the detection zone radii.

I would assume the RCS modeling was a simple decimal where a large bomber without stealth consideration might have an RCS of 1 while an F-117 may have an RCS of .01

 

Essentially yes, it's just modelled as spherical - i.e the same from each angle, whereas in reality you'd see different returns from different surfaces at different orientations

Is RCS even used in DCS? or is it just an arbitrary number given to certain plane types?

Yes, it's modelled according to the devs.

 

It's tied into the rendering pipeline, presumably so that the calculations done to rotate an object model in relation to the viewer's camera are not just used to determine how many pixels will light up as it's drawn, but also to determine how visible the unit is to sensors. Both have to figure out the cross-section of the model at a given distance, but that information is then used for two different purposes.

 

This is supposedly why

: because they'd mess with the rendering pipeline in such a way that sensors would become too effective at picking the units up.

Yes, it's modelled according to the devs.

 

It's tied into the rendering pipeline, presumably so that the calculations done to rotate an object model in relation to the viewer's camera are not just used to determine how many pixels will light up as it's drawn, but also to determine how visible the unit is to sensors. Both have to figure out the cross-section of the model at a given distance, but that information is then used for two different purposes.

 

This is supposedly why

: because they'd mess with the rendering pipeline in such a way that sensors would become too effective at picking the units up.

So it's more complex than a simple lookup table and the best way to do what I am asking for would be to use a lookup table so the code would look a bit like this and maybe something to denote altitude.

 

C = pi * range * RCS * alt;

 

where the RCS is a decimal that represents the average RCS and alt would be some number to indicate the horizon at your current altitude. As the point would be a rough guideline so you can see if there is a reasonable chance the currently selected flight would get picked up by radar. Perhaps the mission goal is to thread the needle while an enemy plane at a higher altitude tries to find and kill you. This would especially be nice if/when we get a dynamic campaign- if we can alter the mission any.

Yes, it's modelled according to the devs.

 

It's tied into the rendering pipeline, presumably so that the calculations done to rotate an object model in relation to the viewer's camera are not just used to determine how many pixels will light up as it's drawn, but also to determine how visible the unit is to sensors. Both have to figure out the cross-section of the model at a given distance, but that information is then used for two different purposes.

 

This is supposedly why

: because they'd mess with the rendering pipeline in such a way that sensors would become too effective at picking the units up.

 

That actually makes sense.

It's just a lookup table and the result is modified by look up/down, aspect and range.

 

It has nothing to do with rendering, it's literally just a simple math function based on the radar equation with the only two variables being radar power and RCS, and real time inputs as defined above

Edited July 3, 2019 by GGTharos

It's just a lookup table and the result is modified by look up/down, aspect and range.

 

It has nothing to do with rendering, it's literally just a simple math function based on the radar equation with the only two variables being radar power and RCS, and real time inputs as defined above

Do you have a source for that because, as noted, Wags says otherwise.

Edited July 3, 2019 by Tippis

The source is me, having checked this out thoroughly and having been in contact with the devs.

 

You can graph the RCS response and you'll find it corresponds to the radar equation; it is only modified by a couple of things as I mentioned above.

 

Not only that, but you can change RCS, radar power, and rendering/LOD parameters completely independently in lua with the expected results, ie. rendering has zero effect on RCS and vice versa.

The source is me, having checked this out thoroughly and having been in contact with the devs.

I'm afraid you're going to have to have something more solid than that because, again, you're contradicting official and very explicit dev claims on the topic.

 

 

Not only that, but you can change RCS, radar power, and rendering/LOD parameters completely independently in lua with the expected results, ie. rendering has zero effect on RCS and vice versa.

So basically, you're saying that Wags is lying? Also, exactly what rendering and LOD parameters are you changing to yield this supposed null-result?

I'm afraid you're going to have to have something more solid than that because, again, you're contradicting official and very explicit dev claims on the topic.

 

You should be afraid of not checking this for yourself. There was no explicit claim of anything, you're just conflating with a mention of something by Wags as explicit information regarding what the code is doing.

 

So basically, you're saying that Wags is lying? Also, exactly what rendering and LOD parameters are you changing to yield this supposed null-result?

 

Why would Wags have to be lying? Wags is not a developer.

There are LOD parameters that you can modify in the LUA - I have neither the inclination nor desire to go hunting for where exactly they are now ... you can do that exercise yourself. Same with the radar power (expressed as a range in LUA) and RCS values.

 

The LOD files contain information about when to use which LOD - usually there are anywhere between 3 and 5 levels available for most objects, starting with the full detail LOD and ending with a dot ( a dot ... which has zero information regarding the full detail shape, get it?) ... that dot tends to be cut off either close, or really far away (technically infinity), depending on who was editing the file at the time.

 

Further, it's not like the testing for this is difficult ... and I'm sure you can come up with some pretty good and simple tests yourself, without even digging into LUA.

There is already a code in DCS to determine MAX detetion range for a given aircraft. So all you would have to do- is add a line for the methods that are triggered when you select an aircraft to get that bit of code and change the detection zone radii.

There obviously is, otherwise the whole system wouldn't be working. But I can't quite see how the display of that is going to work out in a helpful way without torpedoing all efforts of making the UI less clunky.

You should be afraid of not checking this for yourself. There was no explicit claim of anything, you're just conflating with a mention of something by Wags as explicit information regarding what the code is doing.

Eh, what? Why would I be afraid of anything?

And I'm not conflating anything — it's pretty explicit: dynamically resizing LOD meshes to create smart scaling would affect RCSes (and other sensors). This means RCSes are calculated from those meshes, and it's done at a stage where resizing them for display purposes would also affect the RCS calculations.

 

This can only mean that RCSes are pulled from the rendering pipeline at a stage where those meshes have already been used to determine on-screen size — otherwise, you'd be able to rescale one without affecting the other.

 

Why would Wags have to be lying? Wags is not a developer.

There are LOD parameters that you can modify in the LUA - I have neither the inclination nor desire to go hunting for where exactly they are now ... you can do that exercise yourself.

Wags is a representative of ED, explaining why a particular implementation would not work with their software. You are someone making claims that contradict this explanation — claims you then refuse to back up.

 

One of those is a credible source; the other is not.

 

The LOD files contain information about when to use which LOD - usually there are anywhere between 3 and 5 levels available for most objects, starting with the full detail LOD and ending with a dot

Nothing in that contradicts Wags' claims. You're not actually altering the parameter that's important here: size. So again, you'd need to actually come up with some solid evidence to contradict what ED has said on the topic — asking me to dig up evidence for your claim is not going to cut it.
Edited July 4, 2019 by Tippis

So again, you'd need to actually come up with some solid evidence to contradict what ED has said on the topic — asking me to dig up evidence for your claim is not going to cut it.

 

The evidence is in the game itself and you're just too lazy to check. And I'm too lazy to re-do any of the work. But here's an easy one for you:

 

Get an aircraft at look-up (the look-up is important) in the ME and set it up hot aspect (flying towards you) at various ranges.

 

Set up multiples of it at say 10nm intervals, you choose.

Then set up the same aircraft flying perpendicular to you, again look-up, in the same test.

 

In a real radar, that perpendicular aircraft has enough of an RCS increase to appear at 50% more range, if not more, compared to the head-on aircraft. Go ahead, try it with any FC3 module.

I know folks hate to be wrong, but you are completely, and utterly, wrong.

 

 

I can verify what GG Tharos is saying. All the data is in the open lua files to read, the source is: DCS.

 

I can also verify there is no check as to if an object exists via some sort of raytracing or other magic.

 

 

 

The reason I KNOW this is because of bugs in DCS that showed things to be there when actually not. The other method was by creating a mod with literally minute proportions and watching it show up on radar according to the dimensions I set in the lua.

 

 

That's all there is to it, be as disappointed as you like with reality. There is no RCS based on model size, it's in every planes table, go read it and stop entertaining yourself with false hopes and fantasy.

 

 

Oh, by the way, marketing is not a credible source or a replacement for science and intelligence.

 

 

 

 

Eh, what? Why would I be afraid of anything?

And I'm not conflating anything — it's pretty explicit: dynamically resizing LOD meshes to create smart scaling would affect RCSes (and other sensors). This means RCSes are calculated from those meshes, and it's done at a stage where resizing them for display purposes would also affect the RCS calculations.

 

This can only mean that RCSes are pulled from the rendering pipeline at a stage where those meshes have already been used to determine on-screen size — otherwise, you'd be able to rescale one without affecting the other.

 

Wags is a representative of ED, explaining why a particular implementation would not work with their software. You are someone making claims that contradict this explanation — claims you then refuse to back up.

 

One of those is a credible source; the other is not.

 

Nothing in that contradicts Wags' claims. You're not actually altering the parameter that's important here: size. So again, you'd need to actually come up with some solid evidence to contradict what ED has said on the topic — asking me to dig up evidence for your claim is not going to cut it.

The evidence is in the game itself and you're just too lazy to check. And I'm too lazy to re-do any of the work.

Well, then I don't have much reason to doubt ED's claims then. :dunno:

Again, you made the claim — you provide the evidence. It's really that simple.

 

I know folks hate to be wrong, but you are completely, and utterly, wrong.

 

I can verify what GG Tharos is saying. All the data is in the open lua files to read, the source is: DCS.

The problem is that what he's saying isn't actually contradicting what Wags is saying. Again, it's not me saying this — it's Wags. If you (and/or Tharos) say that Wags is wrong, then some pretty solid evidence is required to show that.

 

Don't get me wrong: I'd love for Wags to be wrong about this because that would mean DCS is fully ready for the kind of perception-sim improvement that smart scaling would entail, and that ED are just unwilling to implement that for some silly reason. But again, pretty darn solid data would be required to be able to disprove his statement and all the arguments against perception simulation that have been based on his saying that.

 

The other method was by creating a mod with literally minute proportions and watching it show up on radar according to the dimensions I set in the lua.

Do the results of those dimensions vary with how other aircraft with the same dimensions show up? Or is this a self-contained result without any point of reference or comparison?

 

Oh, by the way, marketing is not a credible source or a replacement for science and intelligence.

It's an infinitely more credible source than nothing at all, and that's all he has offered. No science (there's a reason I'm asking for the control group), no data, no intelligence — just a lot of “nuh-uh” and “do it yourself” (the latter being a very common fallacy that raises all kinds of red flags) — and as unreliable as marking may be, it's still the official word from the developer which inherently ranks higher than some unsourced, unproven claim from a user fiddling in unexplained ways with unspecified LUA files.

 

 

At any rate, the simple fact remains: the official word from ED themselves is that RCS is simulated by siphoning off data from the rendering pipeline.

Edited July 4, 2019 by Tippis

It's an infinitely more credible source than nothing at all, and that's all he has offered.

 

Quit flapping your virtual gums and run a couple tests yourself.

 

No science (there's a reason I'm asking for the control group), no data, no intelligence — just a lot of “nuh-uh” and “do it yourself”

 

Yup. Do it yourself. Do you believe that people are here to write science papers about DCS for you? :) This sort of question never came up when such things were being tested, and I'm not about to spend a bunch of time just to satisfy your grand-standing. You've chosen the wrong hill to die on.

 

than some unsourced, unproven claim from a user fiddling in unexplained ways with unspecified LUA files.

 

Well sourced and proven from behavior in-game. You can do it yourself.

 

I gave you the easiest test you can run as a counter-example, and you don't even need to touch LUA.

 

At any rate, the simple fact remains: the official word from ED themselves is that RCS is simulated by siphoning off data from the rendering pipeline.

 

The simple fact is that this is not correct, and it's very easy to test. And you're too lazy to even attempt to prove it to yourself, you'd rather parrot an incorrect quote and grand-stand as if you were better than everyone else. :)

 

PS: You're not going to get smart scaling anyway. ED doesn't appear to want to implement it - they've tried with the 'imposters' system, and while smart scaling wouldn't be quite as ugly, it would still be ugly. I don't know if that is the primary reason, or if there is another, but that's what it is. Similarly, a lot of gains can be had by increasing contrast. There are threads and threads written about this stuff, but the one constant remains: You're not getting smart scaling any time soon AFAIK.

Edited July 4, 2019 by GGTharos

Quit flapping your virtual gums and run a couple tests yourself.

Or you can just give me the data to support your claim. Since, you know, that's kind of how these things work — onus probandi and all that.

 

 

Yup. Do it yourself. Do you believe that people are here to write science papers about DCS for you?

Yes. If you want your claim to be believed, you're the one who has to come up with the evidence — not me. Until you do, I have no reason to believe you over the official stance, even if I really wish that stance to be false. You seem very unwilling to provide this evidence, which casts further doubt on the claim every time you do so.

 

 

The simple fact is that this is not correct, and it's very easy to test.

Good to hear. Then you should have no problem at all providing the data to support your case. Whether that's because you're just too lazy or because this is, after all, not a “simple fact” is anyone's guess…

Ok, then believe what you want; it's your little hill to die on :)

 

PS: Wags saying something is no proof, so fallacy of appeal to authority there ... onus probandi and all.

And that's fair enough, but as far as authoritative sources go, ED's own staff ranks pretty highly and without any evidence to the contrary, there's no reason to disbelieve what they say. Hence why a contrary claim needs to be supported: you disprove his authority on the matter by proving your own claims to be correct. Now, if you want to challenge him to cough up something to support what he says (since that would be his onus), then I'm right behind you…

 

…but until either of those two things happen, his information is the best — indeed the only — thing we have to go on.