Jump to content

Can Torque3D be used as a 3D engine for a flight simulator?


Recommended Posts

Development for Flightgear, an open source simulator, similar to X-Plane, but with a GNU license. I was thinking of using the Flightgear Flight Engine (FDM) to build something like this using the Torque3D engine.

In flight simulators the arena is very large, indeed very large ... it is the entire Earth planet 0 mt on the ground up to 1000-10000 km of altitude. The motosports are generated from the altimetric data of some powered Creative Commons licenses, such as Open Street Map. The weather situation is dynamically generated following real-time weather forecasting etc ... Airplanes are quite complex and are described with an XML code for animations of the various parts.

This is an example: fgfs-screen-008_A.jpg

And this is an airplane on fly in this arena:


The problem is that Flightgear has reached a situation that does not allow a further evolution of the 3D rendering engine, so it seems helpful to see if there are alternatives.

I'd like to know if you think we can use Torque3D for this work.

Thanks for your advice!

Our wiki:


Our forum:


My Blog for Italy:


Link to comment
Share on other sites

Sure it can, why not?

The only problem is, you get the problem with floating point imprecissions that happen after at around 10km in any direction, but this is probably an issue with all engines.

This would be the main problem to solve.

Then you would need some kind of terrain pager that extends the gameworld procedurally.

How does flightgear handle this currently? You could just try to make a prototype in Torque and see how it works, should not take that long.

I think someone already started a flight simulator kind of game with Torque3D check out Chris Calefs work: https://github.com/ChrisCalef?tab=repositories if you search his repositories he has multiple projects related to that.

Link to comment
Share on other sites

Well, hey there! I guess my ears were burning, but I randomly popped back in here and saw this!

@abassign: I like where you're heading! As Duion mentioned, I did a fairly significant amount of work in this direction, which has been somewhat on the back burner now for a while but I'd love to compare notes.

The direction I took was A) a terrain pager, using flightgear as a source for terrain data over a socket connection to my running Torque instance. My implementation was far from perfect (among other things it desperately needs to be threaded, so the game engine doesn't pause while new terrain tiles are loading) but it did provide a walkable/flyable T3D copy of the FlightGear terrain, broken into (I think) 2.56 km square tiles.

And then for the aircraft, I used B) the UDP streaming capability of FG to give me position and orientation of the aircraft, which I then hooked up to drive FG aircraft models, imported into Torque through the collada format. For animations, I got far enough to do things like rotate the helicopter blades according to the rotation speed exported from FG, and switching between the rotor models of single blades to the transparent disc-like shapes as speed increased.

I didn't solve the floating point precision problem once and for all, but worked around it for local flights by centering my local map at a local origin and working outward from there. For long distance flights there would have to be a way to shift everything to a new local origin when the player gets too far away from the last one.

Here are a couple of videos documenting some parts of what I got done:

This one is a KA50 helicopter with working textures and rotors, sitting on the ground spinning up the engine:

This is an earlier version, with no rotors or textures, but an example of the flight dynamics:

And here's one with a fixed wing aircraft, the Dragonfly ultralight:

The programmer art is strong in these, but if you've spent much time in FlightGear you might appreciate some of the subtleties like the crisp, clear working shadow of the aircraft on the ground. :-) One of the main motivations for me in doing this was to create an environment where users could fly all (or at least some number of) the FG aircraft in the presence of skinned, convincing human models with actual animations. I'd love to see (or create) a low flying, air vs. ground combat simulation, for example, using FG for the flight dynamics and Torque for the animated characters, particle effects, and everything else.

Anyway, welcome to the forums, and thanks for your shared interest! Best of luck and let me know if I can help!



Link to comment
Share on other sites

I would have to say if anyone is serious about doing a flight sim project with T3D i would highly recommend writing a new terrain system to work with it, the current system is just not going to cut it for that kind of thing. @chriscalef has the right idea above about a threaded system that supports paging. The current terrain system is ok for small/medium size terrains but is very outdated now compared to some of the more advanced and faster algorithms out there. GPU-based geometry clipmaps would be far better suited for the job in this case.

Edit: T3D actually did have a terrain system back before the engine was open-sourced that handled large sizes with paging etc, i'm not really sure why it didn't make it into the MIT version? i suspect a licensing issue, i'm sure @JeffR would know more details about that. Either way that obviously doesn't really help ya though but the engine is capable of it, it does have threading classes etc, it's just a matter of someone taking the time to write such a system.

Link to comment
Share on other sites

The main reason is there were basically no editor tools for it. I know one guy had a tool that generated the atlas terrains, but there wasn't anything like the live terrain editor. You generated the terrain via some sort of third party utility, and loaded it. It was pretty much a 3d model, of a sort. You could do editing of the megatexture it used(as the atlas terrain did use clipmaps) in whatever image editing tool you wanted, but again there was no in-engine toolset to edit them.

So the underlying tech was awesome and efficient, but you couldn't easily work with it, so the workflow of utilizing it was sub-par. So while parts of it(like the clipmap, paging) could definitely be carried up to use in the current or new terrain, atlas itself as a whole package definitely wouldn't be the best. Worth checking on for parts/components though...

Link to comment
Share on other sites

Hey Jeff, is there still a publicly available repo that includes atlas? I can't remember where along the way it dropped off.


As above very sure it was a licensing issue, it never was released with any MIT versions of T3D. If you own a copy of TGEA you would be able to port the atlas terrain code to the latest T3D but you wouldn't be able to make it open source though.

Link to comment
Share on other sites

All I can say on that subject is that I was there at Garage Games while Ben Garney was working on Atlas, and that he did a tremendous amount of work on it, but it still never got rolled into Torque, because of what I gathered were escalating complications and issues without easy fixes.

And given that I consider Ben Garney to be a much better programmer than I am, I would hesitate to dive into it now and try to bring it up to speed. While I never dove in to the subject deep enough to know what the exact issues were, I didn't have the impression that it was just a few little tweaks away from prime time. I could probably get Ben to give us more information about it if people want, but that was my general impression.

For my own work, I'm resigned at least for now to concentrating on alternate methods to create the illusion of infinite terrain, such as dynamic skyboxes, or possibly a giant low res terrain that we can cut out holes from and replace with local terrains.

I'd absolutely love it if we had somebody show up and fix the problem once and for all, though! Just saying get ready, it's not an easy one.

Link to comment
Share on other sites

Thanks for the kind words Chris!

Atlas had an (IMHO) very good runtime - I believe on that side it was stable (and even did some neat for the time stuff like polysoup collision).

But as noted by Chris the workflow was weak to nonexistent. I did some initial work on roundtripping chunk geometry into 3d editors, which unfortunately never got to a production ready state.

I based it largely off of http://tulrich.com/geekstuff/chunklod.html and would suggest that for your scenario this might be a great direction to go. In the olden days we had to really be aggressive about polycount so decimation was very important. Nowadays it's not nearly as important and may be entirely optional if you have a reasonably beefy GPU. However you would want to merge meshes if you have a long view distance to avoid blowing out your draw call budget.

I explored some techniques from http://number-none.com/product/Unified%20Rendering%20LOD,%20Part%201/ for LOD but upon checking the code I don't think I ever got them into production.

Anyway, if you have already textured chunks, I would suggest simply streaming them into Torque and keeping an LRU cache. If you have LOD then that's even better, you can swap to it on the fly. If not you probably need to merge up by directly combining meshes. The 65k vertex limit will probably be annoying in this context. Or maybe your view distance is short enough you don't have to worry about that.

Let me know if I can address anything else to help.

Link to comment
Share on other sites

Hey Ben!

Some good suggestions there. One new technique that I was made aware of recently that sounds interesting too is geometry clipmaps.

I'd also agree with "However you would want to merge meshes if you have a long view distance to avoid blowing out your draw call budget."

It's something that isn't really trumpeted much, but it's still a very, very common LOD technique to take zones/chunks/etc and bake the large object's low LOD into a single mesh, and only render the individual objects when you get closer.

This would be especially prudent in a flight simulator, as you'd likely only get close enough for the stuff you're pretty much right on top of.


This render breakdown for GTA5 touches on that idea a bit(they also bake the terrain as a region chunk so it's a singular draw call for the far away stuff, which keeps it super fast).

The main trick is that doing a workflow like that isn't "automagic". You have to do work to get the low LODs of the meshes you deign important, the chunk of the terrain, merge them together and then make them share a texture so you can cram all that into a singular draw call.

We've done some mulling on if it were possible to automate that to a degree. If you wanted to take a look, the devhead version of T3D has a utility function that takes a selection of sceneobjects and bakes their geometry down into a singular mesh. Getting the LODs and collisions baked is still in-progress.

Our idea was to piggyback off that code. Only for this, you would use the lowest LOD for each given mesh, and during the preprocess step, could do a UV packing step which would let you automatically atlas the mesh's textures into a singular set of texture maps.

If you managed that, then it means that your combined mesh would be low detail geometry, and share the same material so as long as you don't go past the 65k vert limit, you could do an entire region's objects/geometry in a single draw call.

Which obviously would do some pretty nice things for performance.

I'll keep it in my mind as we try and get the LOD/Collisions for the current mesh bake function to work about a way to bake a 'far LOD mesh' for a zone. I've got a few ideas for it, but until I get a chance to actually TRY any of it, it's pretty hypothetical on any kind of automated process.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...