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

    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
  2. Flexman

    More HUD readability

    By Flexman,

    First of all, a sincere thanks for the feedback. It's not something to get too hung up about and it's easy to get the idea that we spend hours and hours on making HUDs pretty colours without getting anything else done. Yesterday was pretty intensive in terms of tweaks and adjustments to the HUD but not just in terms of colours.
     
    We've added clipping regions (using glScissor() ) so items like the pitch ladder no longer intrude into areas it shouldn't, this declutters and improves overall readability. Also the acceleration cues are no longer available on the CRUISE mode symbology, again reducing clutter.
     
    And the biggest headache which I'll come to in detail has been the flight path vector, that little circle with the stokes at 3, 9 and 12 o'clock. It presented a problem I hadn't anticipated. It's also difficult to explain but I'll try and sum it up.
     
    The idea is that the FPV is drawn in the the direction you're moving, so if you are moving directly forwards it's in front of you. If you are performing a perfect sideways slip to the left, if you turned your head to look along your left shoulder you would see the marker in front of you.
     
    The HMD or HUD represents a 30x40 degree field of view. However, the default field of view for the main 3D view at a resolution of 1024x768 is 90 degrees. The HUDs default scale is 512x512 and would need to map virtual symbols to a 45 degree field of view (512 being half of this example full screen resolution).
     
    Now, if you have a much larger screen resolution, say with a super-wide monitor, or tripplehead (worst case) you're horizontal resolution can be around 3840 pixels across, the game FOV might be 120' and therefore to match the 3D world, the HUD symbology has a field of view as little as 16 degrees. That's tiny.
     
    The result would have the flight path marker moving the HUD really quickly since it covers a smaller relative area. This would suck if you really needed it.
     
    You can't scale the HUD to match the screen resolution as you loose the top and bottom off the screen. Well, answers on a postcard please. Chewing this one over.
     
    Source
  3. 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
  4. Flexman

    Arming almost done

    By Flexman,

    Not convinced this a a great way of arming the Apache. But what we will do I think is provide some quick defaults, option A and option B.
     
    Only the client sees the weapons appear on the ground ready for selection. The crewman loading the weapons clicks the weapon which is then sent to the highlighted pylon. Internally the helicopter entity receives a message to load pylon x with missile y.
     
    To do: Tooltips for the pods to say what they are and I think highlighting the selected pylon might be a good idea.
     


    I can optimise memory usage a little by pre-loading the Apache stores and instancing then missiles which I meant to do earlier. Pre-caching some of these objects will reduce that awful machine lag that occurs when it needs to show a model for the first time.





    TrippleHead2Go vision


     
    Source
  5. Flexman
    Yes were still using Notepad to edit them. Well that's not quite accurate, I'm using Notepad++
     
    What's nice about Leadwerks is being able to create a shader to add new effects or change how the engine renders something without anything getting in your way. So when Dave asks for a version of the cubemap that will blend in some particular way it was no problem to quickly put it together. He's doing terrible things to make filthy looking windshields, chrome toggle switches and this rather neat looking rear view mirror.
     
    Who needs fancy wysiwyg editors....well it would be nice sometimes.
     
    Dirty Mirror finish
    It's a double rainbow! Testing blending and reflections.

     
    Source
  7. Flexman
    I was looking at the problem of glass again, reflections for cockpit instruments and improving the canopy and TADS optics. FSX manages to do so much with so little (a small 128x128 DDS) for shiny metal parts, such as chrome props it was time to look at adding cube mapping again.
     
    I know this has been added to Leadwerks 2.40 but the corona problem doesn't seem to be fixed yet. Retro-fitting cube-maps to 2.31 is an easy task and the river mesh material was updated (we don't use the single height infinite plane as it doesn't work with real-world topography). As water goes it's not fancy, real-time reflection and surface animation for high-speed machines during the polish end-phase. River surface cube-mapping matches the environment lighting and thus provides a simple and economic effect. There's only one river that runs east-west.
     


    Shiny chrome parts and subtle glass reflections should be trivial to add (when I get the alpha component sorted out).
     
    Source
  8. Flexman

    Rockets and Rails

    By Flexman,

    This entry is not about the life of pioneer George Stephenson. The pylons seem capable of configuring themselves, got some elevation in there for aim assist if/when we add that.
     
    I removed the LUA based weapon loading, it wasn't working out the way I hoped it might. There's a level of disconnect between LUA and the game-engine which added to the complexity of something that is already complex, when it didn't need to be.
     
    Can finally get started on the arming now. Got a little sidetracked with testing what I call compound entities which seemed like a good idea but don't actually work outside of the editor due to some engine bug. It would have been a great way to make villages but we've adopted a different approach. Both would give us destructible buildings.
     
    * update * Stores jettison is working too well. The whole things comes off the rail...and drops through the floor. All corrected. Rail and pod weights are effecting the centre of gravity a little too well, that's going to require a bit of tweaking to correct. I need to check my notes on stores weights and extrapolate how heavy these pods and rails are when empty. Then I had to create a custom physical shape to fit flush with the Hellfire rails as the connectors and actuator were causing collision events to trigger. And it turned out that my function to set those collisions was never called, it was removed after the 2.31 engine update. Restoring the function worked a treat. Now I need to add to the SFX required list, store jettison and stores hitting ground.
     
    Overall it's been a frustrating evening but a result at the end. Lots of fixing up to do to complete the arming, might take until the end of the weekend before it's fully functional. End of April is pencilled in as the blowing things up milestone, the campaign map is well under construction and I think we're almost at the point where the campaign data that sits on the map can start going in.
     



    It's bloody hard work, often tedious but the results make it almost worthwhile. Tomorrow however I have to face a reality I've not been looking forward to. And it might scupper everything.
     
    Source
  9. 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
  10. Flexman
    Making notes on discussions of blade flapping.
     
    Definite gravy but easy to add. Currently blade flexing is done via blended animation controlled by the simulation sending key values to the model. The CH-47 has quite a large blade system (almost doubling the length of the helicopter to 100 feet) and low ground clearance.
     
    Most of the droop comes from the flapping hinge Dave has indicated in white (adjoining the red highlights). These pivots allow the blade to horizontally move upward when the blade is advancing, and down when retreating.
     
    Additionally the blade model hierarchy to allow for visible blade pitching and the Apache blades retro-fitted to do the same.
     

     
    Source
  11. Flexman

    Two years old

    By Flexman,

    Yippe..the 18 month project is now 24 months old. Horray. Short post but I felt I couldn't let it slip by unnoticed. Especially with all the Tipex (White-Out) all over my Project Planner.

     
    Source
  12. 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
  13. 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
  15. 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
    All actions relating to the AH64D go though a message receiver. Player mount, dismount, ground crew arming, lights, AI commanding and (getting to the point) virtual cockpit interactions.
     
    The MPD button naming convention of "MPD_1_17" refering to MPD 1 (pilot left) and key 17 (counting from top left) that gets sent to the input handler for that MPD.
     
    Key messages can originate from the client or network. I had to add a source ID to account for situations where one person in the same vehicle has authority over some function.
     
    The keys and knobs are all working well, interacting with the avionics. I've removed some of the more obscure items and checking authenticity of some elements. Had to simplify a few things just because it's not intuitive. CTRL-G (default mapping) will switch to guns. ALT-G cycles gun round burst mode between 10, 20, 50, 100 and full. Burst is the number of chain gun rounds fired with each trigger pull.
     
    MODE is the method of gun tracking. It cycles between
     

    HMD (helmet mounted display, this is TrackIR or mouselook, where you are looking) FXD is fixed forward TADS is the current TADS position.
    This is a fairly important mode distinction, particually in co-op play as the pilot controls gun/rockets and the the co-pilot/gunner operates TADS and other weapons such as the AGMs (air to ground missiles).
     
    This I think neatly simplifies operation and easy to understand. For most situations you will want to leave it in TADS mode so you can quickly deploy cannon or AGMs against ground targets.
     
    MAN RNG adjusts the ballistics trajectory. Cycles between fixed ranges given in meters. It's there for completeness without adding complexity. It's a candidate for removal.
     
    AGM sub mode coming next unless something really cool happens
     
    Source
  18. Flexman
    AD's SimHQ Dev Diary - Road works
     
    Interesting post on improving the look of the new roads which are meshes exported from 3DMAX using a number of different post processing techniques to level them to our height-map. He touches upon adjusting the height-map to sink roads into the terrain, thus ageing them.
     

    Note that the heightmap images in this post are flipped vertically. If you plan to use them as a map at a later date and get confused then this is why.
     
    Source
  20. Flexman
    Never felt the need to keep fish until now. It's a crashed helicopter for use in your pond or aquarium. Thanks Phil (and Rob for sending it on).
     

    This wonder compares to the bizarre "Titantic with inflatable iceberge" bath toy I once found in an English Heritage gift shop.
     
    Source
  21. Flexman
    It's a sentence I pulled out of context from the recent Unity newsletter. It relates to a Mobile Generation Education Project, a project with a $250k giveaway to help students become the mobile innovators of tomorrow.
     
    Now, when I was a student, we didn't have mobile phones, or the world wide web. And if we did, we'd have moved onto something else by now. Teachers point out that 60% of the jobs their students end up doing haven't been invented yet. I helped develop Risk Assessment software used by Walmart among others, five years later it's old technology. Everything moves so fast in this information age and it's accelerating.
     
    I wonder how much of this social web technology that is perceived to have permanence will be around in ten years or even five. I'm starting to see an effect that could be best described as Dawinism applied to digital data, a process of selection that results in the useful data being retained (at least higher up the search tree) and copied. And this process snowballing with an ever increasing amount of new data.
     
    With amazing concepts of collective information gathering such as Seadragon and Photosynth on the horizon, any guesses as to what the future holds in information mining are just that. If you don't know what Photosynth is then check the link and prepare to have your mind blown by possibilities of this and other forms of data.
     
    It doesn't take academics to come up with these kinds of ways of looking at data, it takes a creative (and ever so clever) mind. Picasso said everyone is born an artist until it's taught out of them.
     
    Right, that killed 10 minutes. I wonder if anyone will be referencing this blog entry when I'm gone from this world. I expect the URLs will have long since died
     
    Source
  22. 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
  23. Flexman
    On the whole, I'm starting to warm to using text for user options, the nineties style. Dave showed me some icon screenshots from ArmA and remembered why I didn't like them. Is that a steering wheel? Desk fan?
     
    Below is an in-game shot showing the menu and data displays for helicopters. Not unlike something you might have seen in older games using pre-rendered art. All interactive objects around the base will have these. If you don't want the floaty status text, CTRL L (for labels) is your friend.
     
    Eventually each helo flight will pull it's call-signs from a datafile (Twodogs, Ugly, Badman, Goody etc.) which will go in placed to the current auto-generated ID. Status refers to the ground crews work time to prepare the helo for it's next sortie. Fuelling and weaponeering.
     
    The play process is typically pick-mission, go to aircraft, pick weapons if default not to liking, hit the fly button. It's been the same in games from Wing Commander to Black Shark. Pretty much universal. And we don't want to break that. Reading how UK operations conduct Apache helicopter turnaround, the Apache lands, is guided into an arming bay and re-armed immediately so it's ready for the next flight whenever that may be. No hanging around waiting for a bird to be armed if you're urgently needed in a support action.
     
    To facilitate this into the traditional game flow, brief>arm>fly, the ground crew servicing timer starts after landing and shutdown. But as the player may change weapons seconds before flight and we don't want to delay, we'll let the players arming choice count as the arming done after landing. With a realism option in to have "Real-time arming" for sim pilots who love to thrash themselves with birch-twigs - metaphorically speaking.
     



     
    Source
  24. Flexman
    All the things we want to show but can't. Still making some final hour changes to get a robust demo working that can be operated by Joe Public (I'm told he's coming along). A simple flying demo that will show the technology, Afghan map, lighting and cockpit. It has the mark 1 flight model I keep tweaking. sounds could be better. I wish I had time to do the landing gear joints, it's hard to land without wheels.
     
    Better stop with the bloggin and get back to writing.
     
     

     
    Source
  25. Flexman
    After close checking of memory usage when boarding and exiting the Apache there's feedback saying that objects are getting freed and memory dumped, except it isn't. Only a small percentage. There are object references that are keeping the cockpit and avionic entities alive and preventing them from being released.
     
    Going to take a little time to track each one down.
     
    *edit*
     
    The large memory leak located, was the TADS camera world not being released. It's been removed for now.
     
    Source
Copyright © 2024 Ultra Software.
All rights reserved.
×
×
  • Create New...