Announcement

Collapse
No announcement yet.

Linux-Friendly X-Plane 11 Flight Simulator Shipping Later This Year

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    Originally posted by gilboa View Post
    While its true that render engine push polygons around, flight sim engines are forced to handle huge assets (10's if not 100's of GB)
    That's not a lot for modern AAA games, GTA5 is like 60GB and isn't even new, The Witcher 3 is at 50 GB.
    2D stuff is mostly shoveling things around, the load is mostly on storage, caches and busses.
    and spend a lot of resource of LOD v.s. range optimizations, neither of which is required by FPS focused engines.
    afaik, most LOD in games is done by swapping models/textures or adding fog to hide stuff (or squashing detail into textures/bumpmaps you put in the background), not by applying algorithms on-the-fly. Too complex models and weak hardware to do that realtime.
    Most of the models here (scenery, not planes) are veeeery simple from the start as they are meant to be viewed only from "far away" so I don't think there is much LOD involved.

    More-ever, I would imagine that X-Plane devs have their asset management, physics code, flight modelling (aero-dynamics) and render code deeply entangled, making it impossible to simply pull out the renderer and replace it by another engine.
    asset management and render code is probably where the third party engine does better.

    The physics would require them to make a module/plugin for the game engine, as I doubt that the stock physics engine can cut it, apart from Unigine that has a dedicated simulator. I *THINK* it should be possible with Unreal as it does support plugins, but I don't know about others.
    Oh, it seems Unity has a plugin for flight simulators already (should have better physics than default engine, but heh, Unity...). http://unityfs.chris-cheetham.com/

    (Even trying to refactor highly optimized single-threaded code into multiple threads can be nearly impossible)
    That stuff (if it is true) must be eventually rewritten, it's only a matter of time before it starts hurting in a multicore world. Which is why they are working on Vulkan, probably. If they can't multicore properly with Vulkan it's a lost cause.

    Last and not least, I would imagine that if indeed using normal engine for flight sims was so simple we would have seen more companies use them instead of developing their own (like you see in the FPS market), while in reality, a vast majority of flight and space sims use their own engine. (1. Including "real" multi-million USD simulators. 2. Ungine seems to be only engine used in "real" simulators, at least AFAIK).
    Please consider also other human factors like developer experience. Most companies in the serious simulator market are relatively old and made their fortune on their own engine they made back then when everyone had their engine.
    Dropping that and migrating now is nonsense, as they would drop something they have decades of experience with to embrace something they don't know in the slightest.
    Even if the engine was dramatically better, they would still suck at using it for a long while, and the only way to see if it is really better than their own is to try and risk it.

    Comment


    • #42
      Originally posted by starshipeleven View Post
      That's not a lot for modern AAA games, GTA5 is like 60GB and isn't even new, The Witcher 3 is at 50 GB.
      2D stuff is mostly shoveling things around, the load is mostly on storage, caches and busses.
      afaik, most LOD in games is done by swapping models/textures or adding fog to hide stuff (or squashing detail into textures/bumpmaps you put in the background), not by applying algorithms on-the-fly. Too complex models and weak hardware to do that realtime.
      Most of the models here (scenery, not planes) are veeeery simple from the start as they are meant to be viewed only from "far away" so I don't think there is much LOD involved.

      As far as I know, most FPS optimized engines usually load 5-10GB of assets per map (single player maps are usually longer and require mid-game reload, while MP maps are usually far smaller) and as such were never optimized to for multi-hour continuous game play.
      Waiting for 2 minutes (or more) while a game loads a certain MP map, including all assets is acceptable. Having the engine do the same while you're landing is quite different.

      Never the less, as I noted earlier, I'm in no means an expert in the subject so I'll have to take your word for it.

      asset management and render code is probably where the third party engine does better.
      The physics would require them to make a module/plugin for the game engine, as I doubt that the stock physics engine can cut it, apart from Unigine that has a dedicated simulator. I *THINK* it should be possible with Unreal as it does support plugins, but I don't know about others.
      Oh, it seems Unity has a plugin for flight simulators already (should have better physics than default engine, but heh, Unity...). http://unityfs.chris-cheetham.com/
      In short, even if the engine, be that Unity is Unreal has no deal-breaker technical issues with 'hosting' a large scale flight simulator, they'll end up rewriting most of the existing code. Given the relatively small user-base, I doubt that any of the small players is capable of surviving such a rewrite.

      That stuff (if it is true) must be eventually rewritten, it's only a matter of time before it starts hurting in a multicore world. Which is why they are working on Vulkan, probably. If they can't multicore properly with Vulkan it's a lost cause.
      I would imagine that they'll be able to push some tasks out to different threads without rewriting their existing engine. E.g. sound, scenery, etc.
      Same goes for Vulkan port.

      Never the less, I doubt that they'll be able to turn their I-write-inline-in-asm mid-90's engine into 64-core capable beast. It'll require a full rewrite and I doubt that any of them have the required experience.

      Please consider also other human factors like developer experience. Most companies in the serious simulator market are relatively old and made their fortune on their own engine they made back then when everyone had their engine.
      Dropping that and migrating now is nonsense, as they would drop something they have decades of experience with to embrace something they don't know in the slightest.
      Even if the engine was dramatically better, they would still suck at using it for a long while, and the only way to see if it is really better than their own is to try and risk it.
      Fully agree. (See above).
      DEV: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB + 2x3TB, GTX1080, F27/x86_64, Dell UP3216Q 4K.
      SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F27/x86_64, Dell U2711..
      BAK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F27/x86-64.
      LAP: ASUS Strix GL502V, i7-6700HQ, 32GB, 1TB+256GB, 1070M, F27/x86_64.

      Comment


      • #43
        what about flight gear nothing get can beat that

        Comment


        • #44
          Nice debate here .

          I just want to point out a few things which have been missed, or maybe I have mis-understood:

          1. Cry Engine isn't the one for flight sims, best example is Star Citizen as they (CIG) have had to make large changes to it just to get the point where they are now, and I would consider flight sims to be more complex (we have more bondafide tested data for aircraft such as NACA than any futuristic space game, which at the end will make concessions for fun). Simulator fans are the most demanding fans out there, discussions with graphs and data over flight models can rage for months, so if anything is off it will be noticed and pointed out. X-plane is also used commercially and also has to pass FTC certification tests.

          2. UE4 is being used in the upcoming Train Sim World (Windows only unfortunately, from the makers of trainsimulator), from what I have seen the physics seem promising, but we'll see how it is received by the end users, as with flight sims anything off and someone with real world experience will be over it .

          3. Lastly, backwards compatibility. LR make it so the current version is backwards with the last, for example XP10 is compatible with XP9 and XP10 will be compatible with XP11. Of course, it will be a lottery when it comes to 3rd party products.

          There is a bunch of comments here:

          http://developer.x-plane.com/2016/10...o-11/#comments

          Oh and a nice write-up on Vulkan:

          http://developer.x-plane.com/2016/03...to-developers/

          Enjoy

          Comment

          Working...
          X