Tuesday, 27 July 2010
Art-dev diary update at SimHQ
Dave has been inspired to work a bit more on the more empty areas of the terrain to give them a bit more "pop". See his diary update at our forum hosted by SimHQ.
Monday, 26 July 2010
Showroom pic
I'm still hard at work on flight model code so not much to show or talk about. I'm feeling a bit sleep deprived but we're against the clock.
Dave is refreshed from his little break in the sun and has been rendering shadows for the opfor ground vehicles and CH47. I like these "showroom" pictures. Gives me a hankering to play an RTS game.
Dave is refreshed from his little break in the sun and has been rendering shadows for the opfor ground vehicles and CH47. I like these "showroom" pictures. Gives me a hankering to play an RTS game.
Saturday, 24 July 2010
Astrasim Expo 2010
If you're in the UK on August the 28th and can make it to RAF Cosford for the Astrasim Expo flight simulation show, there's a chance that one of the more haggard and tired members of the Combat-Helo development team (me) will be hanging around Komodo Simulations.
http://www.astrasimexpo.co.uk/
Some of my favourites will be there, Sky Blue Radio, Flightstore (who were always good at sorting out my Saitek woes).
So fingers crossed we get the demo completed in good time and hopefully we can pair it up with Rich's replica Apache cyclic and collective prototypes.
Fingers crossed, all being well, see you there. Did I mention the show admission is free?
http://www.astrasimexpo.co.uk/
Some of my favourites will be there, Sky Blue Radio, Flightstore (who were always good at sorting out my Saitek woes).
So fingers crossed we get the demo completed in good time and hopefully we can pair it up with Rich's replica Apache cyclic and collective prototypes.
Fingers crossed, all being well, see you there. Did I mention the show admission is free?
Flight modelling, a modular approach
I can't talk about the details much as it's proprietary code. Helicopters have been (inaccurately) described as thousands of moving parts flying in lose formation. Mathematically a helicopter is thousands of interactions flying in loose formation. For Combat-Helo and future simulations we're assembling a modular version of what we call FFD (FreeFlight Dynamics), a library based on definitive engineering texts on how helicopters fly through air. Texts such as Bramwell's Helicopter Dynamics and Wayne's Helicopter Theory are the staple of many an engineer.
FFD is the physics part of HTR, a freely available module for Flight Simulator X. HTR stands for Helicopter Total Realism, conceived and developed over a period of two years by Fred Naar and fine tuned by input from real helicopter pilots.
At the core of FFD library is an ingenious and elegant approach that is easy to expand and simplify. Potentially capable of handling different types of power-plant, flight control systems and rotor configurations without straying from the principles of rotor-dynamics. It has a big future as middle-ware, not being tied to any particular 3D engine and totally independent makes it portable, I can compile this on the Mac. Future versions will handle fixed wing dynamics and possibly other vehicle types.
I'm still on the conversion stage but progress on FFD for Combat-Helo is going smoothly.
In other news, just ordered another 1TB of NAS. every backup is close to 0.3Gb. And a Corsair CPU Watercooler is on it's way to protect my CPU from heat-exhaustion.
Did another job search today, bit pathetic that nobody seems interested in hiring, even for fairly trivial IT support work I don't seem able to get a bite. Can't complain though, the weather is good.
FFD is the physics part of HTR, a freely available module for Flight Simulator X. HTR stands for Helicopter Total Realism, conceived and developed over a period of two years by Fred Naar and fine tuned by input from real helicopter pilots.
At the core of FFD library is an ingenious and elegant approach that is easy to expand and simplify. Potentially capable of handling different types of power-plant, flight control systems and rotor configurations without straying from the principles of rotor-dynamics. It has a big future as middle-ware, not being tied to any particular 3D engine and totally independent makes it portable, I can compile this on the Mac. Future versions will handle fixed wing dynamics and possibly other vehicle types.
I'm still on the conversion stage but progress on FFD for Combat-Helo is going smoothly.
In other news, just ordered another 1TB of NAS. every backup is close to 0.3Gb. And a Corsair CPU Watercooler is on it's way to protect my CPU from heat-exhaustion.
Did another job search today, bit pathetic that nobody seems interested in hiring, even for fairly trivial IT support work I don't seem able to get a bite. Can't complain though, the weather is good.
Wednesday, 21 July 2010
Scrappy day
Began preliminaries on the advanced flight model. This involved looking through the various classes and discussing best strategies to minimise future maintenance and ease integration.
Dor setup a flight-sim workstation and was researching the finer points of .GAU programming but was thwarted when her PC detected a Rookit virus infection picked up when working away over the weekend. She shouldn't have plugged into strange networks and let the client install software. Lesson learned the hard way.
Between looking through physics code and C# I also found time to play with a demo of a terrain editor called GROME" which was used for Blazing Angles 2 and was able to import the ubiquitous Longbow 2 terrain. When I get it painted I'll post a screen-shot but the results are promising.
I also was able to do a little more tinkering with shaders (I was all over the place today you can tell, had a not very nice interview in the afternoon which always leaves me feeling antsy). Was able to trim out some useless parts of the MPD shader and add some smooth filtering and desaturation. Details of the Arrowhead/MTADS (Modernised Target Acquisition and Designation) are a bit scarce but the in general offers three-times the optical range and improved low lighting visibility, highlighting obstacles such as wires, trees. Some edge-detection should be fairly easy to add, I've no idea how representative it would be, but since it's all very definitely under the heading of "capability", is therefore going to be secret. You'll have to live with more approximation based on guesswork and YouToob images.
On of the improvements I'm keen on is applying a global X/Z offset to shaders to implement a fast terrain tile system for future releases. If we can cram more ground detail and reduce load times for larger maps by paging in data and translating visuals at the shader level until a big shunt is needed when crossing a terrain page. That should keep floating point errors in check and spread the load. As well as potentially increasing terrain detail.
Some experiments are needed to verify performance but if it works, we'll slice up some DEM terrain with GROME and see what that will do for us. Using meshes for terrain is probably just as efficient, if not more so than the Terrain object we're currently using. I'm not getting hung up onchanging the terrain system for CombatHelo's first release. We have to give you something new to look forward to right? :)
Dor setup a flight-sim workstation and was researching the finer points of .GAU programming but was thwarted when her PC detected a Rookit virus infection picked up when working away over the weekend. She shouldn't have plugged into strange networks and let the client install software. Lesson learned the hard way.
Between looking through physics code and C# I also found time to play with a demo of a terrain editor called GROME" which was used for Blazing Angles 2 and was able to import the ubiquitous Longbow 2 terrain. When I get it painted I'll post a screen-shot but the results are promising.
I also was able to do a little more tinkering with shaders (I was all over the place today you can tell, had a not very nice interview in the afternoon which always leaves me feeling antsy). Was able to trim out some useless parts of the MPD shader and add some smooth filtering and desaturation. Details of the Arrowhead/MTADS (Modernised Target Acquisition and Designation) are a bit scarce but the in general offers three-times the optical range and improved low lighting visibility, highlighting obstacles such as wires, trees. Some edge-detection should be fairly easy to add, I've no idea how representative it would be, but since it's all very definitely under the heading of "capability", is therefore going to be secret. You'll have to live with more approximation based on guesswork and YouToob images.
On of the improvements I'm keen on is applying a global X/Z offset to shaders to implement a fast terrain tile system for future releases. If we can cram more ground detail and reduce load times for larger maps by paging in data and translating visuals at the shader level until a big shunt is needed when crossing a terrain page. That should keep floating point errors in check and spread the load. As well as potentially increasing terrain detail.
Some experiments are needed to verify performance but if it works, we'll slice up some DEM terrain with GROME and see what that will do for us. Using meshes for terrain is probably just as efficient, if not more so than the Terrain object we're currently using. I'm not getting hung up onchanging the terrain system for CombatHelo's first release. We have to give you something new to look forward to right? :)
Tuesday, 20 July 2010
Flare, flare...no look a flare
Congratulations to ArtDave (AD, geddit) for scaring the poo out of me.
He tells me he's been scripting the flare pen (Gyrojet), I'm so busy heads-down in game code I'm often grunting and throwing back idle comments and ideas to get his flare launching LUA code to work.
Then he sends me his completed files. I'm taking a late afternoon break and thought I'd drop his new files into the project to have a look. So I pull over the gyrojet flare pen into the scene editor, I had no idea my speakers were on so loud. I thought a bomb had gone off, the almighty flash and bang/wheeeeeeeeeeee of the flare scared the crap out of me.
This is just too much fun to play with. Animation, sound, lighting. Nicely scripted. Great work Dave, I suppose we're even for farmyard animal noises I put into your cockpit.
He tells me he's been scripting the flare pen (Gyrojet), I'm so busy heads-down in game code I'm often grunting and throwing back idle comments and ideas to get his flare launching LUA code to work.
Then he sends me his completed files. I'm taking a late afternoon break and thought I'd drop his new files into the project to have a look. So I pull over the gyrojet flare pen into the scene editor, I had no idea my speakers were on so loud. I thought a bomb had gone off, the almighty flash and bang/wheeeeeeeeeeee of the flare scared the crap out of me.
This is just too much fun to play with. Animation, sound, lighting. Nicely scripted. Great work Dave, I suppose we're even for farmyard animal noises I put into your cockpit.
Sunday, 18 July 2010
FSX, MPD menus and Perlin Noise
Quite a scrappy day. Installed Microsoft Flight Simulator X and the SDK, there's an interface I want to try and build as a gauge in FSX. I've used the Simconnect API to interface to my own radio panel, now I need to build a gauge to talk to the Simconnect DLL.
I re-worked the avionics menu page using the new vector glyphs, adding some commands to toggle the chat console, about page for version information. The UTIL page sets the FMS channels (Flight Management System or FLCS FLight Control System) in the Helicopter State.
FMS_AXIS_PITCH:Int = 1;
FMS_AXIS_ROLL:Int = 2;
FMS_AXIS_YAW:Int = 4;
FMS_AXIS_COLL:Int = 8;
FMS_AXIS_TRIM:Int = 16;
FMS_AXIS_ALT:Int = 32;
FMS_AXIS_HEADING:Int = 64;
FMS_AXIS_HOVER:Int = 128;
These are bitwise settings as we need to be efficient sending helicopter stability settings over the network, seems sensible to use a single byte to do this. There's a lot of data needed to set up a complete helicopter if you're coming in over a network and jump into one ready to take-off. Console states won't be updated that often but when we do, we don't want a bottleneck.
Time to sit back and examine the feature list, clear up where are priorities are and how far away are we from the major milestones. It's important to get this bird ready for some serious flight testing, there's the terrain LOD system to work out as we don't want ugly popping, Raleigh Scattering for the sky dome, additional fog and integrating FFD (FreeFlight dynamics tm) flight model.
We might strip down the FCR a bit, the TSD we'll keep on a par with Longbow 2. There are lots of things it can do for designating fire zones and splitting them into groups which we just don't need for this version of the game. Even considering dropping the MPD cursors as they won't do much except mark areas on the TSD.
I learned something interesting today, In 1980 Ken Perlin of Perlin Noise fame worked at Magi, the company that worked on Disney's film "TRON". His paper on a function to generate non-random "noise" was publish in 1985 and is often the basis of many shader techniques today. I read this today when looking at how we might introduce more ground detail into surface textures. That's the problem with shader programming, once you start, it's difficult to stop. Good job Dave knows when to stamp on my toes.
I re-worked the avionics menu page using the new vector glyphs, adding some commands to toggle the chat console, about page for version information. The UTIL page sets the FMS channels (Flight Management System or FLCS FLight Control System) in the Helicopter State.
FMS_AXIS_PITCH:Int = 1;
FMS_AXIS_ROLL:Int = 2;
FMS_AXIS_YAW:Int = 4;
FMS_AXIS_COLL:Int = 8;
FMS_AXIS_TRIM:Int = 16;
FMS_AXIS_ALT:Int = 32;
FMS_AXIS_HEADING:Int = 64;
FMS_AXIS_HOVER:Int = 128;
These are bitwise settings as we need to be efficient sending helicopter stability settings over the network, seems sensible to use a single byte to do this. There's a lot of data needed to set up a complete helicopter if you're coming in over a network and jump into one ready to take-off. Console states won't be updated that often but when we do, we don't want a bottleneck.
Time to sit back and examine the feature list, clear up where are priorities are and how far away are we from the major milestones. It's important to get this bird ready for some serious flight testing, there's the terrain LOD system to work out as we don't want ugly popping, Raleigh Scattering for the sky dome, additional fog and integrating FFD (FreeFlight dynamics tm) flight model.
We might strip down the FCR a bit, the TSD we'll keep on a par with Longbow 2. There are lots of things it can do for designating fire zones and splitting them into groups which we just don't need for this version of the game. Even considering dropping the MPD cursors as they won't do much except mark areas on the TSD.
I learned something interesting today, In 1980 Ken Perlin of Perlin Noise fame worked at Magi, the company that worked on Disney's film "TRON". His paper on a function to generate non-random "noise" was publish in 1985 and is often the basis of many shader techniques today. I read this today when looking at how we might introduce more ground detail into surface textures. That's the problem with shader programming, once you start, it's difficult to stop. Good job Dave knows when to stamp on my toes.
Saturday, 17 July 2010
CSEL (Combat Survivor/Evader Locator)
Dave completed more of the survival equipment, looking really good. The concept is simple, if you need to perform an emergency landing and leave your helo, the CSEL can be activated and will mark the location on everyone's tactical situation display. The signal flare may be use to mark your position visually.
More up close pictures in the SimHQ thread here.
I spun off a new shader to do the MPD video mixing. The symbology layer needed to mask the video layer using its alpha channel which was a five min job.
I spun off a new shader to do the MPD video mixing. The symbology layer needed to mask the video layer using its alpha channel which was a five min job.
Ideally I'd like to pass a "brightness" value to the shader but as the material is used for five displays which have their own settings, the symbology level is set by the alpha value.
Here's the completed shader mixing sources and masking.
Here's the completed shader mixing sources and masking.
Video underlay part II
Video underlays are working as intended (more or less).
I split the MPD buffers into two, symbologyBuffer and compositeBuffer. The symbology buffer is texturestage2 and rendered by the shader at full brightness. If the underlay is active the TADS/PNVS buffer is copied to outputbuffer which is texturestage0 (the simple diffuse buffer). The two are mixed by the material shader which is applied to each MPD screen.
The mix works well, providing enough contrast between video and symbology even when the video is quite bright.
I did a version that mixed symbology and the video buffer into a single composite via a shader but the mix was often overbright and hard to read. A good case for adding a working video level control? Maybe in version 1.5.
The final modification is to use the TADS/PNVS postbuffer instead of the raw camera render.
I split the MPD buffers into two, symbologyBuffer and compositeBuffer. The symbology buffer is texturestage2 and rendered by the shader at full brightness. If the underlay is active the TADS/PNVS buffer is copied to outputbuffer which is texturestage0 (the simple diffuse buffer). The two are mixed by the material shader which is applied to each MPD screen.
The mix works well, providing enough contrast between video and symbology even when the video is quite bright.
I did a version that mixed symbology and the video buffer into a single composite via a shader but the mix was often overbright and hard to read. A good case for adding a working video level control? Maybe in version 1.5.
The final modification is to use the TADS/PNVS postbuffer instead of the raw camera render.
Thursday, 15 July 2010
Video underlay
Not quite there yet.
What I'm trying to do is copy the raw TADS buffer into the diffuse COLOR0 buffer and render the symbology into the same bugger but into channel 2 (COLOR2). Texture channel 2 is used by the "fullbright" shader and mixes at full intensity. The net effect being a normal diffuse texture with full-bright symbology painted over it.
At the moment it's not working as intended. I need to go through the shader to check it's doing what I think it's supposed to do. And see if I need to just use multiple buffers and mix them instead of trying to draw directly into different stages. I'm probably missing an OpenGL command to set the texture target correctly.
It's getting late and I've had to do a lot or changes, our cockpit MPDs only have two knobs, the photos and source material I've been using to layout have three knobs. So there's a slight shift in positioning required.
Non of this does anything yet except the "VID" button that toggles the current TADS buffer. This is the new vector font/glyph system in use. I've yet to add the various button "specials" such as menu nagivation arrows, but the toggles work. The FOV shouldn't be in the raw TADS buffer, need to switch that.
The FMS toggles on the left will interface to the flight model.
I have to say the bitmap fonts looked just as good, if not slightly better when used at the same size. It was a pain adding new glyphs though, here I can add anything I can code with GL commands.
TrackIR remains a tangled mess of wires but I managed to assemble it to test and discovered that I'd not added the Track offsets to the cockpit cam. Quickly fixed that.
What I'm trying to do is copy the raw TADS buffer into the diffuse COLOR0 buffer and render the symbology into the same bugger but into channel 2 (COLOR2). Texture channel 2 is used by the "fullbright" shader and mixes at full intensity. The net effect being a normal diffuse texture with full-bright symbology painted over it.
At the moment it's not working as intended. I need to go through the shader to check it's doing what I think it's supposed to do. And see if I need to just use multiple buffers and mix them instead of trying to draw directly into different stages. I'm probably missing an OpenGL command to set the texture target correctly.
It's getting late and I've had to do a lot or changes, our cockpit MPDs only have two knobs, the photos and source material I've been using to layout have three knobs. So there's a slight shift in positioning required.
Non of this does anything yet except the "VID" button that toggles the current TADS buffer. This is the new vector font/glyph system in use. I've yet to add the various button "specials" such as menu nagivation arrows, but the toggles work. The FOV shouldn't be in the raw TADS buffer, need to switch that.
The FMS toggles on the left will interface to the flight model.
I have to say the bitmap fonts looked just as good, if not slightly better when used at the same size. It was a pain adding new glyphs though, here I can add anything I can code with GL commands.
TrackIR remains a tangled mess of wires but I managed to assemble it to test and discovered that I'd not added the Track offsets to the cockpit cam. Quickly fixed that.
Some improvements to the MPDs
Added a simple frame-skip to MPD draw method, they don't need to be updated every single frame and it squeezes out a little extra. Found a "toob" video in which you get a couple of frames of the UTIL page. Anti-ice and FMS options, presumably this is where you can toggle pitch roll and yaw augmentation. Well seems like a good place to add that and we will need to flag some FMCS values for HTR which can auto-trim. Turning that off in the UTIL page will be handy. Looks like "NOE?" at the bottom too. No idea what channel that's supposed to be.
Got some strange problem with my matricies with the new vector glyph render, fixing that this morning. Will update with a screen-shot when fixed.
Noooo, a totally numb-nutz error. My old OpenGL line macro uses integer verts, switching to floats. Oh man, how dumb.
PC froze unexpectedly this morning. It hasn't done that in ages.
Noooo, a totally numb-nutz error. My old OpenGL line macro uses integer verts, switching to floats. Oh man, how dumb.
PC froze unexpectedly this morning. It hasn't done that in ages.
Wednesday, 14 July 2010
I need a new chair
My chair's really bad and falling apart. Went looking online, some nice ones that might be good for my back but I saw this one,from Amazon.co.uk oh boy, to bad it doesn't come with Kevlar plates and a cup-holder.
Guess I'll end up with this one...
This one is quite nice too...bloody expensive though...
Guess I'll end up with this one...
Tuesday, 13 July 2010
Quick update
Monday was one of those email days.
Future Tech
As director I'm looking beyond Combat-Helo, the future of the game and where we want to make improvements. One major improvement I'd like to see is the terrain rendering part of the engine. Make it more flexible, scalable and efficient. We've been looking at different engines and technologies, none of them are suited for flight-simulation out of the box. As much as we'd like to license those for use in a future commercial project they are either not ready or unavailable for license.
To satisfy requirements post Combat-Helo we require the ability to model the whole of the earth and stream in data for ground detail. There's potential to do that with the current engine by paging in ground object data with a curved terrain mesh (think of a skybox that's curved into a sphere, but used for terrain). There are several interpolated LOD methods. The Terrain Augmentation Program is to be an ongoing side-project and not to interfere with Combat-Helo development.
Vector Graphics and Display Lists
I was looking over our Apache MPD (multi-page display) code, there are items I left out simply because I didn't have a handy symbol or character. Also the amount of updating required is a little inefficient. MPD updates were scheduled to be part of an optimisation pass later in the project but since I was adding the FCR and TADS symbology I feel justified in bringing that forward to make it easier.
Currently the MPDs use a co-ordinate system with 0,0 in the centre of the screen, with -1.0 being the left edge, +1.0 the right side. With +1.0 and -1.0 top and bottom respectively. This allows for resolution independent rendering. However some elements such as the Leadwerks bitmap fonts required converting to a standard co-ordinate system. Bitmap fonts don't scale well.
I've just completed coding a complete alpha-numeric font with symbols that mimic closely the current Apache MPD looks. All using vectors and OpenGL Display Lists (which are sort of pre-compiled commands), runs pretty fast and looks not too shabby. The MPD text and symbols are now fully scalable, also being pure OpenGL they are freed from needing the 3D engine and will run on a modest laptop.
Things left to do,convert existing code to use new VectorFont class, use more Display Lists for page elements. I was adding the FCR (back) into the game while I was away last week but it's aged so much it's worth starting over.
Sensors and Equipment
Regardless of the current Apache capabilities which are not in the public-domain, our Apache will track and classify up to 256 objects (thank you AABB for making it so easy). It's currently magic, meaning instant and no regard for signal strength or LOS. This will be sorted out later. Just needed something to display on the TSD, FCR etc.
David has been looking at the crews survival equipment. Something you can whip out to find out where you are. We know we'll want to have at least one weapon (a sidearm) and smoke signal flares for dropping a coloured smoke emitter.
Future Tech
As director I'm looking beyond Combat-Helo, the future of the game and where we want to make improvements. One major improvement I'd like to see is the terrain rendering part of the engine. Make it more flexible, scalable and efficient. We've been looking at different engines and technologies, none of them are suited for flight-simulation out of the box. As much as we'd like to license those for use in a future commercial project they are either not ready or unavailable for license.
To satisfy requirements post Combat-Helo we require the ability to model the whole of the earth and stream in data for ground detail. There's potential to do that with the current engine by paging in ground object data with a curved terrain mesh (think of a skybox that's curved into a sphere, but used for terrain). There are several interpolated LOD methods. The Terrain Augmentation Program is to be an ongoing side-project and not to interfere with Combat-Helo development.
Vector Graphics and Display Lists
I was looking over our Apache MPD (multi-page display) code, there are items I left out simply because I didn't have a handy symbol or character. Also the amount of updating required is a little inefficient. MPD updates were scheduled to be part of an optimisation pass later in the project but since I was adding the FCR and TADS symbology I feel justified in bringing that forward to make it easier.
Currently the MPDs use a co-ordinate system with 0,0 in the centre of the screen, with -1.0 being the left edge, +1.0 the right side. With +1.0 and -1.0 top and bottom respectively. This allows for resolution independent rendering. However some elements such as the Leadwerks bitmap fonts required converting to a standard co-ordinate system. Bitmap fonts don't scale well.
I've just completed coding a complete alpha-numeric font with symbols that mimic closely the current Apache MPD looks. All using vectors and OpenGL Display Lists (which are sort of pre-compiled commands), runs pretty fast and looks not too shabby. The MPD text and symbols are now fully scalable, also being pure OpenGL they are freed from needing the 3D engine and will run on a modest laptop.
Things left to do,convert existing code to use new VectorFont class, use more Display Lists for page elements. I was adding the FCR (back) into the game while I was away last week but it's aged so much it's worth starting over.
Sensors and Equipment
Regardless of the current Apache capabilities which are not in the public-domain, our Apache will track and classify up to 256 objects (thank you AABB for making it so easy). It's currently magic, meaning instant and no regard for signal strength or LOS. This will be sorted out later. Just needed something to display on the TSD, FCR etc.
David has been looking at the crews survival equipment. Something you can whip out to find out where you are. We know we'll want to have at least one weapon (a sidearm) and smoke signal flares for dropping a coloured smoke emitter.
Saturday, 10 July 2010
Combat-Helo to use HTR technology for flight model
I'm happy to announce that Combat-Helo will incorporate Frederic Naar's HTR Helicopter Total Realism technology for advanced helicopter flight dynamics. (link: Hovercontrol forum, HTR section). Developed as an external physics model that interfaces with Microsoft Flight Simulator via Pete Dawson's FSUIPC, HTR is an impressive implementation of blade theory using door-stopper text-books that designers of helicopters use as source material.
Fred invited me over for a few days for a mutual show-and-tell and I got to see first hand how detailed the model is from the author, who better? First with the Bell 206, which had a tendency to side-slip to the right as weight comes off the skids, which left unchecked could potentially result in a fatal roll-over. Then I got a lecture on stabiliser wings and how vertical stabilisers depending on angle of airflow go from "sail area" to a wing generating lift. Blade flap and pitch is calculated per physics update, the amount of detail resulted in me experiencing a full frontal happy-attack.
After the Bell 206, Fred introduced me to an early Apache flight-model. I didn't find flying with a Microsoft Sidewinder easy, also I'm now used to flying with my joypad (I have shame). Stick in hand, trying desperately to keep the nose on a tree while slipping sideways to gauge the tail drag and weight, with limited success. Apache seemed to make all the right movements with changes to collective and airspeed. Even attempting the classic Apache hammerhead turn, HTR delivers sweat inducing concentration required for advanced helicopter flight. HTR also offers stabilisation and a most impressive auto-pilot function, checking boxes required for Combat-Helo's assisted flight mode. Trim seemed to be a non-issue except when the autopilot was flying to a stable-hover when the pilot was fighting excessive trim while attempting to slow down.
Given that HTR has to work within the limitations of Microsoft Flight Simulator, the implementation for Combat-Helo allows us to use even more parameters; feeding information about local terrain conditions for calculating updraughts, downdraughts , a detailed powertrain simulation as well as the ability to monitor rotor-behaviour via the nausea inducing blade-camera.
The flight-model should also be able to handle a load carrying CH-47, applying all the right moments of inertia. Pretty elegant stuff, a masterful use of OOP.
With Fred's addition we have completed the triad of physics, systems and technical art.
Finally I'd like to thank Frederic and family for their hospitality as well as the staff of Corte Dei Tusci hotel who were always friendly and manage to create the most amazing foods daily.
Fred invited me over for a few days for a mutual show-and-tell and I got to see first hand how detailed the model is from the author, who better? First with the Bell 206, which had a tendency to side-slip to the right as weight comes off the skids, which left unchecked could potentially result in a fatal roll-over. Then I got a lecture on stabiliser wings and how vertical stabilisers depending on angle of airflow go from "sail area" to a wing generating lift. Blade flap and pitch is calculated per physics update, the amount of detail resulted in me experiencing a full frontal happy-attack.
After the Bell 206, Fred introduced me to an early Apache flight-model. I didn't find flying with a Microsoft Sidewinder easy, also I'm now used to flying with my joypad (I have shame). Stick in hand, trying desperately to keep the nose on a tree while slipping sideways to gauge the tail drag and weight, with limited success. Apache seemed to make all the right movements with changes to collective and airspeed. Even attempting the classic Apache hammerhead turn, HTR delivers sweat inducing concentration required for advanced helicopter flight. HTR also offers stabilisation and a most impressive auto-pilot function, checking boxes required for Combat-Helo's assisted flight mode. Trim seemed to be a non-issue except when the autopilot was flying to a stable-hover when the pilot was fighting excessive trim while attempting to slow down.
Given that HTR has to work within the limitations of Microsoft Flight Simulator, the implementation for Combat-Helo allows us to use even more parameters; feeding information about local terrain conditions for calculating updraughts, downdraughts , a detailed powertrain simulation as well as the ability to monitor rotor-behaviour via the nausea inducing blade-camera.
The flight-model should also be able to handle a load carrying CH-47, applying all the right moments of inertia. Pretty elegant stuff, a masterful use of OOP.
With Fred's addition we have completed the triad of physics, systems and technical art.
Finally I'd like to thank Frederic and family for their hospitality as well as the staff of Corte Dei Tusci hotel who were always friendly and manage to create the most amazing foods daily.
Monday, 5 July 2010
Light amplificiation
Today I added a postbuffer pixel shader to do light amplification for ETADS. Based on Geeks3D lightamp shader and modified for Leadwerks Engine it actually performs amplification by sampling the source pixel and if it's below a threshold, boosts the pixel intensity. Pretty neat.
These are tests, the left half is the amplified area, right side is ambient light.
The the first greyscale image has the polarity reversed. Into the mix I added a scanline mask with animated noise. The ETADS mask looks pretty good although I'm using a 'scope' mask here which more interesting visually.
The last shot shows more of the noise distortion that makes the image 'buzz'. This is almost ready to drop into the TADS class.
As for thermal imaging, we would need to add heatmaps as secondary UVs or fake it using some heat lookup.This is adding a level of complexity I don't want to pursue at this time as we could spend years throwing in tiny amounts of detail most gamers are not going to need.
This amplification shader allows us to give some threshold and boost control to the gunner so they can apply some measure of skill in finding ground units visually in poor lighting conditions.
*edit*
After some consideration I think some attention to thermal signatures would be good after-all. This could be done by adding an "objectname_intensity.dds" map to texture channel 4 or 5. Then modify the base Leadwerks pixel shader to boost the intensity of the pixel from that channel. It shouldn't be too hard to take an existing diffuse texture map, desaturate and reduce the brightness to almost nothing then airbrush in some intensity levels.
This would work well with the light-amplification post processing shader too.
These are tests, the left half is the amplified area, right side is ambient light.
The the first greyscale image has the polarity reversed. Into the mix I added a scanline mask with animated noise. The ETADS mask looks pretty good although I'm using a 'scope' mask here which more interesting visually.
The last shot shows more of the noise distortion that makes the image 'buzz'. This is almost ready to drop into the TADS class.
As for thermal imaging, we would need to add heatmaps as secondary UVs or fake it using some heat lookup.
This amplification shader allows us to give some threshold and boost control to the gunner so they can apply some measure of skill in finding ground units visually in poor lighting conditions.
*edit*
After some consideration I think some attention to thermal signatures would be good after-all. This could be done by adding an "objectname_intensity.dds" map to texture channel 4 or 5. Then modify the base Leadwerks pixel shader to boost the intensity of the pixel from that channel. It shouldn't be too hard to take an existing diffuse texture map, desaturate and reduce the brightness to almost nothing then airbrush in some intensity levels.
This would work well with the light-amplification post processing shader too.
Saturday, 3 July 2010
Acting!
As I sat down to implement the generic event system I was reading Game Coding Complete which discusses something similar, the Actor class. I was reinventing the wheel...badly. The wheel is overrated as an invention. By far the greatest invention was the second wheel, lets face it, the unicycle isn't the most practical form of transport.
I digress. Actors. If you want to know more about them see Actor model at Wikipeadia
Then I came across this public domain implementation by Otus which also has a remote sockets version. Should work nicely as we need these to fire n-times every t-seconds for displaying alerts.
Also David worked on analogue flight gauges. There's different ways you can implement gauges. Did we want lighting? A glass face? My initial though was to build them like real instruments with different layered discs (hi-res textures with alpha) rather than 3D objects. Looks like we're going 3D for now, the kinds of instruments we have don't need anything complicated.
I digress. Actors. If you want to know more about them see Actor model at Wikipeadia
Then I came across this public domain implementation by Otus which also has a remote sockets version. Should work nicely as we need these to fire n-times every t-seconds for displaying alerts.
Also David worked on analogue flight gauges. There's different ways you can implement gauges. Did we want lighting? A glass face? My initial though was to build them like real instruments with different layered discs (hi-res textures with alpha) rather than 3D objects. Looks like we're going 3D for now, the kinds of instruments we have don't need anything complicated.
Subscribe to:
Posts (Atom)