More pyro events and secondaries

Expanded the pyro-fx to let me chain events for doing secondary explosions, or ammo cook-off (complete with audio). Turned out pretty good, added some random tints to smoke, fire scale and audio pitch variation to sell a scene of burning carnage. Someone asked for smoke plumes, by golly we've got smoke plumes.

I was quite pleased with the final blast wave effect, a combination of simple expanding geometry and increasing light radius (with intensity as inverse square falloff) sells it. Almost all done in code and one texture file. There's a key that if present swaps out a destroyed model for another mesh to give a bit of control over the look of some objects, such as specials we might want to add later.

As fires die out it secondary smoke plumes are timed to spawn. I'm not using transparent smoke (although it's available), I don't think a 3D card has been built yet that could handle this scene with coloured smoke effects but when they do it would really give it some gravity. We'll keep that feature off-line for now. We'll add some notes to the vehicle database to govern secondary explosions and smoke quantities.

Impact craters from explosions now despawn after their allocated number has been reached.

Fixed some arming issues relating to ground height and AD had an interesting notion to link stores availability to the quantity of ammo crates laying around. It's a nice idea but I'm chewing over practical issues, campaign system should not have to do a stock take and count 3D world entities, it should be one way otherwise madness might ensue. But I like the idea of a visual representation of stores availability and it's no hardship to have an ammo crate flag a stores reduction at a base when it gets freed. So it could be made to work and keep me happy.

Ended the day working on more core simulation code (looking at the powertrain system again and getting numbers to test engine timing / temp functions).

Smoking or non...oh wait.

HDR brown and fine-tuning with video playback

Now I'm able to get more stick time in I've been making lots of little fixes. Something as simple as 8-way coolie hat control for panning around the interior and exterior helps a lot. Could probably manage right mouse and pan control logic for exterior vehicle views.

The normals on the trees really need addressing, I suppose I need to get off my bottom and look at those. It seems to be the LOD2 mesh but as I've mentioned before, I need to try a community shader that adds a bit of variation to them.

I added a bit more detail to the explosion effects. A simple expanding sphere with opacity maps and flame, very subtle, along with initial flash and smoke. This combines with additional fire and smoke effects and more than sells the idea that you're trashing columns of vehicles. The next trick is to add to the game message handler a means to fire effects so scripts or remote clients can trigger them.

Had an OpenGL stack overflow issue today, I was using TWO glPushAttrib() calls to move two colours onto the stack for poping in display list. I don't think this is legal even though it worked but glGetError() was still reported it. So I changed it to not do that. I'd rather add a bit more code and be cautious than break something. It's hard not to resort to tricks like that when you come from an 8-bit assembler background.


Visual Debugging

Using FRAPS to do captures has proved to be a handy tool in the past. It has the benefit of being totally wysiwyg, cheap and simple. You can consistently step backwards and forwards through a recording to examine objects in motion, measuring between frames if you have to. VLC has a handy speed jog dial and frame step feature which I've been using to examine effect sequencing, some elements are timed to last only 60 ms, blink and you miss it.

Alternative method might involve some in-game replay feature which requires something of a client/server topology which this game mostly has but it's a bit too complicated to capture everything in one place. It would take some re-working to fully adapt the code to do that which I don't have time for.

A couple of frame captures on my test zone, here I'm examining a video of blast wave effects for fine-tuning them. Somehow these captures are much darker than the video. Also I shot a night scene to see light propagation from explosions.

The next step is to do a similar test at about 1km from the event. In most games these things happen at close ranges, if the overall effect doesn't sell or have enough visual impact one option is to scale the effect parameters according to the viewers distance. Only visual testing will tell.

Parting shot

Starting to prep for the new Mk2 flight model which means some place-holder functions go in and disentanglement of the old one. So time to put the old bird up on bricks for a bit. Might not be flying for a few days.

AD alerted me to a bug I'd introduced in the joystick code which I was able to promptly fix (index out of bounds, a rookie mistake but dead easy to spot).

Walkthrough of some content creation

Yeah, working with a 200 dollar engine, a box of beer and nothing better to do. We Brits have a tradition dating back to the 80s of creating software with next to no resources. From 1K computers with cassette tapes to health-care systems written in BASIC. Yup, I've done all of the above in the past, but nothing prepared me for the lengths that AD (aka Alpha Delta, or as I like to think of it, Art Department) has to go through just to make a bunch of phone poles to fill some screenery.

As a programmer I think I would have done things in a more programmy way. But sometimes brute force is just as efficient, all that matters is getting the job done.

ADs SimHQ Dev Diary continues with a breakdown of making phone poles.

Glass pits and underlays

Some new screenshots were added to the combat helo website gallery, at the end there, you might want to check them out. Just me playing with some DOF and FOV settings which you can do from a Quake style command console in the game (aka chat interface).

Terrain Underlays

AD has been doing a bit of polish work and discovering the joys of the blend layer in the terrain system.

The terrain system uses 5 layers (with specular and normal for each one) and these are blended by a shader to produce a really fast base layer. Now he's starting to experiment with a secret SIXTH layer (a bit like the ninth chevron in Stargate but doesn't involve blowing up a planet). This blend layer maps a single texture (e.g. from a sat image) onto the painted terrain. It's something tried briefly before but results were mixed and not so obvious at ground level. He's been playing with that to bring out more detail and subtle variation.

Not that you should be flying at these altitudes in game, unless you're a Predator drone (get to da' choppa).

I was looking at SQLlite3 for adding a primitive streaming system for dynamic ground detailing, it's used everywhere as a client side embedded database, even on phones. It has an R*Tree index module for doing fast geospatial queries which is a good method for adding grass/veg/rocks and general junk in selected areas that users need to turn on/off for performance tweaking. It's also free so well within my price range. Don't know if the performance will be acceptable but it's something I will try for the Herat map after we complete the firing range.

Putting the Glass into the Glass Pit

After a material update over the weekend I had the glass in front of my instruments back but there were some subtle graphical issues with view angles and the cockpit night lighting shining off the surface like it was paper.

So after a bit of stepping through the shader code this morning not only did I learn some really cool things directly relating to doing infra-red stuff with the emissive channel but also fixed the computed normal for the glass. The standby instruments also got the glass treatment with a cockpit mesh update. I was actually quite shocked when I saw the difference. Almost makes me want to try and render real-time cubemaps for ultra high performance PCs later.

Now the Easter weekend is over it's back to the vehicle database and enhancing the pyrotechnics.


And now for some WIIIIIIIIIIIIDESCREEEN

To illustrate some tripplehead performance. I did have a very far DOF post filters on and ansiotropic was set to max (16).

the return of rotor blur

With a lot of pixel shaders, especially in the cockpit area, combined with really wide resolutions eat up GPU bandwidth. Tripplehead res typically reduces performance by a half. Just more pixels to crunch. So it IS a real GPU tester but we've not gone through optimising shaders or even art options for maximise performance yet. Since I'm mostly writing this game for me, 30 fps being my comfort zone it's in my interest to keep it close to that region. Although if you're going to be using a small window with MPDs dotted around your desktop of course you'll get much better performance.

How the hell do I turn this bloody rain off? Grrrr.

Screenshot of the day

Captured some nice screens while experimenting with depth of field and field of view. But this was my favourite.

While engaging a compound and dummy SAM site at point blank range, the first round just misses the mark, the other 9 rounds are not far behind.

Bit of an accident...

Currently fixing a video underlay issue but it resulted in an accident that I wanted to post here.

What do you think to having a full screen MPD overlay toggle?

Fire in the hole

Too bad we can't set vegetation on fire in this engine. I added some real lights to fire effects that I'll modulate over time during the update.

So taking it back to the range for a quick trial of the cannon against our target vehicles. Without completed IHADSS symbology for the cannon, the old TLAR system is employed....to not very good effect. After around 3 passes I managed to hit 4 targets.

Trying to engage from a hover.

How did I do? Not very well.

Gunnery is hard, ever harder without cannon stabilisation and HUD symbology. Setting the cannon to fixed forward to boresight targets worked better, understandable considering the lack of auto range adjustment atm.

On the whole, the fire effect system works OK, needs some fine tuning. It's certainly visible from 1,000m and shows where I have some adjustments to make. There's no wind generation atm in the Environment object (which controls temp, time of day, rain etc) but that can be easily added to smoke plumes later as a velocity (trivial).

It's got me starting to think about trigger zones (game mechanics) for this range and basic comms to get some game play element in it. Nothing fancy, just a zone at the observation post when crossed begins a timed run-in and tracks your performance/accuracy until you leave the range area then you get a radio message and pop-up display of targets, hits and score. All in character of course.

Short term things to do over the next few days...

• HUD cannon symbology, auto-range and stabilisation.
• Varation in smoke plume effects
• Enhanced initial explosion effects (they get lost in the 30mm round hit effects).
• Big one, transparencies are not being rendered in the TADS view for some reason.
• A popup MTADS image would help.
• Add score value to vehicle database.
• Effects Update function to modulate ambient fire lighting.

I love lists.

* update *

I couldn't help myself. I need to to stress test in a target rich environment. I improved my home-brew effect factory so it's possible to defer effects and specify fade out times. Also I added the fire lighting modulation (point lights again) which sells a burning mass of vehicles at night.

I also added the steer functions for the Apache spotlight and put a corona over it. The corona billboard is getting culled when it shouldn't be. Probably the same bug effecting the sun corona. One to file.

Observe this!!!

Opps. That's going to cost me. Sadly I used up all my ammo before I got the targets on the range and only managed one BMP.

Happy Easter everyone!

Looking at the Sikorsky X2 "Raider"

Druid posted a link to this presentation on YouTube...

This is a helicopter I've been following on and off. The pusher rotor gives the aircraft an enormous speed advantage (something tried early on in the AH-56 Cheyenne advanced attack helicopter program culminating in the AH-64 Apache).

Eliminating the swashplate through active-blade technologies (where each blade can control flaps many times per revolution) sounds great on paper. Such a system has already been tried on on UH-60s to greatly reduce noise and vibration. Ideal for spec-ops.

I seriously doubt we'll ever add an X2. Certainly the CH-47D is in the works, after that who knows. We short listed helos like the MH-6, AH1 Cobra, I still want the MH-60 as a close friend has many memories of flying that one. It's a LOT of work crafting study sim avionics from bits and pieces of scattered information.

What makes the Apache D so appealing (and I'll quote someone here) is all the gizmos. You don't really get the same buzz with the AH-1. The CH-47 provides a fantastic way to expand the kinds of missions players can fly, beyond that it's hard to nail a mass appeal helicopter (three words that don't belong together....EVER). Everyone has their own likes.

Even the RAH-66 never made much impact. It appeared in a few SEGA games, Razorworks and Novalogic traded on their hi-tech appeal. Stealth helicopters as a fashion came and went.

Perhaps the best known helicopter is the Blackhawk and partly for the wrong reason, crashing. I guess we'll evaluate it when the time comes. But I do love the debates.

Please share your thoughts and opinions on the X2 and other helos either here or on the SimHQ forums.


My Favorite Coffee mug

The simplest things make my happy. Just in...our homage/nod to LB2.

Cheers AD. It gives me a sense of completeness you can't possibly imagine. Oh that sounds a bit psychotic. What I mean is, ever since I felt the dedicated helicopter game needed a revival, I knew it needed to have this as a comforting reminder that the days of mimes are numbered.


Kablewie

Smoke plumes and some fire effects. If you turn on coloured shadows (global illumination) it does some impressive things, smoke shadows across the terrain. Can be pretty heavy on the GPU though.

Lunchtime blues.

Spent my lunch time kicking my heels and decided to try using some of the footage I put together the other week for a quick video. Wanted to show the mouse cursor moving seamlessly around from surface to surface but FRAPs had the cursor setting off. So here's an OTT music video instead :/

Back to exploding vehicle code for me.

Looking back over the blog, it's a year and a half of my life and Dave too, it wouldn't have worked without his dedication. It's funny looking at the old videos, back then I saw in my head what you're seeing now.

I knew what we could do, AD made it a reality. He's knocking out 3D models of Gatorade and probably cursing me for making him use the primitive tools that came with a 200 dollar engine. I think we did alright considering. What we could have done with a 20,000 dollar engine (saved a lot of time for sure) but I'm glad we stuck it out. Learning experience.

And of course we couldn't have achieved the fidelity we have without those who did what they could in offering offering specialist expertease and guidance where appropriate. You guys can see your influence in the game and as a result I know more about this stupid helicopter than I ever wanted to, but still just a fraction of the complexity.

You could spend years adding code to simulate every electronic and mechanical nuance but it wouldn't get you any closer to the experience. It's like measuring, the smaller the units you use the more accuracy you need and so on into infinity.

Soon the focus will be on flight model fidelity (as frankly I hate my current implementation) then it's balls to the wall polishing for a limited beta to get some data on how to make it system friendly for a firing range mini-game release to claw back some of the monthly costs of development.

Thank you all for your continued support and kind words, and to you regular blog commentators who make me laugh during the day when I need it most. And to Pizza Toast, you're always there for me when I'm peckish.

Screen-shot of the morning

Number 1659. Moment of Zen.

Cursors/Zones and offscreen-buffers

I was sent a detailed layout of how an XBOX 360 controller could be mapped closely to the CP/G handgrips for inclusion as default controller layout. What struck me was the predominance of the 'thumbstick' as an important interface component. For a while now "mouse to buffer" problem had been bubbling around my head, it was something I tried months ago but put aside for later. Well yesterday was that later and using a special mouse pick and taking the xyz (well xy anyway) from a valid pick on the virtual display surface, then subtract the local entity position, you get a valid relative co-ordinate you can simply scale to suit your display. It works much easier if you have a display co-ordinate system that has the origin in the middle of the display.

curpos = Vec3(mfdpick.x, mfdpick.y, mfdpick.z).Minus(mfdpick.entity.GetPosition(1)) ;
 mfd.SetCursorPos(curpos.x, curpos.y) ;

In SetCursorPosition() you'll need to multiply x and y by some scale to match world units returned by the pick and object width/height ratio).  Works independent of screen resolution. Our implementation allows you to  easily move the system mouse across and through many virtual displays. Who needs Scaleform?

Below is an example of the FLT page, all pages now sport automatic generation of hot zones (debug in red), the thumbstick/mouse controlled cursor is near the middle (green circle with 4 lines radiating out at 45 degrees). The system mouse is automatically hidden and shown when moving across virtual display surfaces.

This was needed not just for interior helicopter use, but it's also a big part for the mission planning and map interface.

Mission planning or command tent functions can be considered a "hub" activity. When not in your helicopter, this is where players should be spending the most time. So it needs to have a gravity, an environment to match this weight. Meanwhile AD worked on some ground objects to use for virtual display devices. The mission planning system will be run on a laptop. Using code developed for the Apache TSD with some interface elements added, you use these much in the same way you interface with everything else, walk up to it and use the darn thing.

Mission Planning furniture

The Xombat Laptop open

You can even close it but save your work

As a hub, mission planning needs to occupy enough virtual space to allow easy user identification as a place of importance and allow easy navigation with around 4 other players present. So we're looking at a whole walk-around table with laptops and assorted non-interactive furniture.

Mission planning on the laptop taps into the campaign engine and planning involves taking that route data identified by a snappy codename and assigning it to the player editing. The projector serves as a public viewing device, it is a read only interface that can select a single mission profile to view. This allows a single planner in the laptop interface to edit a mission profile while everyone else in the command tent can see and discuss. Missions are assigned to the player operating the terminal or attached to a specific aircraft on the pad. Missions are finally bound to aircraft when a player mounts as the pilot (assume sort of data cart upload on boarding).

Base radio set. Buttons work apparently

I'm finishing off the mouse/events for the TSD and FCR (symbols etc). They mostly just emulate existing MPD bezel button presses but it also needs to select glyphs such as individual Hellfires etc.

So, for that uber CP/G experience, an XBOX 360 joypad is the closest off-the shelf controller you can currently buy.

*update*

Gratuitous images of operating existing MPD functions with cursor controller. Just got the "mouse up" to sort out for drawing PFZs.

AD has been working on some refreshments and reading material...

The flight manual seems a little thin. My A-model binder is about 3 inches wide :)


*edit* Here's an original fresh-install locker from Longbow 2 complete with my favourite mug :)

Apache Helicopter Pilots Kill Mimes!

FCR new look

I hadn't planned to do more work on the FCR radar system. I wanted to try out some ideas for target tracking and adding commands to select scan arcs (Narrow, Wide, Zoom). AD is having problems visually sighting targets on the firing range so we're going to add the same controls to try out a snap FOV change.

Part of the same Helo avionics and ApacheMPD class. I had to make some tweaks to some of the re-usable elements. My prototype code can't be used, too many differences now. This is much much better and faster.

Wide scan 90 degrees

Medium scan 45 degrees

Narrow scan 30 degrees

Zoom scan sector 15 degrees

Your virtual collective should have a HAT assigned to quickly set the scan valume for FCR GND, FCR AIR, TADS and game FOV snap.

Choo choo

Josh Klint kindly gave us permission to use the Leadwerks train model, I think AD is adding a railroad to the US range map as I write this. His last message read "choo choo".

*edit*

Oh yes, as if by magic...

New Combat-Helo site live

A new webzone thing for Combat-Helo is up at www.combat-helo.co.uk

SpaceNavigator beta drivers

I just thought this was pretty neat. New beta drivers from 3Dconnexion have joystick, keyboard and mouse emulation mode.

Setting it up as a walk controller in Combat-Helo was pretty easy. Was able to configure it for the Leadwerks editor without much difficulty.