Support of different wavelengthes in ArmA2

[S!fkaIaC 10]

But conclusion is that BIS could implement a generic simulation of different radiation even with the ArmA 1 engine in a common way so that not every modder must invent its own way, right?

[gonk 0]

Thermal imaging is easier than an extra LOD; it'd be only an extra material setting and an extra texture. That texture would take only little memory, since it doesn't need to be high-res and it only needs one component (intensity), or two (intensity and alpha).

damn... I forgot about those options in Multigen materials settings... been a while since I have touched it. Would be nice to see implemented.

[max power 21]

As for Radar: Well, since it's not a 'visual' thing, it's possible to script it. This indeed requires to raycast into the world; for vehicles it's easy to do. You check if the vehicle is in the radar cone, you use an 'abstract' RCS-value (radar cross section) to calculate the reflection 'power' and display the radar return accordingly. If the vehicle in the cone has a ESM-sensor, well, you notify that vehicle/pilot of the radar spike.

Also, it's easy to simulate two different radar wavelengths, since it would be just querying if the sensor supports wavelength 1 or wavelength 2.

This is mostly very simple vector math and using the right programming structures.

As for ground clutter: Well, it isn't much different than the above, though I see performance problems. Also, how to draw that (ground) radar screen?

It doesn't even need to be raycasting. All you need is some parameters of radar performance and some other parameters of target specular. From those you can simply have a program that solves using some element of probability. It may even include some information about target aspect.

As for the materials, I was doing some research on the subject for ACE mod and I was able to make some pretty sweet RVMats for IR but there is no capacity to change them on the fly in the ArmA engine. The only way is to do hidden selections, which is work intensive.

[PhilippRauch 0]

'work intesive' on the engines part? or on the modeleres part, creating and setting those selections?

[S!fkaIaC 10]

All that needs to be guarded by BIS since we need a "normal" else each modder would parametrizing "signal strength" and "sensor sensitivity" relative to his own addons and if you put all together in one mission a BIS Mosquito might have the same radar print as a Boeing 747.

[vektorboson 8]

It doesn't even need to be raycasting. All you need is some parameters of radar performance and some other parameters of target specular. From those you can simply have a program that solves using some element of probability. It may even include some information about target aspect.

Raycasting is definitely required, especially for terrain masking. The raycasting is also required for the radar cone, were the ray is just the 'axis' of the cone.

What you call target specular, is what I call RCS-value (which should be dependend on direction, external loadout and other things like gear down/open baydoors).

All that needs to be guarded by BIS since we need a "normal" else each modder would parametrizing "signal strength" and "sensor sensitivity" relative to his own addons and if you put all together in one mission a BIS Mosquito might have the same radar print as a Boeing 747.

Different modders using different values will happen anyway, even if there's a standard made by BIS. As for the Mosquito vs Boeing 747: That wouldn't happen since the Mosquito wouldn't be in the 'radar receivers list' at first.

If I have time, I may code a simple radar system example to show how it possibly may look like.

(but wasn't something like this already made by Mandoble or Spooner?)

[PhilippRauch 0]

spon_radar ... even with some 50s style radar screen ... could be even used in various modes and still its lot of space for more functionality ..

i think about a trigger being rotated around the radar station collecting lists of all units, or one large trigger gets all 'radarenabled' vehicles and the other. rotating, trigger adds or removes them depending on some conditions and direction of radar dish.. like line-of-sight, decoy, atmospherics etc .. this then can also be used for tracking radars... even radar cones could be made by dividing the trigger into several triggers, each with different width and all aligned along the radar middle axis on their respective positions....

Edited April 23, 2009 by PhilippRauch

[max power 21]

Raycasting is definitely required, especially for terrain masking. The raycasting is also required for the radar cone, were the ray is just the 'axis' of the cone.

What you call target specular, is what I call RCS-value (which should be dependend on direction, external loadout and other things like gear down/open baydoors).

If I have time, I may code a simple radar system example to show how it possibly may look like.

(but wasn't something like this already made by Mandoble or Spooner?)

The game already knows if something is occluded or not. It's got all kinds of built in tests in the ai and the sound engine for deciding what is occluded and what is not. These systems also already have speed and heading in. Whether that is done by ray casting, I do not know.

The purpose of radar is to find out unknown information about objects in space. In the game engine, all of this information is already known by the program. The trick is to manipulate this information in algorythms to produce a satisfying radar simulation. Having a totally seperate sim for radar is not necessary.

Edited April 23, 2009 by Max Power

[vektorboson 8]

The game already knows if something is occluded or not. It's got all kinds of built in tests in the ai and the sound engine for deciding what is occluded and what is not. These systems also already have speed and heading in. Whether that is done by ray casting, I do not know.

The purpose of radar is to find out unknown information about objects in space. In the game engine, all of this information is already known by the program. The trick is to manipulate this information in algorythms to produce a satisfying radar simulation. Having a totally seperate sim for radar is not necessary.

Sorry, but I don't get your point. Are you now talking about BIS implementing radar themselves, or about the community implementing radar?

If BIS keeps the magic infrared radar, then a 'totally separate sim' for radar needs to be made by the community.

Either way, it could be done pretty much the way I have outlined; and yes, visibility tests are normally done with raycasting (there is also another way to make an occlusion test: render the scene without the tested object, then render the tested object and count how many pixels were actually drawn).

[max power 21]

Neither. The OP was wondering about a electromagnetic spectrum simulation. My point is that it's not necessary. Further, it is my opinion that having seperate raycasting procedures for radar is also not necessary, given the game already knows a great deal about the world and the relative positions of objects. I don't think anyone is really talking about serious implementation except the discussion about Spooner's addon.

[.kju 3245]

In what way is the BI radar system limited?

It does take into account viewdistance, fog, object, terrain elevations and different

configurations.

The locking system is very limited, simplified and bad for gameplay, yet the radar

part (apart from available for units not meant to have it) is quite ok, or not?

[max power 21]

It's not at all realistic in any way. Personally, I think it does the job of what it's supposed to do- that is to give the player as much awareness as the AI has. As far as a simulation of radar, though, it's totally out to lunch.

[sidhellfire 0]

The funny thing, is that despite all the magic that comes with the poseidon IR radar it's still easier to find, target, and engage enemy target in any flight sim from LHX/F19 to Lock On/Falcon4.

[vektorboson 8]

The OP was wondering about a electromagnetic spectrum simulation. My point is that it's not necessary.

Well, that was my first statement in this thread...

Further, it is my opinion that having seperate raycasting procedures for radar is also not necessary, given the game already knows a great deal about the world and the relative positions of objects.

That's nice that the game knows about it. If you can get this data out of the engine, that is suitable for radar simulation, then good. I don't see how this can be done (if there is a solution, I'll be happy to know it).

In what way is the BI radar system limited?

It does take into account viewdistance, fog, object, terrain elevations and different

configurations.

The locking system is very limited, simplified and bad for gameplay, yet the radar

part (apart from available for units not meant to have it) is quite ok, or not?

I hope I could say something good about BIS "radar", but I can't think of anything.

BIS "radar" is

• omnidirectional: It knows of any contacts in every direction; jets for example need to turn if they want to scan 360°
  
• passive: any contact that is on the 'radar', doesn't know about it; thus also no means of simulating passive/semi-active missiles (without a custom simulation)
  
• infrared: the "radar" isn't a radar at all, but more something like the IRST on the MiG-29 or Eurofighter; as soon as the engines are off, the target is a white box, and can't be locked by TAB
  
• friendly/hostile: it can discriminate friendlies/hostiles/neutrals; but that discrimination depends on the engines running!
  
• viewdistance dependence: actual radar is not dependent on 'view distance' (well, if there's really really bad weather)
  
• anti-air and surface radar at the same time
  

BIS radar is not only bad from a realism perspective, but also from a gaming perspective, as kju already stated. It's a workaround for shortcomings in other fields.

[S!fkaIaC 10]

It does take into account viewdistance, fog, object, terrain elevations and different

configurations.

But I do not know in which way to get a clue to tune a new type of radar receiver or transmitter. In addition the current simulation only shows units of a certain category, not just objects.

Take the shilka radar as example (which is the same "vehicle scanner" generic for all other units which should have it) which is an old machine, but "vehicle scanner" works like a SuperTargetHyperMachine with following features:

- friend/foe detection

- can partly look behind hills

- can track endless targets at full 360 degree

- must have intelligent SW that can detect from the shape of an object if it is civilian or not and if a crew is onboard or not

- it can detect destroyed vehicles, they disappear from screen

Well, such features I could partly believe in a modern russian system, but not in a shilka, and not in the helmet of one of the doorgunner in the UH60 in ArmA 1.

You understand now what I mean?

It is a modern WarSim, but most of the electronic systems are simulated totally wrong.

Edit: vector was faster and explained much better

Edited April 24, 2009 by S!fkaIaC

[PhilippRauch 0]

It is a modern WarSim, but most of the electronic systems are simulated totally wrong.

First its more like a 'world simulator' tuned to military style gameplay and I believe that there are no proper weapons systems 'emulated' is because BIS developers are software developers/coders not military advisors/engineers... Still i would love to see all mentioned things ingame, but hey its step by step... maybe its just too early to think of waves inside a game, maybe ArmA10 or after FARMA hits the markets :D

[.kju 3245]

Thanks for the heads-up!

I very much agreed that the listed changes would make gameplay a lot

better as well. Though not be easy to do your own system.

Sounds like a nice challenge and a perfect addition to the Communtiy Base Projects (CAIRSP). :bounce3:

With vektorboson interested, this might turn out getting somewhere.

[shinRaiden 0]

Presentation of dynamic stuff like this typically has to take one of two approaches.

First is the 'simulation' approach. This orientation uses of actual scientific models to provide a statistical sampling of the whole effect. For example, it's impractical to simulate the individual effect of n trillion rain drops, but the maths for liquid reactions over time are simpler to project. Similarly it would be impractical to calculate a fully 'natural' environmental spectrum, but it is practical to artificially 'clamp' distinct modes. From another point of view, even wide-spectrum analysis tools have fine-grained filters to focus on the very narrow and specific objectives. There's little need for example to do a full water vapor simulation when you're filtering for RF propagation, simply insert an appropriate approximated coefficient.

The other approach, that used by 'serious games', instead bypasses the simulation of the natural phenomena to rather present the observed effect of the phenomena. So instead of trying to simulate it, they skip that whole process to directly replicate the observation. An interesting theory, and in practice can occasionally result in a higher fidelity presentation than a traditional simulation system. It does however have its inherent weaknesses, as they tend to be extremely limited in scalability. For example, in OFP/ArmA rain is presented as a billboard'ed visual effect. Like with other games, it provides an atmospheric presentation effect, even though there is a lack of hydrodynamic or thermal or other environmental effects.

Non-visual spectral presentations in the 'serious games' approach are challenged by the typical lack of necessary systems required to accurately replicate the differences in propagation between visual and non-visual emissions. Game models typically use face-based modeling, rather than solid object models for visualization. Pseudo-solid object components such as collision geometry - simply collections of dimensional properties - merely provide static parameters and do not for performance reasons typically provide adaptive materials.

Performance optimization methods in computer graphics assume static objects that can be readily replicated and directly rendered. Implementing the various degrees of procedural modeling required to provide a dynamic visualization more accurately reflecting non-visual spectrum emissions requires renderer design outside of traditional hardware optimization capabilities.

For thermal imaging in VBS2 a hybrid approach was done. While it was obviously impractical to change the renderer to a procedural solid object model, inspiration from that approach was used to create the texture maps for the objects. The RGBA channels record in separate channels the various emmissive characteristics to provide a range of presented visualization dependent on metabolism/utilization, environment, and other factors. As a result, the texture map generation process is quite complex, but the rendered effect simply uses a different shader modes to present a visualization of the net effect of the object.

EM/RF simulation would have similar challenges, that in a gaming world would probably still have to be addressed as a presentation of the observed effect, rather than the direct simulation of the phenomena.

Aside from the technical complications, there's also the aspects of business objectives (eg would the investment required to include the expanded spectral presentation realize an appropriate return on investment) as well as propriety (paper-pushers take a dim view of lulz-ware that can be repurposed as an arguably adequate systems trainer). But, opinions on those matters vary widely and are founded on the morass of impatience, jealousy, and covetousness.

[S!fkaIaC 10]

EM/RF simulation would have similar challenges, that in a gaming world would probably still have to be addressed as a presentation of the observed effect, rather than the direct simulation of the phenomena.

Since the observed effect is usually classified, it might be better to stick to the phenomena, we can find it in every school book ;)

The effect (how does the weapon system detect ) is still unknown, but one can try to rebuild the addon somehow as it works in principle.

[max power 21]

....

Dude, maybe you missed the point where I was saying that I don't think anyone is talking about implementation. If you want to program a radar sim, go for it.

[S!fkaIaC 10]

Common conclusion is...leave it as it is in ArmA 1?

[7 0]

Common conclusion is...leave it as it is in ArmA 1?

No... :cry2:

[max power 21]

No, the conclusion is that it WILL be like how it is in ArmA 1, regardless.

[S!fkaIaC 10]

:crazy::confused_o:

[7 0]

Couldn't have put it better myself.

I'd gladly become a BI groupie if they implemented atleast IR spectrum.

:don 12: