Jump to content
Ultra Engine Community

Flexman

Members
 View Profile  See their activity

  • Posts

    916

  • Joined

  • Last visited

 Content Type 

Blog Entries posted by Flexman

  1. Flexman
    It's ridiculous, I'm seemingly unable to purchase from the UK, PC Pilot, a UK based flight simulation magazine . The only way I'm able to obtain copies is via ebay sellers in the US.
     
    Local stockists are non-existent and repeated attempts to buy them online results in emails informing me that they are unable process my details. The same details which seem perfectly fine for US ebay vendors.
     
    Two weeks now.
     
    I give up, I'll stick with US postal charges. More reliable.
     
    Source
  2. Flexman

    Weekend video

    By Flexman,

    I know I said this week but will likely be over the weekend, there were some LUA issues I needed to get my head around. As for LUA, I think I'm going to pull out some of the model features I've been putting into the model LUA scripts as it's starting to get in the way when I need to control them in game logic. Reading values and objects back seems to be a dark art, these things may have been fixed, or not bugs at all, but caught between moving engine versions and not much documentation I'm left with having to "land at an alternate airport" just to keep things moving.
     
    Also I want to fix up the cockpit ambient lighting before recording a sight-seeing tour around our version of Herat city. Here's a tasty screen-shot of the Citadel to keep you going.
     

     
    Source
  3. Flexman
    Was exactly a year ago today we started work on Combat-Helo. I really don't know where the time has gone. Happy buffday team, and well done. To commemorate the occasion I dug out one of the earliest screen-shots I could find to compare with one from this afternoon.
     
    And thank you to everyone who's offered kind words of support and encouragement. It all helps.
     
    Sept 2010 - "Herat"
     

    Oct 2009 - "Camp Zero"
     

     
    Source
  4. Flexman
    It was over a year ago we were notified that some of the models we had purchased from Dexsoft might possibly have been stolen. After a period of investigation the probability was quite high this was the case and Dexsoft contacted customers to offer new packs. However months later I was unable to get a reply about these replacements and only in November when doing a review of outstanding assets and licensing we had to either press again or do a re-build.


     

    Dave elected to take it upon himself to do a rebuild and not wanting to have to reposition every building adopted the same dimensions with the exception of adding much needed 'basements' (a basement is just an extrusion of the exterior wall so that it will sink under terrain so no gaps are left if the centre of the model is positioned on uneven ground.


     

    Originally the models were made for use in first-person games and LOD0 had details such as railings and girders. Dave completely built (from scratch) versions complete with new textures and made them more efficient at the cost of some detail. An original building had 5213 polygons, after a rebuild only 728 polys (which is iPhone territory).


     



    Original stolen model on left, rebuilt from scratch on right
    Scratch build on left, original on rightAny small indie developer takes a leap of faith when purchasing models from 3rd parties, you don't know where they came from or their history. In this instance we got bitten as did the 3rd party which handled the situation well (but it would have been nice to have the replacements anyway). No harm was done, anyone using or releasing games with 3rd party content be aware.
     
    Thanks Dave for once again being on the ball.
     
     
    Update
    Started work on the updater again.This is based in part on the Leadwerks SDK downloader which is pretty much everything I needed given a little twist and a slice of lemon. Hopefully some of you will be seeing this in the near future. At some point we'll add user names and a regcode system prior to any content downloads (these will not be required to play).
     
    As much as you might want to click on it, you can't yet
    With any luck the 'one click' update system will let us add rolling improvements at the cost of occasionally annoying you with a download when an update is available. I just want to be able to push one button, get the latest changes to any content I own and go.
     
    Support for different builds (content)

     
    Source
  6. Flexman

    Showroom pic

    By Flexman,

    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.
     

     
    Source
  7. Flexman

    Astrasim Expo 2010

    By Flexman,

    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?
     
     
     

     
    Source
  8. Flexman
    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.
     
    Source
  9. Flexman

    Scrappy day

    By Flexman,

    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?
     
    Source
  10. Flexman
    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 **** 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.
     
    Source
  11. Flexman
    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.
     
    Source
  12. Flexman
    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.
     
     
     
    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.
     
     

     
     

     
    Source
  13. Flexman
    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.
     


     
    Source
  14. Flexman

    Video underlay

    By Flexman,

    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.
     
    Source
  15. Flexman
    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.
     
    Source
  16. Flexman

    I need a new chair

    By Flexman,

    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.
     

    This one is quite nice too...bloody expensive though...

     
    Guess I'll end up with this one...

     
    Source
  17. Flexman

    Quick update

    By Flexman,

    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.
     


     
    Source
  18. Flexman
    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.
     
    Source
  19. Flexman
    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.
     
    Source
  20. Flexman

    Acting!

    By Flexman,

    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.
     
    Source
  21. Flexman

    Additional screens

    By Flexman,

    I updated my work-map today with a more recent one and still in the process of fixing up missing objects. I think I have half of a city missing. The cockpit is now in it's own world space resting at the origin and no longer effected by floating point error, but I did leave in some rotation 'noise' to give the cockpit a vibration effect.
     
    I pushed the tree LOD out a bit more which you might see in the following screens. If you have an uber PC you'll be able to render some really sweet scenes. The ETADS has a temporary green tint because I've not yet added the desaturation filter, it's on the to-do list.
     

    Some of the systems such as the helmet mounted display are not operational as it thinks the power is off. I only just found the ground radar mode from September. It's amazing some of the things you forget you added.
     

    One day soon there's going to be ZSUs in those tree-lines.
     

    I'm missing a chunk of city here. There should be rows of stores and back alleyways around the urban compounds. I have the models installed so I don't know what's going on yet, I suspect they are missing from the SBX.
     

    Gets awful lonely out in the plains. Stopped for a photo-op.
     

    With the cockpit rendering modification almost complete it's back to core systems.
     
    Source
  22. Flexman
    HUDs often used in simulators adopt a green hue and use an additive or alpha blend. It can be hard to read them in some conditions and this is something I was thinking about so I tried a few experiments, non of which I like fully.
     
    First: To improving readability of heads up displays by down-sampling the HUD buffer to a smaller buffer (I called the hud_fx_buffer) with a texture filter, a poor-mans blur. Using the resulting 'fuzzy' version to reduce the intensity level of the background image.
     
    Has potential, reduce the resolution of the hud_fx_buffer too much and you get a darkend 'strobe' effect around the symbology which is akin to what you see on video tapes. It think with a Gaussian blur effect and a higher res buffer it might be a winner.
     

    Second experiment, the ubiquitous drop-shadow.
     

    Yuck. Looks like a drop-shadow. It's the same down-sampled hud buffer with a small offset. It works though, can clearly see the symbology against the lighter parts of the horizon without resorting to 'orange' or black.
     
    The hud 'clarity' will remain a user option, off by default.
     
    *update*
     
    One last toy, a twinkly hud glow. This is actually quite pretty in motion and again reminded me of some old HUD tape footage shot in old Jaguar aircraft.
     

    Good for simulating what it's like to have certain eye-conditions. Another one for the cutting-room floor.
     
    Finally, below we have hud glow mk2, a more subtle variation which is just a glow applied, mipmaps help soften out the hud image.
     




     
    Source
  23. Flexman
    Thanks to "GrViper", bit of Russian press coverage courtesy of "Game Navigator". I think I like the intro about raining fire and brimestone? I had to have a Russian friend in Siberia read it out to me over Teamspeak after which he asked, "so you're interested in flight simulation then?"

    Work update
    Last night I added the waypoint/navigation system which is rudimentary but has the needed functions for other bits of code to insert them into an aircrafts avionics. It's a linked list with some methods for management and selection. Once the HMD and MFD gets the steering cues for the current waypoint it should make it easier to navigate around our game theater.
    Also I worked on the flight path vector which is a little confusing since it's 'virtualised' in the helmet sight (adopts real world position regardless of your head rotation), but the artifical horizon is not.
    How *I* currently made it work (which is slightly different from how it will finish) is a magnitude of vertical speed and horizontal displacement (sideslip) which is how I think it works in a 2D format for MPDs (the little square screens in the cockpit). For the HMD virtualised mode it's a matter of using angular velocities (HeloBodyOmega) to estimate where the nose is going to be in 3D space and add the pilots view position and rotation.
    Fred put it more simply, offset from nose = angular velocity * coefficient etc. Well the devil is in the detail working out what the etc. is and doing it in the right order.
    Flight path vector - circled
    Nav symbology will be done today. I'd like to thank Toshiba for the Qosmio X300, the most ugly laptop ever made but certainly a powerful machine.
     
    Source
  24. Flexman
    We're going to edit the LUA script for the CH47. Helicopters are somewhat complex and incredibly noisy machines, you thought your XBOX 360 was loud?
     
    Yesterday we trawled through some online video, ripped the soundtracks and used Audacity to get some loops of the compressor, and rotor beat. That's two discrete sounds that when mixed together should give a good representation of helo noise. Using Audacity it's possible to mark a region, and use that as a 'sample' to remove that noise from another. So we took some of the compressor/engine noise and removed (or reduced) this by around 16db from the rotor noise.
     
    Next task is to add these two looped audio sample sources to the CH47 model script. As we want all instances of the CH47 to use there we'll add them at class level....
     
    local class=CreateClass(...)<br style="font-family: Verdana,sans-serif;" /> class.soundcompressor = LoadSound("abstract::ch47_compressor_loop.ogg")<br style="font-family: Verdana,sans-serif;" /> class.soundrotors = LoadSound("abstract::ch47_rotor_loop.ogg")
     
    The compressor noise can get on your nerves. We want to emphasise the rotor beat so we have set a volume ration of 1:2 between them. Setting the volume of the rotor loop to 1.0 and compressor to 0.5
     
    function class:CreateObject(model) if class.soundcompressor~=nil then <br style="font-family: Verdana,sans-serif;" /> object.source_compressor = object.model:EmitSound(class.soundcompressor,75,1,1)<br style="font-family: Verdana,sans-serif;" /> SetSourceVolume(object.source_compressor,0.5);<br style="font-family: Verdana,sans-serif;" /> end<br style="font-family: Verdana,sans-serif;" /> if class.soundrotors~=nil then<br style="font-family: Verdana,sans-serif;" /> object.source_rotors = object.model:EmitSound(class.soundrotors,250,1,1)<br style="font-family: Verdana,sans-serif;" /> SetSourceVolume(object.source_rotors,1.0);<br style="font-family: Verdana,sans-serif;" /> end
     
    Note, LoadSound() returns a source which we need to store for later when we change volume and pitch. When the Rotor Speed is increased either by the AI pilot or engine/entity update, the blade flap function is called to update the relative positions of each blade. And here is a good place to update the audio for the blade thumping. It seems better to place it here than in the update/render which is called every frame. Here it only is updated on changes to the rotor state.
     
    function object:BladeFlap()
    local flapangle = 7 - (object.rotorspeed*0.6) + (object.bladeangle * 0.08)
    local offset = 120
    for i=0,1 do
    if object.bladehinge~=nil then
    RotateEntity(object.bladehinge[0], Vec3(flapangle,0,0))
    RotateEntity(object.bladehinge[1], Vec3(flapangle,-offset,0))
    RotateEntity(object.bladehinge[2], Vec3(flapangle,offset,0))
    offset = -offset
    end
    end
     
    -- CHANGE AUDIO PITCH
    SetSourcePitch(object.source_rotors,object.rotorspeed * 0.045)
    end
     
    We added additional code to turn on/off audio for static and parked helicopters. We can improve on this by introducing a "start-up" and "shutdown" state that will wind-up/down the compressor noise whenever the aircraft is flagged as "live" or "dormant".
     
     
     
    Such a simple method that greatly adds a sense of weight and presence to an object. Here's a video of the result.
     

     
    Source
  25. Flexman
    Sound is an impressive tool. And something I worried a great deal about from the start. Just adding various audio sources to the Apache, from the Betty, to various computers tones, compressor noise, all adds to a sense of cockpit space.
     
    The Chinook needs similar attention, as a non-hero aircraft (currently a non-flyable). The game engine uses OpenAL, which employs a system of 3D positional audio. In the Apache most of the noise is behind your head, looking left and right appears to pan the audio. Externally the engine and compressor sound sources are attached to a helicopters engine positions.
     
    The difference between the hero-ships such as the Apache and AI units is the way audio is initialised. Apache audio is split between interior and exterior sounds; interior sounds are built during the player boarding process which initialises the cockpit and switch status, the exterior audio is created as soon as it enters the 3D world.
     
    Our CH-47 Chinook like the Apache, will have engine sound sources attached upon the object creation process, and the LUA update function, called every frame will swap in and adjust the volume and pitch of various audio files.
     
    Getting really good audio requires at a number of digital recorders positioned around the aircraft. As we don't have local access to a Chinook and a bank of digital recording equipment, the modern internet age comes to the rescue with numerous video web sites rich with source material of variable quality.
     
    After auditioning a few choice videos, using a Firefox web-browser plugin that downloads the video files from these sites, the process of ripping the audio for processing can begin.
     
    VLC Media Player is a free video player with a number of conversion features. And allows you to batch export audio from a video files using the Convert option.
     
    Selecting the video we want to convert and the destination file then choosing the export format. We want audio only and in OGG format.
     
     
     
     
    I have the Audacity
     
    Don't leave home without it. Audacity is in my price range (free) and works well with OGG format audio files.
     
    It's reasonably easy to find and build audio loops but before you can do that you need to turn it onto a mono audio file. OpenAL's 3D positional audio requires a mono-sound source, it will split the sound to different channels depending on the source and listener position. So having flattened the audio file, the work of finding and snipping loops can begin.
     
    In the next blog update I'll detail the processing of adding and loading the sound files in the model's LUA script.
     
    Source
Copyright © 2024 Ultra Software.
All rights reserved.
×
×
  • Create New...