Flexman

On the topic of fuel systems, someone shared this video recorded at an FOB. One of the more difficult jobs. Source

Thanks for that great link Rick. I thought about something like it, using the vert colour as an offset. I don't know how practical it might be for a helicopter with large textures but there might be something in it (a decal atlas or some such). Thanks again.

Dunno how that happened. I deleted the instance leaving the original intact. However your message still contains a reference to it therefore the forum is now unstable and could crash at any moment.

Currently I have the need to use the same geometry but different skins.

Dull day, so lets post about something most normal people find dull. Fuel flow controls. In the Apache D model this is administered on the FUEL MPD page. Not much to say about it, I'm bored already. It does what it does. Our Apache has two internal ballistically shielded self-sealing fuel tanks. Fuel can be drawn or transferred from one or the other to adjust weight distribution. Activating fuel boost engages the rear tank cross-feed valves as seen here. Fuel transfer between tanks should normally be left to auto unless you feel the need to play with it. HTR flight model should take account of the weight distribution. Marching antsFuel flow takes about 4 seconds to change, while changing, indicated fuel lines are drawn in high intensity white before returning to green. The most important button on this page is bottom right [CHECK]. This brings up the a sub version of the page where you set your bingo fuel status if you get an alert reminder in the UFD. Bingo TimeAward for dullest sim video goes to...."Fuel Crossfeed"..yeah. There it is. It's Friday. Source

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

AD posted more Chinook goodies at SimHQ Link here >>> SimHQ - AD Chinook Update What am I looking at? It's a little creepy, crew heads now reflect the pilot helmet sight (PHS) and gunner helmet sight (GHS) Vec2 offsets, so using trackIR, mouselook etc will operate the appropriate crewman head position (with suitable organic tweening). These positions are stored in the aircraft state so will work across all aircraft (AI and player) as well as multi-player. How creepy is that? "Everyone gets everything he wants." "All I wanted was a mission," "and for my sins they gave me one" Shot on my iPhone. This is what TrackIR and mouse movements do to the crew head positions. *edit* There's a few pages in the system that are informational only, the FUEL page was one, I fleshed it out a bit tonight, adding a working cross-feed system complete with animation (yes the real one does that too). It's lacking the fuel check and bingo settings (to be added later). Setting the bingo stat is part of your start-up checklist, it would be a shame to leave it out. Source

That's quite a cool USP for Leadwerks. Could that be synchronised efficiently over a network?

Now available. *edit* A few additional notes... The controller setup page shown in this video has a number of devices listed. These are just the ones I had plugged in at the time of recording. All DirectInput controllers should be available, some will have ready to fly config files (most Saitek sticks, Logitech). I forgot to turn on the post processing effects since I work without them (generates more heat). There is a LOT of changes going on to various sensors and the IHADSS won't be updated to reflect these changes until I've done the MPDs. So please no accuracy police, I'm aware of the various bits and bobs. It's all in hand. YouTube Link: http://youtu.be/L8AHX8uXHpQ?hd=1 Vimeo Link: http://vimeo.com/29957378 Screenshot of the day Cleanup in lanes 1,2,3,4,5 and 6 please. Padlock, shoot, padlock shoot, HMD mode cleans house at close range , almost too easy Source

Will it possible to 'weight' sectors?

Josh, if it was a simulation of me shopping in a hardware store it would be spot-on.

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

First screen-shot of a quickly put together KBU (keyboard unit). This is a flat 2D image you click on, taken from the texture used in the cockpit. I wanted to see how good/bad it looked since we don't have time to develop a 3D one. Clicking on Air Surv will abort current FCR operation and switch to an active air scan (air surv mode) The keyboard command list is looking horrible if you want full control over this. The shot cut keys work fine however. I made some tweaks to the heading tape symbols and the Air Surveillance Mode has been adjusted according to recent feedback posted. No sweep indicator is displayed (? is that correct) but the radar is still active. And not NTS or targeting is available. This mode is not available if either crew station has FCR as the selected sight. Either crewman selecting FCR or cycling through HMD/TADS/FCR will cancel this mode. I made attempts to smooth out the logic for simple joystick control so you can hot key from mode to mode. FCR Scan and FCR Scan burst will cancel each other out with immediate effect, no waiting for a scan cycle to complete (which is what it did before). I'll adjust the scale of the FOR box shortly. The dot isn't active yet, will fix that shortly and then I'll correct the cue dots in the HMD, That will be as much time as I want to spend on the FCR. I think it's not too shabby and does nearly everything it needs to do for now. Completing the command list for the sensors now means I can finish the default control setup for new installations. For full control on a joystick you need 3 hats minimum. 4 Way Sight Select (HMD, TADS, FCR) 4 Way FCR Mode Select (GTM, ATM, other to come) 4 Way FCR Footprint Set (Zoom, Wide, Medium, Narrow) There are also keys assigned to FCR Mode Cycle Up/Down to keep the control count down on smaller sticks. As always if I've got it wrong then please leave some feedback however I'm unlikely to embark on any more major changes for now. Quite pleased with the detail and how it works. Source

Dome light fixture, fist pass on panel illumination Source

OK that makes sense. This would need to be applied to every exterior material when it rains. Sounds too easy, I bet there's a catch. Besides my shader programming isn't savvy enough to do this in a reasonable amount of time but the principle seems sound.

What's the general approach to achieving the "wet look" with a deferred renderer? Making rain particles is straight forward, I'm interested in objects/terrain. Here's a Unity Plugin video that is sort of the look I'm after... This would be nice too, although I shudder at having to supply yet another texture map for materials to achieve this. This is an image from another rendering system that has a nice puddle/wet effect. I'm thinking one might create in Photoshop a tillable 'render cloud" image that could be used as a specular mask. Any thoughts? I added a specular modifier to the terrain shader which isn't too bad, with particle rain and SFX it's not too shabby but not great either.

Yeah, once you sort out the details of your co-ordinate system (game world <> engineXYZ) you can start to work on the treadmill. @Mike I didn't know that's what you'd done, cool to hear you got it working OK. One caveats using tiled terrain meshes; automatic occlusion/culling. Make tiles too big and you'll loose the benefit of object culling, to small and you have a lot more tiles. Finding a size that works for all altitudes might be tricky. But over the sea it should be fine, you eliminate a lot of issues there. Make something flexible so it's easy to adjust the tile size in case you have to workaround culling/performance issues later. - Rich

Sorry to be a pain, but what is the process of generating the heightmap from the diffuse? Is it a greyscale? 0 to 255? Could you provide the original heightmap you used as a reference? I'm trying to create my own and getting odd results.

What makes good source files for HeightProc.exe? I takes a straight heightmap. What settings did you use for the test scene above?

Merci. It will take me a while to look at this and check it out but I think this might work well for the rocky/gravel boundary around areas of airstrips. Certainly can't wait to try it on the interior of our Chinook helicopter which has lots of quilted padding, that should suit this shader quite well.

Indeed. The flying around tables and chairs is a good analogy for what flying is like in Battlefield 3. In Leadwerks as you move past the 20,000 unit mark those rounding errors start to creep into the shadows causing jitters. That's different from the camera range but if you're not going to have a long distance to the horizon then you keep the precision. OH I must say, I fell in LOVE with EGGplanes, cute versions of F14s and A10s shaped like eggs. That would be a great little game to knock out if you had a small army of artists. Egg Planes - Google Gallery

Aha, that makes perfect sense now. Yes an index of some kind would be of great help.

Problem with adjusting scale universally is that you just end up moving the decimal point but the precision problems remain. Say you reduce it by a factor of 10, your near camera object, say you're on the runway, runway markings which might be 1m away, are now 10cm away in real-world and game units. In Leadwerks there's a slight problem, load up the editor, turn on debug physics mode, add an object to a scene and then scale it. Have a look at what happens. *spoiler* the physics shape doesn't scale - oh my */spoiler* The Virtual Earth book I linked to in my earlier post has some downloadable programs which let you explore this very thing, by adjusting parameters, scale, zbuffer and double/float precision, you can see the results on an actual globe. And it's not always intuitive and often not pretty. I might have had some experience. If you want to buy Empire Interactive's Enemy Engaged Apache Havoc or Comanche vs Hokum, they are available from Good Old Games. There's a little bit of me in those. I also worked at Microprose UK for a while and wrote mission tools for Janes Longbow 2 Apache helicopter simulator. Frednaar is working with me on the physics modelling on the Apache in Combat-Helo using his own blade element theory flight model aka HTR or Helicopter Total Realism which is a free Microsoft FSX add-on that replaces the Microsoft flight model with something much more realistic. It's available in the forums at Hovercontrol.com I got a plug in there for you Fred About exported meshes. If you try and use a 3D modelling program to take a DEM and turn it into a gridded hightmap mesh, it won't work. As you suggest, performance will be TERRIBLE. Detail is a problem. Actually let me re-phrase that. Detail IS THE problem. It's worth assessing just how much you need for your particular game. Irregular triangle meshes are they way to go if you're going with terrain slices, large flat areas can be covered in just a few triangles with mountain tops having more detail. A tool like Grome (I'm really NOT a salesman for them, just citing recent experience) t exports these kinds of meshes. EEAH (Enemy Engage Apache Havoc) used this kind of irregular triangle mesh terrain. Also the terrain slice meshes will have to be loaded "on the fly" as you move around unless your world is small enough to pre-load them. This potentially will cause stuttering or pausing unless it's done on another thread. Then you have the problem of textures on these slices. If your game is fine with 1024 textures covering a terrain tiles you can add noise layers or even throw in some instanced objects to add clutter. If you want to go the way of generating your terrain geometry at run-time then the technique use in FSX is solid. FSX built the terrain vertex buffers over several frames, and it was double buffered so the next terrain was being assembled while using the current one is being used.

He's an evil genius. I hadn't heard of Cone Step Mapping but it sounds cool and looks great.

LE or any other off-the shelf engine isn't suited for a jetsim but not impossible. Grome is an editor, not an engine (although they do license the engine used in the editor). Our use of Grome is about assessing how we can use LE to scale a game up to 100x100km. It's sole purpose is to take large world terrains and slice them up into single meshes, these meshes would be used in place of the built in Terrain object (the LE Terrain object can only have one instance and is not moveable). The down side is that you also have to dump the awesome performance friendly vegetation system. But you shouldn't need it for a jet sim. LE is about as capable as any other engine in this regard. You can look and look and never find anything ready to roll your own sim. A jet game maybe. Lots of games with fighter aircraft cheat like crazy, using perspective and scaling tricks. They give you the impression they are flying at 500 kts but if you measure how much terrain they cover per second you'll realised they are moving slowly compared to a real jet fighter. Video games are all smoke and mirrors. Apache Air Assault had bushes the size of houses. Look at the fighters in Battlefield 3 videos, they are pulling turns at indicated speeds that would take miles in real life. My project doesn't need more than the maximum terrain sizes allow so the only issue has been how to deal with the precision and z-buffer problems that do occur and you have eluded to. Z Buffers are the weakest link, so long as you keep camera near and far distance in a range that's retains precision you solve a lot of z fighting problems. But if you want a visible horizon out to 6 or 8km then your camera near distance needs to be 6m. Which is terrible if you're sat in a vehicle, most of it would vanish. To workaround that you have a couple of tricks, First, you adjust the camera range dynamically, the close to the ground you are the nearer the horizon appears. And the near camera distance can be inches away. Second, your vehicle is not part of the outside world, it's a portalised object. this is what I do in my helicopter game. Let me elaborate on how we do the portalised vehicles, I don't want to put you off, it's not as bad as it sounds, no matter what engine you run with, you need to get your hands dirty. Our vehicle interiors are 3D meshes separate from the exterior. The cockpit interiors are positioned at the origin in their own world; the render cycle first updates the outside world, then we do some frame buffer copying to a cockpit buffer. There's a lot of fiddly code to match up lights, camera and movement (action?). The final composite is an illusion but near perfect. This is how it's done in most simulations. This delivers a rock solid cockpit interior free from precision and z-buffer issues, plus environment objects such as trees, water, rain, particles, can never intrude into the vehicle space. The way we did it was highly technical from the art aspect, you can't see the join, even use TrackIR to lean out of the cockpit when the doors are open. Getting all that to work was specific to the kind of game we were making. But it can be done (and is done) in other engines. If you're studying technologies for the purposes of simulation games you'll have come across Outerra which is the poster-child of how far you can take GPU and procedural content generation. Many of the techniques used are starting to find a foothold in other applications now. For example logarithmic depth buffers are used in Google Earth and it wouldn't surprise me to see a Unity mod for that. Other techniques for rendering long camera distances include multi-frustrum rendering (example: Infinity The Quest for Earth) which I have tried in Leadwerks but the cascaded shadow maps were a disaster, I couldn't get them to match up at all but just because I couldn't get it to work but that doesn't mean it's not possible, my patience just ran out and some swear words were used. So far the best option for large terrains using Leadwerks engine would be the treadmill approach. This is something I'm considering for Leadwerks 3D when it's released. So long as streaming mesh data in is supported, this should be One final word, simulations use two co-ordinate systems (sometimes 3), your real world co-ordinates, and your interior 3D engine co-ordinates. You might find this link interesting, it's a White Paper on Microsoft's Terrain Technology. I would recommend looking through it. Even if you have no intention of developing ellipsoidal worlds many of the techniques I've mentioned are covered. Microsoft Global Terrain Technology