Flexman

Summer Sim 2010 is nearly here. Komodo Simulations, makers of replica helicopter controls for virtual training are sadly not going to have their replica controls ready in time but a recent news update on their web site shows the current collective at the pre-mould stage. Komodo Simulations WAH-64 collective WIP Looking good so far. Combat-Helo will be there to show a build of some kind. Although like the controls we're perhaps not going to have all the goodies ready to go into a demo build. We're still working on getting the new flight model ready, going to be a bit hit and miss that one. Source

Taking a little time-out from debugging to recharge my batteries, something slightly less frustrating, camera views. Not helped by my original program flow which had camera commands in-line where needed, and I still have to go through and fix up TrackIR to work with the new class but shouldn't take long. TrackIR is really simple to implement in this kind of software. Crew positions are parented to a pivot and then offset so it was important to retain any camera/parent relationships, add offsets to source entity location and target entity location (in case the view needs to point-at some object but add some fudge factor, such as trackIR offsets or something). So I untangled the inline camera code and added a new class with SetPostion() Move() SetParent() SetOffset() etc.. and added GameCamera.Update() which does the final camera positioning. Now changing cameras is as simple as updating the GameCamera class you wish to render the viewpoint from. It will be possible to add camera views from an external source with a bit of extra code. These screens are not using the current terrain so still a bit washed out and using the old veg (will update my test build in the next few days, it just takes longer to load which doesn't help testing). Blade tip cam will be added again shortly. And I need a key to toggle the canopy doors (yes they do swing open and closed). And I remembered to increase the TADS camera range to 6km, I'm not using deferred lighting on the TADS buffer, just shader effects for light amplification and edge detection but need some atmospheric fogging to fade into the distance. Scratching my head on best way to implement that one. Source

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

What was that Barry Schwartz video about?..too many choices? Way to derail a simple question. .lib is fine but whatever you like. I'm used to .lib (everything else I link is).

At no point before have I felt so much under pressure as I do now. Hence the lack of blog updates. The new physics engine is still being problematic but these are issues relating to -ff-math and tracking down typos, the odd logic error and other errors that occur when programming. In a flight model, such errors result in numbers quickly blowing up, which they do. So I'm currently tracking down each issue, one at a time until, eventually, it should just all click into place. I finally configured my Combat-Helo input map for my Saitek X52 and apart from my shocking oversight of an inverse axis option it was a nice experience using the old mk1 flight model. It's frustratingly hard to get up to speed and it still flies in a nose down attitude. I may fix those points and retain it as a 'rookie' flight model. All this debugging and testing is taking up all my time, the goal is to have it in place for the show on the 28th. It's looking hit-and-miss atm. We're supposed to be working on some FSX stuff as well but that's had to take a back seat due to holidays and other things. Hopefully will be able to spend some time looking at that in two weeks time. AD did well finding an OK solution to paved roads. They work, efficient but they require a lot of work. To quote... Just to elaborate a bit. The key component is a vertex shader that takes the Z value (height) from the terrain and applies that to the Z value of the road vertices. The road itself is built in 3dsmax as a primitive mesh, a meter high and 20 meters wide. It's flat and the vertex shader sets the height at the end of each section of road. 40960M's of road can be bought at the cost of about 2500 polys which is outstanding in comparison to the native road system which costs tens of thousands of polys for short distances, doesn't work most the time, creates massive slow-downs, and flickers like a 1950's TV in a washing machine. The only real down-side is the amount of work it takes creating the road mesh itself. It took me about an hour to lay down 10KM's, debug the path and smooth-out the ground underneath it. Therefore it probably won't be a suitable method for the dirt roads. I would add that the native road system is fine for small areas, it's perfect for small FPS style levels but non-instanced geometry will always have a huge performance hit if there's a lot of it. Using static meshes for the road system makes it easy for collision testing to flag "onRoad=True" and the model can use this value to adjust sound and emitter properties. For example, running across sand will sound different to running across a road surface. More dust will be kicked up. Those things are more complicated to do using texture splatting or a giant texture overlay to represent these kinds of features. Here are some pics of the roadworks. Source

It looks great. We had a lot of crashes using large maps, know the frustration you felt. It's just memory allocation I think. Try making a 40x40km map THAT's pain If you were group all those walls into a single compound, you'd get much better performance. I think culling all those walls really eats into CPU time unless queries are done on the GPU, even then there was a noticeable performance difference. This is how we tried building compounds at first. Going from a 'LEGO' approach to single models was the difference between night and day. Your approach which grants more fidelity anyway and lots of veg which looks like a pain to place. Procedural veg would be a nice to have.

You can indeed land anywhere and take a walk as I often do, really makes me wish for a procedural grass feature. We built the helicopters so you can run around and jump in and out. The act of boarding a helicopter creates an detailed instance of it on the client. The client loads the avionics and cockpit for that vehicle which is dumped when you exit the vehicle. Player controlled vehicles (just one kind of helicopter is supported atm) retains a 'state' that is persistent between players and sent over the network. There's also a mini-state used to sync the same vehicle between players in the same helicopter. This system enables us to add a detailed CH-47 Chinook later without much extra code other than the avionics code for the cockpit instrumentation. Flight model is data driven. Going for a walk is as simple as finding a nice spot to land and popping the canopy to exit. Could add controls for ground vehicles too but the focus is very much on low level or NOE (nap of the earth) flight. Only the player bases will have detail enough for FPS levels of detail and even that is functional. But more than most combat sim products. All this map data, veg, models, textures has to be loaded in one go. So we have learned to make good use of single materials, optimised everything for the rendering pipeline. Compounds originally we made from discrete walls as sub objects, too much memory, we reduced all objects into one single object where possible, much faster. Didn't loose anything. There will be some civilian traffic following routes along the roads, eventually. It's feature number nine-hundred and ninety nine on the list, well pretty low down. If it can be done without much impact it will stay in the game. Traffic will be fun to do, there's many ways you can go about it. But it needs to sync across clients and any vehicle might be destroyed through player action. That imposes some constraints. I had in mind a simple array of vehicle type and distance, like toy cars on a length of string. And simply winding the string around roads and pulling all the cars along. Array positions can be crafted so they don't intersect oddly when it crosses another at intersection. Open to ideas on this. Has to be as cheap in terms of CPU time.

I think these have been on the SimHQ forums for a couple of days but I've been too busy to post any updates. Here AD has been adding some gardens to the Friday Mosque and adding it to the city. To overcome scale/zbuffer issues of having a large scene, AD has buried the the tiled gardens into the terrain, just like the river sections. The gardens sit on a large slab that is quite deep, this also accommodates uneven terrain. No paved road surface currently. While Leadwerks supports roads that are baked into terrain geometry they are not efficient for our large scale map. One of the reasons we're looking to build our own terrain streaming system after Combat-Helo is released. We might be able to squeeze in another texture layer to splat a paved surface in. A high altitude view of the city shows the west side is still waiting to be populated. This was the area most damaged during a previous regional conflict. Source

Be careful. In Black Holes graphic engines break down below the sub pixel level. It's impossible to render them beyond that point.

No water plane. Water planes don't work well at all with large maps or long draw distances. So we built the river that runs east/west across the whole 40km map from 3D meshes, in sections. And cut into a a "death star" trench in which they are positioned. This eliminates z-fighting. The steep banks don't look natural but it's far less noticeable than z-fighting. A few oasis are being added to give some focal points to otherwise empty areas. Draw distance is currently set at 6km (6000 units) but will be adding a variable view, fog and shadow range based on camera height. As far as FPS goes, it varies greatly depending on in-cockpit or over the city, or green zone. With an nVidia 460 it's around 40-50fps in cockpit which is quire remarkable considering. The fan gets a workout. For helicopter flight my personal taste is for a min of 20fps. 9800GTX manages around 30fps average. Add 20fps when on foot or free-cam mode. The cockpit is quite CPU intensive with the avionics and flight model. Still using 2.31 due to the fps style LOD ranges introduced with 2.32 which are no good to us at all.

While I'm spending hours pouring over interfacing the flight model, AD has been tinkering with billboards again, finding a blend of shadows. There's still more to do, I want a ground fog layer, multiple layers, realistic light scattering and a more dynamic LOD system which we can't do yet. AD is reducing the tree poly counts from 1,500 to 500 on the LOD1s. This should improve shadow performance a little. Looking at shadows again, I came across a GameDev.net post that I might look into. It's similar to the shadow system used in Brano's Outerra whole world engine. I'm not sure what it would do to a high bandwidth environment like a 3 monitor wide system. Probably no worse that using HDR or other post-processing effect. Source

Are you using any kind of framework that handles drawing to the back-buffer? If so, then you can probably locate the part of the code where it clears the back-buffer and insert a call to your own openGL functions. Using SetBuffer() will work for openGL commands, you might need to do a bit of housekeeping, like inserting SetBuffer(outputBufferMadeWithLE) ; glDisable(GL_BLEND); // OR SetBlend(0); glPushMatrix() ; glOrtho(0, 512, 512, 0, 1, 10); // set for a 512x512 buffer glMatrixMode(GL_PROJECTION) ; glLoadIdentity(); CallMySkyCodeHere(); glPopMatrix(); So there shouldn't be much to do. It can get a little upset if you change OpenGL states and don't put them back the way LE is expecting. So you might want to bookend your custom part with the state push/pop commands. Other than that you should be fine to do what you want to do.

Ahhh, hence the nice computing number. Thanks JK, much appreciated.

Clouds are most def on the to-do list after the Rayleigh light scattering skydome. I was chatting to Eternal Crisis about clouds. Skyboxes and maybe particle based clouds are ok if there's no danger of flying close to them. And the air density of the region means getting a helicopter up to that altitude will take a lot of work, it's still possible. My thoughts on clouds was either, a) don't bother, or billboard sprites with the old proximity fog trick. Some good cloud photos on sprites might do the trick, or look really terrible. Will find out in due course.

For iPhone, my general rule of thumb is about 8000 polys total per frame, so budget props accordingly. You don't get much, nor do you need much.

Updates to the green-zones, incremental improvements to the billboards, painting 'shadow' under vegetation. Dev-diary update at SimHQ It's looking great considering how much detail we can't use. Currently we can't use the 2.32 engine due to lack of LOD distance control, and loading the levels with all the vegetation takes three times as long in the new version due to the extra processing required for veg culling. The detail in our production level map shows little performance difference between versions. Upgrading to a new version of the engine is becoming less attractive from a performance viewpoint. Which seems a bit silly but there you go. In the background we have started preliminary design work on an all new rendering system, not for Combat-Helo but for a later project (again simulator related). This will incorporating object streaming and allow for very large terrains. This work isn't interfering with Combat-Helo, there will be no unnecessary delays in production. I'm currently working on aircraft data import, the part that takes a data-file (profile) of an aircraft (helicopter, fixed wing, hot-air balloon etc) and builds an instance of a class that tells it how it flies. Our FFD (Free Flight Dynamics, or Freds Fantastic DLL) class is pretty flexible, a specialist physics engine of it's own. One of the more interesting features are the virtual helicopter controls. Your control inputs are sent to "virtual controls" which then have any necessary trim by AI/AFCS or other input shaping applied. The virtual cyclic can be set to match throw of your actual joystick, you set the ratio of your joystick to that of a full size 70cm cyclic. So if you're using a 20 cm tall stick, setting the joystick length to a value of 20 will correct the input as if you have a 70cm floor standing cyclic. It uses a non-linear function to still give you 100% cyclic throw (shaped after 20% so you can still apply fine control inputs). We'll be discussing the Auto Trim feature at a later date. It's so simple most pilots will never know it's there. Source

Please, is someone in a position to provide the 64 byte structure for storing vegetation? Place one tree, save, 64 bytes, two trees and it's 128 bytes. I could waste an evening REing the bloody thing and get it slightly wrong. Hand placing all these things is a pain in the bum when I can push it through a database and write out a finished .dat file. I'll be happy to provide a tool as a result.

Pretty nice improvements Gandi.

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

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

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

That's what they said about waffles.

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

Have to be careful moving cameras around during a scene when using 3D audio that's parented to it or it's pivot (like for a character). Oddly on some systems it can (not always) produce sound clipping/clicks and other audio artefacts. I've taken to having an "fx" cam that's hidden until needed.

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