Thought Design Experiement

[frederf 0]

Hello and welcome to Thought Design Labs. Today the topic of discussion is centered around the AN/PEQ-2, otherwise known as the inert bit of hardware velcro'd on to the M16A4 rifle made by BIS. The goal of this design experiment is to outline, in practical terms, how a fully-functioning AN/PEQ-2 or similar device can be made as an AddOn for the software Armed Assault (ArmA).

Experimental Subject: AN/PEQ-2

Experimental Subject Description: The AN/PEQ-2 is a small, rifle-mounted, multi-function infrared laser device for the purposes of illumination, target pointing, and aiming.

Experimental Subject Reference: http://en.wikipedia.org/wiki/AN/PEQ-2

Design Factors Outline:

Host Weapon Design

AN/PEQ-2 on host

Magazine-ammo design

AN/PEQ-2 Weapon Design

Laser logical simulation

End-point logical simulation

Intended Obscuration

Unintended Obscuration

Beam logical simulation

Laser visual simulation

End-point visual simulation

Beam visual simulation

User interface and control

Mode select switch

Battery depletion

Device state recognition

Illuminator simulation

Illuminator logical

Illuminator visual

Infrared simulation

Performance and Compatibility

Single Player

Multi Player

Computational Resources

Artificial Intelligence Factors

[frederf 0]

Host Weapon Design: The host weapon, most likely an M16A4 rifle during the development phase, will likely utilize the multiple-muzzle functionality present in ArmA and as found on the M16A4 rifle with M203 grenade launcher.

***AN/PEQ-2 on host: The AN/PEQ-2 device will be piggybacked onto the host weapon like the M203 with a separate fire mode to control operation. The goal is to use the highest number of controls found throughout the original ArmA software as consistently as possible for the most seamless and enjoyable user experience.

***Magazine-ammo design: Since all weapons in ArmA require magazines and ammo types to fire, the magazine(s) should be Battery types. Magazines and ammo are described later in reference to other subtopics.

AN/PEQ-2 Weapon Design: The AN/PEQ-2 weapon is likely to be designed on the premises of logical (and non-visual) simulation of the laser effects and the visual effects done separately for reasons explained in the infrared and beam sections. Weapon design must also consider the switching functionality offered to the user, the user's ability to understand what the weapon is doing at any one time and the possibility of battery depletion as a consequence for continued use.

***Laser logical simulation: The AN/PEQ-2 will likely rely heavily on the existing laserDesignator type weapon for logical simulation of the laser effects due to the similarities, functionality, and pre-existence of a well-working similar device simulation. The aiming and target pointing laser will be considered primarily due to its simplicity and straightforwardness and the illumination function considered at the end as a more complex addendum.

******End-point logical simulation: The end-point of the AN/PEQ-2 should be created in a straight line out of the device at the point that line reaches an opaque surface. Other methods of simulating laser pointers by affixing an incorporeal glowing line to the end of the rifle fail at stopping at opaque objects and pass through them unsatisfactorily.

The standard laserDesignator weapon creates a object that is able to be seen and targeted by some vehicles' weapons. For example an AV-8B Harrier's GBU-12s. While the AN/PEQ-2 is visible to infrared wavelength imaging systems it is not able to be locked onto by ground or aircraft weapons systems. Therefore any object created at the end point of the AN/PEQ-2 weapon should have no defined irSignature value and instead rely on manual visual acquisition and targeting with night vision devices or thermal imagers.

*********Intended Obscuration: Generating the end point should happen at a logical place where the light of a laser would not go beyond in real life. This includes people, weapons, vehicles, buildings, thick vegetation, terrain. The laserDesignator weapon effects thankfully do this to a relatively high degree of accuracy to real life.

*********Unintended Obscuration: The end point should pass through some objects that would not stop a laser beam in real life. This includes glass, water, chain link fences, and sparse vegetation. "Penetration" values may be altered to allow the end point to pass through certain objects and not others. Detailed knowledge of material types may be required.

******Beam logical simulation: AI notwithstanding, the laser beam itself does not need a logical simulation. The fact that the weapon source and the laser end-point are within LOS of each other precludes the need to worry about anything passing through the beam as any object that does so will trigger the end-point to reposition itself onto the obstacle and the beam will be redefined the new shorter distance. Logically the laser beam is inert and is simply derived as a straight line between two defined points.

***Laser visual simulation: Ignoring for a moment the fact that infrared radiation (IR) is invisible to the naked eye, the laser is visibly defined as two parts; the end point and the beam.

******End-point visual simulation: The end point is by far the easiest element of the laser to visually simulate. A simple laserdot object clad in a shining RVmat-defined material would make for a convincing laser end point (for the targeting/aiming laser). The dot cannot be infinitely small but must grow with the distance it travels from the laser source. The default laserDesignator weapon uses an odd mixture of close-range sprite white dot and long range small-square red dot. A small light source could also be spawned at or very near the end-point to simulate laser light being scattered by the surface and illuminating the immediate vicinity.

******Beam visual simulation: Ideally the laser beam would simply be directly drawn into place, defined strictly by its end points and some brightness and color values. Unfortunately I know of no way to do that directly in ArmA. What is available at the developer's disposal is incorporeal models, presumably long, skinny models textured in an RVmat. The model would be placed and oriented mathematically as a function of the weapon location and the end point location.

Creating a convincing beam to span the distance between two very dynamic end points may prove to be the single greatest challenge. A model would have to have flexible dimension in order to be exactly the length between the end points. Perhaps some sort of "uncovering" animation would provide the length adjustment. Alternatively, a beam could be comprised of many small beams tiled together if a dynamic model cannot be created.

***User interface and control: The user interface consists of the HUD elements, especially the element showing ammunition and muzzle name in order to relay the status of the weapon. The control should consist primarily of the 6-position selector switch. Adjustments of illuminator beam spread would be another advanced control.

******Mode select switch: The real life AN/PEQ-2 has a 6 mode select switch to control its two lasers. Presumably the user will "fire" the weapon to turn it on and off, so it would be the most intuitive and user-friendly to have "firing" the weapon cycle it through modes 0,1,2,3,4,5 and then back to 0.

******Battery depletion: After prolongued use any battery-powered electronic device will deplete its batteries. Real life battery life may be so far beyond the practical limits achieved in ArmA that simulating battery depletion wouldn't be wise. Otherwise, battery depletion could be handled simply in the same manner that is use with the stock laserDesignator weapon.

******Device state recognition: Recognizing what state the AN/PEQ-2 is in could be done in several ways (or any combination of). The control switch could be brought to the user's eyepoint during the "switching" animtion in which case the user could directly see the switch setting on the device in the in-game model. Additionally, the number of battery magazines could be adjusted with each mode switch. This way the HUD element showing magazines left would be a number by the muzzle displayName in the upper left of the screen corresponding to what mode the user is in. The magazines would have to be type=0; in order not to conflict with the user's inventory. Lastly, the magazine could be physically replaced by another and the inventory icon could have a visual display representing what mode the device was in.

***Illuminator simulation: The illuminator is more complex because it has a wider and more detailed geometry than the aiming pointer or target pointer. The illuminator would be logically different than the aiming / targeting pointer in that it may call for more and different visual effects to appear. One option is for the illuminator to act like a "headlight" with a directed light source in a small cone.

***Infrared simulation: IR simulation would hinge upon the simple fact that NVD users would see the visual effects of the AN/PEQ-2 while naked-eye users would not. In ArmA there is no known way to have an object or texture be invisible to the naked eye but visible when observed through the night vision filter or any other. Instead I offer that the IR laser effects must be dynamically created and destroyed based upon the vision state of the character. This is the reason for the separation of logical and visual objects in the design so the logical objects could maintain invisible simulation of all positions and only under the right conditions would the visible effects be created according to the logical objects.

Performance and Compatibility: If the AN/PEQ-2 addon is to be successful it must work in a variety of ArmA modes and require a reasonable amount of computer resources to impliement.

***Single Player: One-user mode is the most straightforward implementation. All variables and observers are on one instance of the program.

***Multi Player: With the introduction of IR effects, all visual effects should be created client-side for all characterson all clients. Only the minimum amount of virtual objects should exist in the multiplayer server space to reduce visual lag and improve network performance.

***Computational Resources: CPU and rendering resources must be considered with a system so potentially taxing of computer resources. Resizing of beam lengths and dynamic creating and destroying of visual objects during night vision cycling must be smooth and efficient in order to be viable.

***Artificial Intelligence Factors: The AI should detect characters using the IR laser only if they have NVDs equipped and in use. AI who have LOS on the beam but cannot see either end point will be unable to detect the beam at all. Perhaps a series of "AI detection nodes" littered along the length of the beam will increase the chance that the AI will see the mid-part of the beam. More consideration is required in this area.

[Juan 0]

Sounds pretty strait forward.

So you just want to discuss about it? Or are you actually going to work on one.

The way you put it make it sound very achievable, and that would open the door to range finding using a laser in combination with a scope, for sniping purposes, like the way I use it in my air rifle.

I know that an air rifle and a fire arm is two different things, but the principle of aiming and knowing the amount of sight adjustment to be done by using a laser with a scope should be very similar.

[frederf 0]

The design is supposed to be doable, as very few things are done that are not. The idea seems straight forward until you get into complications of connecting the end point to the shooter visually which is something no one has ever done before.

Simply making the dot appear where the muzzle is pointed as a direct rip off of the laserDesignator is very simplistic and is not the full potential of the device. However it will probably the the first stage in developing the fully-featured device.

Visible laser dots (without visible beam) are probably the easiest to make at this point.

The invisibility of IR radiation is an important feature of the AN/PEQ-2, but it might be ill-spent time and energy as few PvP games are done in the dark where one team wouldn't have universal access to NVDs. The AI might not care one way or the other, although it would be nice to have to think to turn off your IR laser when around enemy with NVDs.

[Espectro (DayZ) 0]

Maybe have the laserbeam texture be an animation which loops slowly to invisible and then to visible. The keypoint is "slowly". This would generate the effect of smoke coming in infront of the beam and makes it visible to the human eye.

This simplifices it alot. I believe it would take too much work to make it work through semi-transparent objects, and not solid ones. It should be stopped as soon as it hits anything the BI laser designator interprets as solid.

Is it possible to stop drawing an object (laser-beam) whenever you want to using scripts? If not... You can create small bits of the laserbeam and make it be drawn in a straight line, until the nearest object. I am thinking of bits as small as 10 cm. It should also be stopped at some distance, say 150 metres.

So the beam will be divided into 1500 10 cm long laser beam parts when it's longes:

--------------------------------

-------------|House or any other solid object|

As mentioned earlier... The small bits would have be animated texture (low resolution), going from almost solid beam to completely invisible (most of the time). This would also give the effect that there are different particles throughout the range.

[Wolfrug 0]

You might also want to take a look at this:

Mando Draw

Just our resident scripting-guru having a bit of fun with weaponDirection, but it does look pretty cool. Wonder if you can have one single, really long particle that is defined the lenght of weapon muzzle -> laser dot.

Making it only visible in certain spectrums might be the hard part tho.

Regards,

Wolfrug

[frederf 0]

I'll take a look at the Mando Draw mission. Particles may indeed be the answer, if they are configurable in length. IR spectrum compatibility is still theoretically possible if the particle is created and destroyed client side and as a condition of IR vision yes/no.

Espectro-- If the beam indeed is tiles of 10cm models laid end to end, perhaps they can be spun at a low speed, be triangular with only certain faces having the visual texture/RVmat. That would provide variable visibility. However all videos I've seen of PEQ-2 like devices had a very solid and constant line regardless of dust level.

Indeed the idea would be to create/destroy the laser beam objects dynamically in order to have the beam the right length.

[Winters1807 0]

sounds cool, could be a way to increase the ability of aircraft to support ground troops if the target is marked with lasers

[Panda-PL- 0]

Get a functioning demonstration addon out and people will use it.

Your problems:

1) you cannot check when NVGs are used

2) you cannot set custom anims on weapon models

and

3) experiments with tracers show that ArmA has a habit of moving objects up if they end up below ground (so the ray would run away if you looked down).

4) it is probably impossible to detect if the line hits objects with required accuracy.

5) particle approach is not possible perfoirmance-wise. You'd need thousants of them!

Best I came up with was making textures nearly invisible durring daylight with rvmat settings.

[frederf 0]

1. There has to be clever ways of finding out the state of the NVGoggles; if that was the only hurdle believe me it'd be solved inside a week. Current ideas are: make new NVGoggles that launch script on use, utilize the UI eventhandlers (e.g. onSingleMapCLick, etc), captureKeys the "N" button, etc.

2. I doubt that's true.

3. The particle shouldn't be asked to go below ground ever.

4. You never need to detect if the line hits objects, read up.

5. Or one really big particle.

The idea of using RVmat materials is generally more appealing, especially with the idea that config.cpp's can be rewritten and modified on-the-fly, the object could specify one of a few models, rewritten on the fly, one invisible, one visible. That'd help with the on and off visual switching.

[Grinman 0]

For the laser effect, perhaps a 'weapon' with 0.0000001 damage and an incredibly high ROF (*stupidly* high) and red tracers

I dunno if this has already been suggested, whole thread is tl;dr

[jasono 0]

When you fire a weapon in ArmA, even if its 0.0000001 damage.. it creates a spurt of blood. So, step in front of that thing and you'll hear and see the blood splatter.