Back-end tooling

This week saw some changes to the flight model test bed, fixes for the helmet mounted display, changes to how the mask is positioned to allow for custom sizes and the class for handling FFAR rockets is being added. This last part raised some issues with different warheads doing slightly different kinds of damage and how different objects should reacted to these forms of damage. It was clear the object database file needed population. As much as I love punching in numbers for hours on end (no not really) it made more sense to give the job to someone else.

I finally got off my bottom to start writing some simple C# tools to facilitate content production starting with the vehicle database. Data is stored in a localised development database then exported to the game. There's quite a lot of data to add with regard to crews, sensors (line of sight) and weapons. For now this is enough to get some calculations in for armour penetration which I need to test the different FFAR rocket warheads. Dave expressed an interest in ricochets which is doable since at every impact we know the amount of energy and angle of impact. I'll stop short of thermal damage for now. Most ballistics and armour penetration math comes from (again) Physics for Game Developers which lists some coefficients for common shell sizes. As we want to include asymmetric protection in our simulation, tank armour is weaker at the rear or flanks, we need to express this data as a  coeff modifier in the database.

Mk1 vehicle data editor - 

While building the campaign database it became apparent that connecting maps would be possible with an additional field to index which map each campaign element belongs to (e.g vehicle groups and strategic nodes). It wasn't something I considered as production was focused on a single map. Since maps take so long to hand craft splitting regions into discrete maps wasn't in the design document. Longbow 2 divided up the terrain dataset into a sliding map arrangement which is a bit different. The option should be there to allow us to load in the next map over when crossing a map border (or trigger zone) at the expense of having a long load screen. I'm not going to add this but I will leave open the possibility to go down that route should we want to add DLC to expand existing campaign maps. Ideally we'll end up with a better version of the engine in 12 months time which can stream in additional map data seamlessly.


*update*

Game launcher/auto-updater. Need to sort out the server requirements but it shows promise, better than other off-the shelf solutions I've tried. There's news, serial number and other elements to add.

PNVS - short video

Short video showing the PNVS, mostly complete, some level balancing to do which will wait till testing.

http://vimeo.com/24074674





*Edit*

Tinkering with the PNVS/HMD mask today to fit symbology and again one of those quirky realism vs. expectation problems became apparent.

Looking down the HMD egg with video on, the video underlay appears as a slightly ill-fitting rectangle within the near circular lens.

To borrow a crude diagram...

Which looks like a family slide-show thus...

This looks odd without graphics for a surrounding combiner lens frame which is something I'm resisting. A recent AAA console game had this which might look cool but blocks visibility. A more rounded image is better on my eyes (see below). I really prefer my original one though.

PNVS, programmer now very satisfied

I have a terrible head-cold and ache all-over so not in the mood to sit at my computer for much longer, on the whole there's no real visual difference you'll detect in the PNVS in this re-write today.

I found a texture output channel Leadwerks only uses for Global Illumination (emissive alpha), we don't need GI so I hijacked this to store heat-map information. This is normally invisible and can only be viewed when rendering a copy of the gbuffer (or small rectangular area)  via a PNVS post shader. This is hiding heat information in the scene which is then made visible when writing a mask or rectangle over the buffer using the PNVS shader.

Heat maps can now be added to smoke and flame effects, these should work for TADS, NVG, PNVS rendering without special treatment. Which is what I wanted in the first place but couldn't easily, the Leadwerks pipeline is a little cramped at this point and I felt it was important to do this in a single pass for performance reasons.

This also works with any shaped mask and works flawlessly with GLOW maps (emissive textures used for headlamps, instrument lights etc.), these don't use their own alpha channel. Only issue is the instrument symbology which uses this alpha channel to mask off video underlays on the MPDs, this results is symbology showing up quite bright in close up external views (which just looks pretty but not intended).

One thing still to do, calibrate the mix of background and heat-maps to balance illumination in total darkness.

This week saw a fair amount polishing to view system, two different camera motion systems and more weapons tweaking. Camera motion based on Cubic motion conveys smooth formation flying, since posting a short demo video on Vimeo I've since changed it so the motion is based on the 2D motion of the tracked object in the frame so there's less 'wobble' if it's flying towards or away, and plays 'hard to catch up' if flying across your point of view. Works remarkably well. The other camera motion setting will be good for weapon cams where short attack and decay vibrations convey kinetic energy.

AD set about the tree normal problem, creating a new set of trees to experiment with along with custom billboard models. If you see strange looking elf trees over the next few days don't be too surprised. Dave spent some time playing World of Tanks which inspired some ideas on destructible environments. Completing a building in rubble model that I hope can be re-shaped to fit small models when they are flagged as destroyed. We can use the FX system to mask the transition with debris and dust.

Heat maps now a post-effect, making invisible buffer information visible

Terrain is too dark, will fix that

Improved sky and ground visibility

Added some heat information to the terrain tile shader based on red albedo and specular.

Some fine tuning of light levels and electronic noise. Viewing the PNVS without any 'egg' tinting so I can see what the buffer looks like. Bright objects seems to flare OK, here's a strobe going off.

Dust and light particles push to the heat buffer. I left in a smoke type that masks heat which might be useful for aerosols.

Screenshot of the day

Today was reasonably productive. Pencilled in for this week is completion of the HUD which is under-way. Although I took time out to fix some outstanding game camera class issues, auto panning and zoom flypast view and hand-held camera motion. Both of which I never get tired of.

I was reminded about the IDM or Improved Data Modem this morning which is how you share targets and PFZs between aircraft. The place-holder message handler was put in (message route is HELO > AVIONICS), I just need to get it to add an alert message into the upfront display with a suitable bleep. Then it's a matter of parsing the message content.

Camera shake really kicks up the drama, but don't overuse.

Had a lot of fun just cruising around capturing choice flypast and formation views while testing. I noticed some rotor-blur issues (write masking) that will need fixing and a rare unexplained mesh occlusion where the main body of the helo will vanish for a few frames. I've noticed the stobes do this and think it's some AABB bounding body issue in the engine, it's so rare I've not been able to pin it down yet.

Cannon reticule almost done, currently missing means to manually enter range data but the game console will do for now.

Another quick update

A query at SimHQ by "nadal" prompted me to add another setting to the HUD config to allow for users with colour blindness to change the PNVS video to any hue they want. This brings it in-line with the HUD symbology. Both can be configured with different hues using RGB values 0 to 1 (0 min intensity and 1 is maximum intensity).

Also added a dynamic field-of-view to the flypast camera (F5) which makes for nice screen-shots and videos.

Gun firing during a sideways flypast

Programmer Not Very Satisfied - PNVS

It sort of works which is the main thing. And it's fast. Combining the functionality of the PNVS but ease and speed of pilot point of view rendering. Each pass of the deferred rendering stage, geometry, light and transparency is blended in a different way to recreate the PNVS image that's 99% perfectly aligned (I added a very very small level of transparency so the image slightly lags when moving you head quickly).

Manual mixing of video levels for a good balance

Alas I couldn't do this in the way I wanted but the results are not bad. It was a royal pain to have to clip geometry, the material to 'see through' needed a flag adding to it, the fragment shader needs a uniform to know if the PNVS is active or not, heat-maps have to be added to materials. The good side is that the diffuse colour is still there but the heat map is rendered into the 'glow' buffer so they kind of radiate if you have your glow video setting enabled.

Contrast and brightness are enhanced in the final PNVS image via a post-processing shader. I could in addition add the old light amplification function to this too but I don't think it's necessary. During full daylight it burns out your retinas if you have the video level turned up to max.

All in all I'm sort of OK with it but not satisfied. I simply wanted to blend heat-maps as a post-process and not a form of multi-texturing which is inelegant.

AD had a little play and looked at some of the interesting glitches that occur when you're clipping geometry so you can see through it. This is down to the move from a virtual camera to a 'mouse look' view point, you can move your view beyond the constrains of the PNVS. So AD suggested a rather neat solution of fading the PNVS image at the constraints which works brilliantly. Nice smooth fade out when nearing the edges although I chose not to apply this in external views where bad clipping isn't a problem.

Still need to sort out the scale and mask size/shape which won't take long. AD has everything needed to build heat-maps for the remaining assets. Soon everything will be a blaze of black and green. Did I mention that tracer fire looks pretty cool?

Transparency, lighting, particles, heat glow maps

PNVS redux

Short update on this.

Dispensed with the headache and nausea inducing PNVS camera. Copying the physical arrangement virtually does not translate to a 2D video environment. And thanks to that man who emailed to sympathise while sitting on the pad, that made me feel less of a wimp.

I've got a much much faster and smarter solution working for the PNVS and I'm very happy with it. A few rough edges still (it needs more of a smooth edge) post-processing will add contrast enhancement and edge detection. Parts of the helo are visible through the floor of the cockpit, like the TADS barrel and forward avionic bays, these need to be removed using geometry masking when the PNVS system is active. Since the PNVS area always stays in the same place it's easier to accomplish.

What I need is a Portal hole. Again shaders to the rescue and I'll employ a texture channel to act as a discard mask when the PNVS is on, unless something simpler comes to mind.

Anti-col light half in and out of the PNVS frame.

devs quick test zone, lighting and transparency blending

Transparency and lighting is now blended to the PNVS buffer. Gunfire, explosions etc looking quite good at night in refreshing mint flavour vision (tm).

Some post-processing gives control over contrast and brightness while desaturating the image. Still to do, image enhancement and then the large task of adding heat maps to all necessary assets which when rendered in a single pass will be applied to the emissive output channel. And it hardly costs any frames, brilliant.

first heap map test

Crew and external cockpit detail

The Duke now sporting detailed external cockpit and crew complete with working glass instruments. Excellent work AD. We'll get some rudimentary animation sorted out, head movement will be tied to sensor operation shortly.

Peek a boo

Get that laser out of my face!

PNVS is giving me a headache, literally

I'm not going to post a screenshot of the PNVS yet as it's still quite primitive. I'm just putting in the building blocks of setting up the camera, rotation constraints etc.

Currently I'm taking a camera view from the nose of the aircraft and blending it as a layer under the IHADSS. The camera is not stabilised for head roll which I'm guessing the real PNVS system is.

First impressions of flying with the PNVS in this early state is that its bloody frighting. My eyes were not happy with it. A slight ghosting effect caused by subtle differences of the distance between your head position and the nose camera and rotational delay of the PNVS unit is something that will either take some getting used to, or will have to be thrown out as just too unpleasant for gaming. Bordering on the f*cking horrible actually, no wonder crews get headaches and this is on a monitor never mind an eyepiece. I'm getting headaches too.

The way to do this is good old fashion game conceit and match it up with the main camera perfectly aligned with no lag otherwise nobody is going to want to play night missions. It's not a problem you get with night vision goggles since your POV is the same, in many ways that's easier to implement.

*edit*

The camera position is now locked to your viewpoint much how goggles would be and adjusted the fov to match. Ignore the masked area for now, it's all going to be changed. The PNVS images needs to be larger than the IHADSS image so it fits inside the circular mask. Heat maps are not being rendered yet, and the  PNVS material does not have the night vision shader applied yet.

What it does show is the sense of having the ability to 'see through' your aircraft, like having x-ray vision. As it is now, I can perform decent landings at night without going cross-eyed.

IHADSS back in the tool-shop

The final part of the weapon system for the Apache involves a ton of logic to get this working in all my little black software boxes. It needs to handle many situations, for example the CP/G firing a missile with the gun obstructing the launch rails. With different sights selectable by crewmen, messages and high action display format needs to be updated in a timely fashion for each position.

General things still to add, aim reticules and more heading tape markers for various things. Some improvements were made to the internal HUD rendering, a fair chunk of it could be optimized later much like I did with the MPDs.

The High Action Display now has zones for messages updated by the ApacheAvionics class, slip ball and the FOV box needs some logic to deal with the currently selected sight. So that's some of my worksheet for the weekend. I move the whole H.A.D down a bit as it was too low to fit all the messages that are supposed to be around there. Native resolution is 512x512 for the interested.

Screenshot of the day

Only took one today so it wins by default. I recently changed the arming system to make things a bit tidier, sometimes pods would slightly sit under the surface of landing pads and the arming option is disabled if there are no arming crates around.

One change I want to make is how rockets are loaded into 3 zones (rocket tubes are grouped into 3 areas or zones that can be selected individually allowing you to load your helo with 3 different types of rockets). There's a need to present this graphically in the above interface, somehow.

*update*

Thanks for the suggestions on zone loading. Keep 'em coming if you have any more.

This morning I was quickly adding some performance options to the config, cockpit pre-loading and real-time lighting. Pre-loading is something that engines like Unreal do to prevent stutter, here it's a bit more fundemental as cockpits are potentially quite large, there can be a bit of a pause between mounting and being in your seat (around 5 to 10 seconds first time you mount). To streamline this I added pre-load cockpit option (on by default). When we have two or more cockpit interiors to choose from this option will be of more use.

Went for a joyride this morning over the range to test it out. The new AOE cannon burst damage really comes into it's own, still takes a few rounds to take out vehicles. HUD work today followed by more work on the vehicle database.

Here's another one of looking back through the dust-off effects, I added user options for contrast, saturation and brightness. You can get some interesting looking views depending on ambient conditions and time of day.

Returning to base. Oh look it's lunch time.

Just a few more for fun. Only changing the saturation setting in the config you can play in glorious mono...

Well almost, the effect is ruined in the cockpit as it's rendered in full colour along with the HUD and explosions on the ground (which in full colour against a grey backdrop does look rather arty farty).

Colour? Who needs stinking colour? :) Enough of this, more serious work is coming up.

20 knot smoke

For someone who wanted to see what smoke looked like at 20 knots.

Busy weekend

Sunday night, this weekend we're we're back at full three man team strength. I can tell Fred's working hard on the physics as my DropBox folder is constantly getting updated. Inspired by a Microsoft blog of how a remote team collaborated on a project we used a combination of Skype, TeamViewer and Dropbox to edit and test live across countries.

AD has been fine-tuning his graphic pipeline and performance. As always Combat-Helo is a work in progress. After release the intent is to continue to fine-tune and improve for as long as we can pay the bills for it. As always AD kicks it up a notch, always finding new ways to makes things work that bit better.

Recent shots published at SimHQ of the US Firing Range / training area.

His work makes my screen-shots look crap in comparison :) Most of today was spent adding blast radius damage effects, wind and replacing the potentially seizure inducing 30mm cannon muzzle flash with a non-flashing gas expelling effect which is almost there but needs some artistic love to get the materials just right.

I am very pleased with the explosion and secondary effects and I think all the functions are in place that we can throw in some good vehicle data to make it behave. It's starting to play like a Longbow game of the 21st century.

I can't thank the team enough for their hard work and giving up their free-time over the weekend. The Milky Bars are on me chaps.

Plumes at approx 1,800m

Plumes at approx 1,000m

Took 3 passes to bag 6 targets, first two in the middle, then the left two followed by the right in a final overhead pass.

* edit *

Modified cannon impact code to do AOE damage to emulate exploding shells. Anything in a 10 meter radius of each impacting round is subject to damage checks. Each 30mm round is said to be like a grenade going off so small amounts of frag damage are applied.

This greatly improves effectiveness and gunnery.

Realistic delay of explosion sounds I've kept in for now. Coming up next up is the HUD update for weapons.

Splash!!!! Arghhh Arrrrrrghhhh!

Splash damage, the effect of damaging nearby objects based on proximity to an explosive force.

Very easy to implement and abuse. In my first attempt I didn't realise that entities such as a vehicles individual wheels, turrets, in fact any child object on a vehicle would also generate damage mesages. The result was a single tracked vehicle repeatedly applying small amounts of damage to every nearby vehicle and object. Everything, and I mean everything exploded in a fraction of a second and scared the shit out of me.

OK, next try I made sure to only apply splash damage to the parent vehicle. Success, nearby vehicles/objects began to smoke. Moving to the firing range it was all too tempting to try it out on the stagefield.

Spawning an AH64D I mounted, armed the cannon and pulled the trigger. A few rounds thudded into the concrete apron...which then exploded..still incorrectly flagged as damageable by 30mm the resulting splash dmg of the 1km long object was passed on to nearby objects. The entire airbase, local road network, phone poles, basically everything as the database isn't being passed over them yet, exploded. At an FPS of about 0.01 it was hard to see what was going through the wall of near motionless flame. The entire map blew up in my face. Too bad I don't have one of those low frequency transducer Buttkicker devices, I think I could persuade my wife to get one if she could remotely activate it.

Well that's one way to bring a computer to its knees.

OK, clearly a little more thought is required here. I changed this so  now a list is built and filtered for each explosive force which eliminates cascading effects. Effects will also be mitigated by the vehicle database including splash damage factors, for example, a fuel tank is likely to do more damage than a lamp stand. Indeed, objects such as flag poles should just break. I referred to Just Cause 2 for tips on how this kind of process can be set-up. This is a straight mesh swap with a damaged model and a non-persistent debris object that is driven by the physics engine till coming to rest. To make this happen without additional art work requires CSG operations on meshes. Otherwise it requires pre-rigging meshes to split or just additional models such as what we did with the vehicle entities.

Damage over distance

Inverse square law is a nice simple to understand physical law that applies to some force or energy that radiates out from a single point. Energy spreads over an area in proportion to the square of the radius. There are variations, one of which is inverse distance law which doesn't drop off so quickly and a tiny bit faster in terms of CPU cycles. It's simple enough to describe the attenuation of a blast as a percentage of 1 over distance.

blast_percentage = 100 * (1 / distance)

When damage is applied to an object this base damage value is modified by armor and damage type. If we delay our splash damage messages by (distance / speed of sound in meters) you can get a very interesting cascade effect that approximates the propagation of the blast wave so not everything will explode at the same time.

Third attempt, still OTT

So, tip for the day, if using ForEachEntityInAABBDo, create a list, filter it for the source entity and make sure you're only adding top level entities. And skip duplicates. Keep the source entity handy as you'll need that to compute distance as a damage modifier. If you're using physics to punch objects around you can also use that to apply a force and send objects flying everywhere.

Above all, have fun.

Sorry, just a handy target rich area for stress testing.