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

[Amarildo]

For a game engine the only thing that matters is total polycount of the rendered scene and effects (shadows, and stuff).

How "big" or "distant" or whatever is irrelevant, they are different starting numbers plugged in the same calculations.

So yeah, the bling bling "short distance" engines might very well be better than the engine here even if they are only tasked to make similar scenes due to obvious reasons.

I would love to see that happening. If they retained the blade physics while:

- Being able to display overcast clouds;
- Being able to display huge amounts of trees, buildings, roads, cars, etc;
- Being able to simulate complex systems;

And all while having a decent frame rate? I would definitely donate to the project. I just don't think it's possible.

[M@yeulC]

I apologize for the long post, I must have gone out of my mind (and I had already typed this when I went back to it).

I don't mean to be disrespectful, but where are you getting this from? At this point, I'd expect you either:

1) Have an internal source from Laminar that says it's viable;
2) Is making assumptions

Ok, sorry about that, I should have made it clearer: I have no affiliation with Laminar Research whatsoever, and everything I write here is based on my personal experience with game engines and programming in general. Let me clarify a bit:
Modern game engines such as Unreal Engine and CryEngine are very modular, and come with the source. This is also true for their current engine (or at least I very hope so). There is more to an engine than the graphics part, of course. This includes, but is not limited to:
- Assets loading
- Networking
- Rendering
- User interface
- Input
- Scripting
- Physics Engine

This is a very rough, uneven breakdown, and you are free to criticize it in any way you want. But these modules are present. We'll probably want to keep our Physics engine, Input, Scripting and Assets loading (debatable for the last two, but if you want to retain ascendant compatibility with the third party content -- and even the first party one -- that is the way to go). The first two will probably be a lot superior to the other engine's offering. We're left with the UI, Network and Renderer. I can't really speak for network, as I don't really know how it's done on modern engines. But you'll probably want to keep your already-optimized network code.
UI: Well, they redesign it anyway, and a ton of games are using some kind of middleware for this, so either way, I think they could choose whatever solution they are more comfortable with.

Now, on the last component, which is the renderer, and which was the reason for the first comment asking for porting to a new engine. Yes, this is quite hard to get right, especially if you start thinking about this explicit multiadapter support in Vulkan/DX12. But the goal here is only to take some polygons (+normals if you want to nitpick), textures, shaders and render them together on screen. Have a renderer or another here wouldn't be a big deal, I suppose (this depends heavily on the two engines). You probably have something like

AddObjectToRenderingPipeline( T_Object &)

That you could get running on the new engine. It might be a bit difficult to port the threading model, the shader format (I am thinking about UE4, even if I don't know that much), and the assets loading (while still adapting the LOD, as you would have to choose between the engine's implementation and yours).

Overall, you could technically do it, but (and that was the whole point of my previous post) you wouldn't have many obvious benefits at first: if you use your old implementation, you don't get the benefits of the new one, even though it might be faster to port it over that way. Take for example the assets: by keeping the old ones, you don't get to use all those nice "shader nodes" that the new engine could offer.

I was trying to stay neutral and consider both points of view, as it seems to me that there are pros and cons to both approaches, and we might as well trust laminar research to have thought about this already. And I don't really think someone is better fit to assess wether it's worth it or not than them.

There is a last point, which I didn't really mention, when it comes to next gen graphics API: the more the renderer knows about what's going on in the application, the better. This allows to prepare drawing queues in advance, to save the relevant ones, and to batch submit the right thing at the right time. And this is probably much easier if you have your own graphics engine. "Ready-made" engines can go around that if:
a) The user doesn't change the engine in a very meaningful way around these features, which is probably the most frequent; or:
b) The user changes it in order to better fit it to his needs, which is almost a complete rewrite.
Choosing a game engine is not an easy task, and you often have some clearly defined reasons to do so. If you want to avoid spending time on the graphics part, that might be one.

Do you have any numbers of the costs, "Man-Hours", and so on?

Well, I was more thinking of engine licensing costs, those aren't so difficult to find. Of course, migrating to a new engine would probably also require a fair amount of work too, but I wouldn't risk any figures there. Plus, it would require some in-depth knowledge about the current and next engine to be able to make any useful estimate.

I've had X-Plane 10 on Steam for more than 2 years without issue, and I've tested almost every commercial aircraft available for Linux. No problems at all.
Right now I only fly the FlightFactor 757 and the DreamFoil AS350 B3+. Sure, it requires activation, but that's totally fine, as fine as on Windows. In fact, I can do "dd if=/dev/zero of=/dev/sda bs=4M" on my drive, copy the saved MBR from the previous install (from where I activated the aircrat), copy the activated aircraft folder, and use it again without having to activate. X-Plane's DRM is, to me, one of the best out there.
And I also never heard of this "having to open things twice". Do you have any reference links so I can take a look at it?

Ha, I didn't know this was so easy to bypass. You could even activate it on a GPT-enabled drive with a protective MBR, to have more freedom.
After a quick google search:

http://forum.aerosoft.com/index.php?/topic/90603-steam-version-and-multiple-instances/

https://steamcommunity.com/app/29218...0477993565163/ (granted, the same guy)
I think i've heard of other restrictions, but I can't recall them right now. If you have basic needs (no need for the fancy xplane stuff), the steam version should be good enough.

Basically, this feature allows you to use different views for the different instances. You can for example use a monitor for your instruments, another for the cockpit view, etc. It probably available on other PC via LAN too (think about supervised training). I wish it was available on smartphones/tablets, though.

Correct, but it's not a game ;-) It's a simulator.

Meh :/

XP 10 uses ~61 GB's worth of default scenery.

To me, their roads are mostly terrible. I can't recognize any city I visit, no matter where it is. And my own city? It's not even there hehehehehe. However, most highways, train lines, and so on, are very accurate.

Thanks for the information.

_____________________
I might have made some mistakes in this post; moreover I am a bit tired (00+), and I usually hate these kind of quote-and-answer posts. So, I won't bite anyone for not reading it.
The first part of the post was written last, so it might be hard to understand the connection between the two.

[starshipeleven]

I just don't think it's possible.

If you look at the models (unpacking game files), all "forest" tiles for example (tile composed of many objects of the same type, be it trees, boats, houses, whatever) are made, you can see that each single object is usually 1-4-poly.
The ground is also similarly low-poly, where each ground tile is a handfew polygons.

Most game engines from when I was still a modder (2008) could run at decent framerates with like a hundred of 10k poly objects on the scene (some were choking at 50 such objects as they were running on a single CPU core because the engine was shit, like for example Egosoft's X3R or X3TC).

Some modern game engines render 11 million polygons each scene/frame on a ps4 game. http://polycount.com/discussion/1410...n-games-thread

Sure there is more than just polygons in a rendering load so that's still aggressive eyeballing, but I wouldn't be so skeptic about using a third party game engine.

The biggest reason most companies don't switch afaik is that the engine is basically the game, if you change engine you are throwing away all the experience you have with the current one as you are starting from scratch with the new one, and thread into big unknowns. It's a huge amount of risk that many companies don't want to take.

In this case, the main beef of the game isn't graphics and there isn't much competition anyway, so this jump in the dark is not really justified.

For those starting from scratch already it's a no-brainer instead. Nowadays none makes their own shitty engine that will require 5 years of development (and of experience for the game developers) to stop sucking when they can take third party ones that rock already.

[Amarildo]

Thanks for the informative post, @M@yeulC.

[Amarildo]

I'm watching the X-Plane 11 presentation and I'm blown by what these guys have done https://www.youtube.com/watch?v=AaGDkVhZPfU

Check here for a few pictures of XP11: https://www.facebook.com/33920252628...53832152131283

I have to say, I'm already saving money for it. This next release will be fantastic!

These next two photos show how much more realistic the visuals are:

https://www.facebook.com/XPlaneOfficial/photos/a.10153832152131283.1073741827.339202526282/10153832152781283/?type=3&theater

https://www.facebook.com/XPlaneOfficial/photos/a.10153832152131283.1073741827.339202526282/10153832152406283/?type=3&theater

[log0]

For a game engine the only thing that matters is total polycount of the rendered scene and effects (shadows, and stuff).

How "big" or "distant" or whatever is irrelevant, they are different starting numbers plugged in the same calculations.

So yeah, the bling bling "short distance" engines might very well be better than the engine here even if they are only tasked to make similar scenes due to obvious reasons.

This is not correct. The calculations are done with limited precision. A classic issue you will run into is z-fighting. This is where you might have to get creative in your approach of rendering near and far objects (scaling down far objects and moving them closer to camera, reversed floating pioint z-buffer, logarithmic z-buffer etc).

[gilboa]

Rope they can build a modern engine that can really take advantage from a modern multi CPU processor. All major commercial flight simulators are using old engines, from Windows XP times, that cannot fully tax a modern quad or octa core CPU. Is pathetic when you read the lame excuses from developers that are asking a lot of money for a old piece of software.

Too bad nobody is using Unreal or Cry Engine as a base for a modern flight simulator.

While Unigine might have an engine that can be used to "realistic" flight simulator neither CryEngine nor Unreal were designed to render huge landscapes, let alone the complex and realistic flight model that is X-Plane's pride and joy.

As for "lame" when you develop a realistic flight simulator you'll get to call other people's work "pathetic".

- Gilboa

[M@GOid]

While Unigine might have an engine that can be used to "realistic" flight simulator neither CryEngine nor Unreal were designed to render huge landscapes, let alone the complex and realistic flight model that is X-Plane's pride and joy.

As for "lame" when you develop a realistic flight simulator you'll get to call other people's work "pathetic".

- Gilboa

For the huge landscapes, read Starshipseleven's post, he explained it better than me. And what I called lame was the excuses some developers make, not their work. This I respect very much, as a long time sim player.

[starshipeleven]

This is not correct. The calculations are done with limited precision. A classic issue you will run into is z-fighting. This is where you might have to get creative in your approach of rendering near and far objects (scaling down far objects and moving them closer to camera, reversed floating pioint z-buffer, logarithmic z-buffer etc).

I was already assuming the trickery to avoid limited precision issues was in effect.
In any decent game engine you can place things at arbitrary distances and if the engine isn't a POS the distance will not matter, even if the object is too small to be seen it still weights the same on performance, which is why there always is at least some mechanism that detects it is "too far" and blocks its rendering (like happens for the parts of objects behind other objects, that aren't rendered since a long time ago).

For that reason there are bunches of tricks to render realistic amounts of far away objects without tanking performance hard like using different poly-count models/shaders/textures for different distances (as none will be able to see the higher detail anyway).

[gilboa]

For the huge landscapes, read Starshipseleven's post, he explained it better than me. And what I called lame was the excuses some developers make, not their work. This I respect very much, as a long time sim player.

Sorry for the misunderstanding ( on the lame part ).

I've read Starshipseleven's post after commenting on yours.
I'm far from being an expert in engine design but I at least as far as I understand he's only partially correct:
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) and spend a lot of resource of LOD v.s. range optimizations, neither of which is required by FPS focused engines.
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. (Even trying to refactor highly optimized single-threaded code into multiple threads can be nearly impossible)

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

- Gilboa