Range targets

Art dept. has been going into overdrive today taking existing assets and giving them a 'make-under' would you call it? Distressing them to the point where they are nothing more than rust buckets which wouldn't look out of place in my driveway. My car looks like its survived an atmospheric re-entry.

Another thing Leadwerks does really is piles of rusty garbage. We needed something to shoot at on our firing-range that resemble old vehicles. Photographs of target ranges will show large white tanks painted on the ground, or have descriptions including old cars and containers. As this is video-game land where assets are virtual we can do what we like. We can populate the firing-range with  rusty cars and Russian Tanks/BMPs.

I really need to sort out some procedural grass somehow. It would add so much more depth to exterior scenes, can't use engine veg for grass as it's simply too much data for the large outdoor areas we use and shouldn't be necessary. This is one area where Unity really scores. Mixing the large and the small is something neither engines are great at, Leadwerks has more positives in this regard even though they are both really made for creating small scale level based games.

Completed some bug fixes today, waypoint selection was confusing, the HUD was telling me to go in the opposite direction to the map, which is down to the helicopter being aligned down its negative axis.

Also the special effects system we need for 'blowing stuff up' is taking shape. For days (weeks) I kept putting it off as I'd think about how it should work, how well it would scale, changing my mind. Problem with OOP programming is that there's more than one way to instantiate cat skinning. I'm a visual person (right brain dominance), terrible verbally, in phone interviews I can manage my name and sometime my phone number. When it comes to programming complex systems it's easy as pie to see them in my head as dozens of discrete interactions but don't ask me to describe it (blog writing isn't improving my skills any). However the FX system had many versions running around my brain with no clear advantage to either approach.

So I'm adopting a singleton effect manager. As this is easier to scale and debug. Each effect type (smoke, fire, crater etc) as it's own class instance added to a linked list, each type managing the max lifespan, max count, update logic. Some effects being less resource hungry than others can be processed over several frames, others are more dependent on time between frames. This is easier to control in a single manager. I don't know if this is also what might be called a factory? It's been so long since I worked in a office with real people I'm not clear what current terminology would be. Someone asked me about design patterns the other week, I thought they were talking about bloody knitting, even though we'd been using re-usable code concepts for over a decade. I blame yuppies and their fancy frothy coffees.

Aha, it could be considered an "Abstract Factory Pattern" (I just looked it up). Really don't care what you call it. It should do the job as adequately as any other approach and be a bit easier to maintain and debug.

To finish, here's a screen-shot of a fuel bowser and interior of the gas station...although you wouldn't normally get to see the interior in game. Why does it make me think of Duke Nukem?

*edit*

Ground test cannon fire on static objects. Each round impact is creating two emitters, one for dirt material and another for dust/smoke. Work needed to give it more visual 'pop'.

Smoking or non-smoking?

Metal rain.

The above shot for Pavel. Showing dust from a 10 round burst at an object 10 meters away. Dust duration is now set to 16 seconds.

End of week progress

A short video of a live fire test courtesy of DEVLEAKS, captured as it happened from my iPhone. Just showing Dave the shell ejection at work.

Update...Gas anyone???

Firing range gas station for the highway that runs through part of it.


This week...

Bad memories of programming Misioneer resurfaced when dealing with variable map scales, orientation and panning. This wasn't so bad as we have a non-resolution dependent display system work with. MPDs are simply 2 units across. So we can plot game units directly to the display simply by multiplying them with a mapscale:

float:mapscale = 2.0 / (Self.MapRanges[Self.TSDScaleIndex] * 1000);

Yesterday was spent adding waypoint rendering which mostly consisted of adding the vector symbols to render each type of waypoint symbol. Each symbol requires a mask for blanking the map or video underlay.

AD asked me what some of the symbols meant from the shot I posted yesterday, "AP" was supposed to the "RP" for Release Point (I've changed the "R" character to be more recognisable). See shot below.

The problem I have with this map is that the symbols are hard to see when sat back. Unless you stick the ruddy map in your face it's hard to tell some blobs apart. I tried making them bigger but then they start to overlap when you have tight clusters of waypoints. Then there is the issue of layering. The trick to rendering maps like these is to draw your route first (lines) then symbols. Only connecting lines to waypoints flagged as being 'on current route'. Adding waypoints to a helicopter involves a message to the Helicopter.Navigation object, (Vec3, type, speed_knots, label).

All helos can be loaded with routes for player and AI flights, it allows for players to send their routes to other helos as a message stream if we want to implement that later. The command tent mission terminal will use this same function to upload a mission route to the helo. The ground map is scheduled for April hence the need to get the symbology done).

More 3D Art - Ammo boxes and obs tower

I didn't take these in great lighting conditions, the ground lights are still a novelty so I can't resist playing with them. FARPs now have 30mm ammo boxes, both open and closed in addition the Apache will be getting shell casings ejected  from the cannon today and if I have time, look again at the blurred rotor blades.

I think part of the problem with the blurred rotors is that they are supposed to have transparent parts added through a multiplicative blend (not alpha), but they also have parts of the hub and connectors on the model so I think they just need to be the 'blur' component and nothing else. But also it's an animated 'skinned' mesh so it cones upward with lift.

I think the best way forward is to hide this element on the model (in the LUA code) and show it when rotor RPM is above a certain rate so both the normal rotor and the blended one is visible.

The firing range tower stuck on my mini test site. You can mount the stairs but getting inside is a bit of a trick. I'll see if we can't fix a static ground camera in there.

Checking ballistics visually. Normally you won't see this.

Where am I? Instrumentation.

TSD Update

Added a number of navigation glyphs to the TSD, going to need a bigger test map.

Trying this new FSAA full screen anti-alias shader. Trees look a little posterised, edges look a little softer. Still in two minds about it. Performance seems the same.

Expanded the navigation systems a little. Present Position (PP) toggles your location given in Decimal Degrees using WGS84 ellipsoidal calculation. The map tile provides origin position in lat/lon. I highly recommend this Microsoft white paper if you're interested in mapping data.

http://msdn.microsoft.com/en-us/library/cc749633(v=sql.100).aspx

Basic conversion is (using doubles for precision):

// METERS_PER_NM = 1852.0;
// METERS_PER_DEGREE = 60 * METERS_PER_NM;
// Map Tile origin in lat/lon degrees in
//    Tile.MapLongitude and Tile.MapLatitude
//
// Input: TVec3: pos; entity object position we want in lat/lon
// Output: TVec3:LatLon; in decimal degrees

Tile.MapConvergence = cos(Tile.MapLatitude * DEGREES_TO_RADIANS);

LatLon.x = Tile.MapLongitude + pos.x / METERS_PER_DEGREE / Tile.MapConvergence;
LatLon.y = Tile.MapLatitude + pos.z / METERS_PER_DEGREE;

Seems to work well enough on this scale without having to resort to complex calculations.

More cockpit switches have been given functions, nav lights and stobes. The aircraft spotlight was given it's own 3D mesh finally, so it will pop-out on demand, will make it steerable too. The switch to deploy the spotlight (it's a 4-way hat, extend, retract, left, right) is located mid collective and we don't have the cockpit et-up to allow mouse clicks on these controls. There's no other cockpit switch provided so for now it will be hot-keys/joystick input command only (although /skey spotlight 1 in the console  works too).

Standby instrumentation now working: alt and airspeed needles now indicating (little calibration needed). Texture mapping the artificial horizon ball (attitude indicator) has been driving Dave crazy to get the degree markings all lined up but he got there with only mild insanity, muttering things about 3D Max and inability to do flexible sphere mapping without crashing. Finished the standby magnetic wet compass (wet as it contains fluid, not much different from the ancient Chinese compasses consisting of a needle floating on water). That completes the analog instruments in this helicopter.

The Horizon Ball was one of those silly problems that sucked up more time than it should have. Pitch applied then a local roll. Problems with the objects XFORM (3D MAX modifier) caused some issues until AD got it licked on the second try this morning.

Additional FARP furniture is in progress: 70mm Hydra rocket pallets (pictured below), flags, 30mm ammo boxes and spent shell casings for fall out the bottom of the cannon.

*edit*

Update to Apron lights (and ground based static navigation lighting, such as tower hazard lights). Now we're looking more like a science-fiction film.

Next step

Finishing mapping and route navigation today and tomorrow. Then it's back to the firing range to complete the exploding fx tests.

More things (edit)

Little addition to the TSD. Adding more and more options here to keep track of where you are, what to display. I've probably missed a few things, PFZs for one, shout if you think of any.

Now adding glyphs for BattlePoints, Waypoints, Comm Checks etc.

And I'll move the "ENDR" endurance button label next to wind so I can fit a reciprocal heading display at the bottom. However there isn't room on the main TSD page for it. Not without moving elements around. Dave started work on some more FARP furniture, just in...

*end of update*


Little bit of optimisation. I put several drawing functions used by instruments, such as DrawAircraftOutline() DrawPitchLadder() DrawStores() etc. into OpenGL Display Lists. Someone compared my FLT page video with one found on YouTube and it was pretty close. I've added a few extra bits since which you might be able to see in the shot below.

The Bushmaster cannon got some love in the form of an 800 poly muzzle. I'm being asked, is it worth 800 polys? I don't know, its something that matters up close when LOD0 is active in an external view. Gun cam puts the cannon right into your face so it needs a bit of detail. How much is too much?

You might note the WEP (weapons) page has been completed too. If you're interested in looking at the real thing then see this Boeing video featuring a desktop trainer from a few years ago. http://www.youtube.com/watch?v=IP6onv6W5lc


*update*

I wasn't going to work this weekend but I had a few hours to tinker this evening and added a rudimentary GPS satellite system to the Environment class (that does the time of day / air pressure, sun position etc). There's a star of 25 GPS with variable signal strength that's computed when the host initialises the environment.

Doppler toggles a sensor in the tail that points down (detects ground movement to assist INS confidence, not the radar alt as I wrote at 2am *thanks for the correction), auto-page toggles the ASE pop-up (ala Longbow 2). INU resets don't do anything (we don't want to do manual set-up of these things). Time toggles between local, Zulu and current system (PC) time in the Upfront Display. That's another page crossed off the list.

Other things...the TSD had some tweaks, helo datum, NAV/ATK mode toggle now working. The FLT page pitch ladder had it's scale adjusted to more accurately reflect reference video (YouTube source) and this made room under the heading tape for important indicators.

Cockpit/Sim Data Exchange

This was something I always wanted to add but never got a clear idea as to how to do it. Circumstances forced my hand (in a good way). I added a JSON library to turn some internal game data structures into a format suitable for sharing. Once I sort out the connectionless interface it should be possible to quickly add FSUIPC style query/response exchange. We can make this bi-directional and allow web pages to set "Direct To" waypoints for helos as incoming messages.. I'll let your imaginations run wild with the possibilities of that one.

I have a concert tonight, Bach's Double Violin Concerto which is one of my favourites (http://www.youtube.com/watch?v=hRLyj5iEZag) our first combat video is going to be delayed a few days since I'm not that into working flat-out atm and I've got a busy day Monday.

WEP page revisited

This is old old code. So old the font turned brown. The old WEP page had to be scrapped as it didn't use any of the new vector font or button functions. Here's what it used to look like before...

Old WEP page

New WEP page in progress

Our Helicopter class contains more weapon information, ammo, pylon usage, burst settings in the Stores object member. Stores class data is available across all Apaches on the client so I decided to also use it for special mode information e,g, is the cannon is 'fixed' forward for on-axis engagement, or turreted for off-axis engagement?

Then there are the acquisition modes, someone tried to explain this to me in layman's terms. If I understand this correctly, the helicopter are multiple sensors, different ways to acquire targets and acquisition modes allow one system to tell another about targets. For example, using your helmet (in mouse look mode or using TrackIR) to look in the direction of a threat, then request the FCR radar system or TADS to seek that location on the ground. I might be totally wrong and frankly it's hard to justify putting in details like this which are probably incorrect. It's not an important game-play detail.

We're going to go over the old code, give it a polish, add new values from the Stores class and get our weapon page working again. Looking for a quick implementation so breaking it down...

Buttons

Like the FLT page earlier we start with the button labels around the bezel. The only pages we're really interested in are the ASE which is the magic eye sensor to detect incoming threats. Longbow 2 fans will remember this thing auto-displaying, usually populated with flashing diamonds and a tone when that Mig29 which spawned on flying over 250 ft appeared and popped a missile on your direction. Also it was something you'd glue yourself to when in the presence of 2SUs and SA-10s. Ahhh those were the days of creeping forward and seeing of anything lit you up.

The CODE page will be relating to laser codes. As we're not implementing the Hellfire system at this time we'll just leave this as a place-holder. Also I'll have to make this one up as I can't find any public sources and it's probably just a list of numbers anyway. I think we had a notion to have ground troops lase targets and you'd enter the code for the missile but that was way back before we had to actually program all this stuff.

CHAN is..........Jackie? My favourite martial arts dude. Channels I'm guessing. I recall the Apache 64A used laser channels, HI/LO settings. Such a long time ago. Again something that will act as place-holder. Maybe we can get a picture of Jackie in there.

COORDs are co-ordinates of course. I think this is a list of positions of mission targets, or a list of acquired targets. Again, we'll pass on this as we're just interested in the cannon and rocket system.

UTIL is the same old UTILITY page for turning things on and off. I'm sure we'll be able to throw in some functions to make this useful.


Along the bottom we have weapon selection and manual range input which we had working before. These are:

• GUN 30mm Bushmaster Cannon
• MSL Hellfire missile system (which we're not implementing currently)
• RKT FFAR rocket system, lots of variations here, including flares.

Along the left side of the page we have currently actioned weapon specific controls.

• For cannon, this sets the MAX number of rounds fired when you pull of the trigger, the same system that allowed me to shoot myself on the helipad.
• Rockets selects the zone (we can load 3 different kinds of rockets into each pod)
• MSL will select LOAL and LOBL modes or some trajectory selection (again parked for now)
• AIM we don't have plans for at this time.

Then we have the aircraft glyph in the middle showing stores and count.

After a couple of hours tinkering we have built from scratch....

...the all new WEP page, trimmed and re-shaped. I had to hand tweak all the verts on that aircraft shape. All vector based. Currently only the gun is operational, the fixed/normal turret mode and burst selection are working.


Apron lights

As a follow up to the ground crew lighting issue, AD built some solar lights.

These could really use that material switcher that applies one of two 'glow' textures on texture channel 3 according to the vertex colour.

gl_FragData[3] = texture2D(texture2,texcoord)*fragcolor.x + texture2D(texture3,texcoord)*(1.0-fragcolor.x); 

Ground crew arming at night

In case some of you have suggestions for this, here's a little problem. At night, arming looks like this....

It's not exactly safe, can't see bog all. What I propose is to add some 'crew lights' when the stores are laid out. AD looked at light stands of different types but they are unsafe to use around helicopters. He's putting together a model of some solar lights that crew can position around the work area.

With shadows it sort of looks like this...

And this...

Which looks ok with shadows, powerful light sources with shadows eat FPS, without the extra shadow detail it looks a bit flat like this...

It's better than nothing and we'll try and make it look a little neater. My main concern is probable shadow z-fighting on larger maps.

Thirty mike mike

The 30mm chain cannon is complete with the final additions of the muzzle flash and lighting effects. Each round sends a damage message to any object it encounters along it's trajectory, the applog window is correctly recording  entities when hit.

A couple of screens of the cannon being put to use over my test-zone. It flashes a bit, but looks pretty cool. The TADS follows the pilots view around atm to help pick out objects for shooting. It's quite a handy little mode. Hopefully we'll have a movie at the end of the week to show it in action.

The "Duke" would really benefit from a blurred rotor model option, if only for screen-shots as it loosed something in stills when it's not updating at 60 fps.

The Duke is the nickname given to prototype Apaches by the US Marine Corps, which never got far being navalised. The Marines sticking with the popular AH-1 SuperCobra. 



Blowing the bloody doors off

Shortly we'll have the pyros for destroyed objects, AD showed me some concepts based on the LUA crater object and fire emitter, which will suffice for now.

If you liked the old smokin tank effect from Longbow 2 then this might look familiar...

What's needed is some kind of programmable particle animation system that's available in other engines and y typically come with a bunch of re-usable assets. Alas we'll have to do without till one either comes along or we can roll something simple. I'll see if we can't get the turrets popping off too.

An XML object/damage database will be added later improve the simulation of munitions against different armor types.

Oh, funny story, a slight bug in the ground-crew re-arming system meant I was able to shoot myself with the Apache.  I ran out of ammo and had the grnd override switch on, before landing I triggered a 10 round burst of cannon which was queued up in the Apache waiting to go off when I re-armed it...on foot. Opps.


TEDAC Shader

The TEDAC also got a bit of love today with additional working 'lev' and 'gain' knobs which pass values into Aily's edge enhance shader seen below at max settings. It's just concept atm as I want a certain look to MTADS images which requires careful examination of other implementations I've seen and really liked.

I also linked the pilots video intensity knob to the TEDAC 'level' control which just controls image intensity, it gives you a means to control it from the rear seat if you have underlays active. And we need to do this as our MPDs don't have individual video level controls.

Thirty mike mike = 30mm