So what with DX11 support?
-
3dsMax is essentially to create animations and export the 3D model for use in BMS.
If that is the case then it precludes a lot of people from ever contributing content to BMS which is unfortunate. I have searched but I can’t find anything about exporting directly from Blender so that does not exist. I can’t afford 3DS Max so I won’t be able to develop a Blender -> 3DS Max workflow even if I wanted to.
-
PBR looks good but how exactly does it work? specifically how would it impact fps in bms?
The performance overhead is typically not that high, but there is an increased requirement for video RAM to store the additional textures to be loaded, depending on the PBR implementation. Engines such as Unity and Unreal Engine support various metallic/roughness formats where you would typically have your diffuse/albedo textures, your normal map textures and then separate texture sets for metallic and roughness. All these textures need to be loaded into video memory and take up storage space, so some simulation developers try to embed as much information into the smallest file spaces to try and save on those. X-Plane for instance embeds the PBR texture info into the alpha channel of the normal maps. It is a crude solution but it works to some degree but it does not provide a 1:1 representation between the development software and the sim. Each texture set has two textures for X-Plane, and a third if you have an emissive set.
DCS embeds metallic/roughness data into a single texture but within the individual RGB channels to separate the info. DCS thus uses three texture files for each texture set.
The VRAM requirement depends not only on the number of additional files but also the resolution of the files. A high definition aircraft could have multiple 4K texture sets to allow a uniform texel density over the entire object - and that is only referring to external. Internally you may need the same of even more depending on the level of detail you are going for.
If I had to guess, adding PBR could add an additional 30% - 50% VRAM requirement over a standard albedo/diffuse & normal map texture set. This is a very rough guestimate that will depend entirely on the PBR implementation. On a simulation that is mainly CPU dependent the performance impact could be negligible. If you are running an old video card that is already struggling from low video memory then the impact could be noticeable, but I have no idea what the current BMS underlying system looks like so I can’t really comment on that. -
The performance overhead is typically not that high, but there is an increased requirement for video RAM to store the additional textures to be loaded, depending on the PBR implementation. Engines such as Unity and Unreal Engine support various metallic/roughness formats where you would typically have your diffuse/albedo textures, your normal map textures and then separate texture sets for metallic and roughness. All these textures need to be loaded into video memory and take up storage space, so some simulation developers try to embed as much information into the smallest file spaces to try and save on those. X-Plane for instance embeds the PBR texture info into the alpha channel of the normal maps. It is a crude solution but it works to some degree but it does not provide a 1:1 representation between the development software and the sim. Each texture set has two textures for X-Plane, and a third if you have an emissive set.
DCS embeds metallic/roughness data into a single texture but within the individual RGB channels to separate the info. DCS thus uses three texture files for each texture set.
The VRAM requirement depends not only on the number of additional files but also the resolution of the files. A high definition aircraft could have multiple 4K texture sets to allow a uniform texel density over the entire object - and that is only referring to external. Internally you may need the same of even more depending on the level of detail you are going for.
If I had to guess, adding PBR could add an additional 30% - 50% VRAM requirement over a standard albedo/diffuse & normal map texture set. This is a very rough guestimate that will depend entirely on the PBR implementation. On a simulation that is mainly CPU dependent the performance impact could be negligible. If you are running an old video card that is already struggling from low video memory then the impact could be noticeable, but I have no idea what the current BMS underlying system looks like so I can’t really comment on that.Do you think bms developers are able to implement PBR completely? it is not possible to recreate bms into Unity and Unreal graphics engine?
-
Do you think bms developers are able to implement PBR completely? it is not possible to recreate bms into Unity and Unreal graphics engine?
BMS devs are able to do whatever they want, considering they decide how much time and resources they want to spend. Implementing PBR is not trivial, but they already have DX11 in place. The hardest part was already done. Implementing PBR implies modifying the basic Albedo/diffuse shaders to take into consideration more textures like the metallic and such, also they would need to create from the ground up all the new required textures for the whole game. Again, it is not trivial, but the backend system required to build PBR rendering is already there.
Recreating BMS into Unity or UE is not going to happen, ever. There are many reasons, I am not the product owner of the game, so there are going to be millions more reasons why not, but the most important is that you already have the Empire State building in place, you don’t take the building down just to replace the exterior tiles or a couple of walls in the interior.
Building software is just like building BIG buildings, like a stadium, a carrier or even a jet. You need lots of things to build a carrier, lots of money, many years, decades of experience, LOTS of experience, and the correct people. You just don’t sink a carrier to build a new one just because you want more F18s on the deck.
I hope you liked the analogies there
-
Well said. While many of these engines do offer the advantage of having access to modern techniques to build and modify content, these engines suffer from severe ‘bloat’ as they are designed to try and do everything. Desktop flight simulators are very unique in how things get processed and rendered compared to first person shooters and other types of games. Some games have a visibility of a few hundred meters - simulations are expected to to display 100km or further.
Because these game engines focus on smaller environments the coordinate systems are still 32-bit and you start suffering from floating point jitter the further you move away from the origin. There are ways to fool the system but it becomes a messy affair and is not really suited to flight simulation. There are engines that support 64-bit floating points but these are expensive to license and still suffer from bloat.
At the end of the day it is not the engine that determines the success of a product, but what the developers do with it. Anyone that ever says a game is crap because it was developed in engine XYZ has no idea what they are talking about. The time and effort invested in a specific engine cannot be easily undone and rejigged to work in another. Part of an engine can be swapped out and improved on to make it better, but changing an engine is a massive undertaking that almost equates to starting from scratch.Edit: An engine and a renderer is not the same thing.
-
…Part of an engine can be swapped out and improved on to make it better…
This is what I meant, taking the parts we need and putting them in bms
Do you think it is possible to convert dx 11 to 12 or to vulkan on bms? -
Do you think bms developers are able to implement PBR completely?
Yes…
it is not possible to recreate bms into Unity and Unreal graphics engine?
No
As it was said already, such “generic engines” may be good for matching many scenes but not necessarily a flight simulation needed range and other unique properties. So while you can theoretically create breath-taking scenes with these engine with the reuse of some existing stuff, I doubt they will answer ALL the necessary requirements from a BMS engine.
Also, for having total freedom, and being able to debug tweak and being independent of some potential limitations (e.g performance) that may exist in some 3rd party library, we will always prefer to have the source code with us, statically linked with the options to fully debug including GFX debugging which isn’t trivial at times even this way (We already have some problems with debugging GFX with some of the modern versions of VS).
Do you think it is possible to convert dx 11 to 12 or to vulkan on bms?
Yes, for sure it’s possible but 3 things here:
1. It will require work, at least some (I don’t know the exact estimation). Probably less for DX12 than Vulkan.
2. Vulkan may not be the “wet dream” that everyone think of when compared to DX11/12. And yes I know the benchmarks, numbers etc, so enough of those. XP11 may give such a boost because it was OGL before, you may not know if Vulkan will be so much better than DX11/12.
3. If you already push the GPU to work 100% all the time, I’m really not sure how much you may gain from an API which its primary advantage is parallel-context (i.e the ability to process draw calls in parallel, because you may just shift some of the draw-calls bottleneck elsewhere, so GPU will be able to digest draw calls in parallel but if it’s already fully utilized, how can you gain?)I do agree though that probably in general DX12 and maybe especially Vulkan will produce some performance gain compared with DX11, but the question is how much and does it worth the effort? Regardless of that DX12 has some nice features over DX11 (More of a low-level kind of stuff, rather than rendering methods features) but DX12 force Windows 10 which until now we still tried to avoid forcing (Although I personally think at some point there will be no choice)
-
Let the developers utilize DX11 first and correct me if I’m wrong , but iirc DX12 and Vulkan are quite similar APIs. So rewrite GFX engine to either DX12 or Vulkan should take similar amount of work. I’d opt for Vulkan because it would help running BMS on non-Widows systems.
Vulkan being available on WIndows7, 8/8.1 is another bonus. -
but DX12 force Windows 10 which until now we still tried to avoid forcing (Although I personally think at some point there will be no choice)
as long as BMS runs on my Windows Me we are good
-
Let the developers utilize DX11 first and correct me if I’m wrong , but iirc DX12 and Vulkan are quite similar APIs. So rewrite GFX engine to either DX12 or Vulkan should take similar amount of work. I’d opt for Vulkan because it would help running BMS on non-Widows systems.
Vulkan being available on WIndows7, 8/8.1 is another bonus.If we could use a vulkan version of bms on linux, assuming it is compatible with all products, joysticks, vr viewers … to be ready for the future, I would create a partition with linux only for bms
-
Guys … DX11 just came in and is not fully exploited yet and you are suggesting Vulkan implementation?! Are you nuts?!
-
This is what I meant, taking the parts we need and putting them in bms
Do you think it is possible to convert dx 11 to 12 or to vulkan on bms?I would like to add something important, it is true that the term “modules” and “parts of a system” exists in the Software Engineering world, in theory, back in the ‘80 and 90’, modules were created to give us the freedom to swap different modules from different systems. In real life that doesn’t happen that easily, there exists something called coupling and cohesion, and they tell us about how much one module is tied to another module in a way that if you break the bond between them, they won’t work alone anymore. So the term Modularity and swapping out modules is relative, and tends to not work the way we want it to work.
DX12 and Vulkan are both a different beast than DX11.
DX11 is a great leap forward for BMS, MANY games run on DX11 nowadays. There is no need to change the rendering API if there is no real need. We need to exploit DX11 -
Guys … DX11 just came in and is not fully exploited yet and you are suggesting Vulkan implementation?! Are you nuts?!
Quite contrary, there’s lots development headroom with DX11, all in all even MSFS2020 is still DX11. I merely wanted to say that if/once BMS team decides to move to next GFX API, it should be similar amount of work.
-
….you start suffering from floating point jitter the further you move away from the origin…
but so how did they do with fs2020 and predecessors?
-
I would like to add something important, it is true that the term “modules” and “parts of a system” exists in the Software…
Guys … DX11 just came in and is not fully exploited yet and you are suggesting Vulkan implementation?! Are you nuts?!
Let the developers utilize DX11 first and correct me if I’m wrong , but iirc DX12 and Vulkan are quite similar APIs. So rewrite GFX engine to either DX12 or Vulkan should take similar amount of work. I’d opt for Vulkan because it would help running BMS on non-Widows systems.
Vulkan being available on WIndows7, 8/8.1 is another bonus.But are vulkan and DX free? I mean why should they be debugged? there are no guides to integrate them?
I don’t know much about these things, i don’t even know how a motor like unity works. -
Quite contrary, there’s lots development headroom with DX11, all in all even MSFS2020 is still DX11. I merely wanted to say that if/once BMS team decides to move to next GFX API, it should be similar amount of work.
Hey,
Not exactly - In fact the current rendering engine (i.e the one running in 4.35) is a “new beast” which should allow much better flexibility with potentially replacing the lower-level API (i.e replace DX11 with say DX12) later. However, as it was stated above already, there are still ties and dependencies that will still require some work at least. And last but not least, as you can see even FS2020 runs of DX11 and not (at least not yet) DX12, although we are talking about MS here who owns both and probably some of the most knowledgeable folks in the world regarding DX and GFX development.
In short - I think that all those talks about replacing the API before we even brought DX11 to be close to fully utilized features-wise, I think there is simply no point to that.
But are vulkan and DX free? I mean why should they be debugged? there are no guides to integrate them?
I don’t know much about these things, i don’t even know how a motor like unity works.You are mentioning Low-level GFX APIs before you understand the meaning of such an API and what exactly may be the advantages of replacing (or upgrading if you insist). DX11 is fully suitable to give BMS all the graphical bells and whistles you can think of (and again, FS2020 is a proof of that), so what you will see or not in BMS in future versions simply depend on what exactly we upgrade/implement rather than what low-level API we use.
-
… so what you will see or not in BMS in future versions simply depend on what exactly we upgrade/implement rather than what low-level API we use.
… and depends on community investments and interest and efforts (BMS team being just a part of this community) …
Anybody can start working on higher definition of PS effect textures (flame explosion, dust smokes … etc …) no need of DX11 for this.
To do something looking like this:
ParticleSys.ini for texture & effects definition
Textures are in …\Data\TerrData\MiscTexNotepadd++ (text edition tool much better than Windows notepad) : https://notepad-plus-plus.org/downloads/
Download link for Gimp (free) : https://www.gimp.org/
Some Gimp tutorials : https://www.gimp.org/tutorials/@ TheFalcon: Be an actor of your dreams!
-
Hey,
Not exactly - In fact the current rendering engine (i.e the one running in 4.35) is a “new beast” which should allow much better flexibility with potentially replacing the lower-level API (i.e replace DX11 with say DX12) later. However, as it was stated above already, there are still ties and dependencies that will still require some work at least. And last but not least, as you can see even FS2020 runs of DX11 and not (at least not yet) DX12, although we are talking about MS here who owns both and probably some of the most knowledgeable folks in the world regarding DX and GFX development.
In short - I think that all those talks about replacing the API before we even brought DX11 to be close to fully utilized features-wise, I think there is simply no point to that.
You are mentioning Low-level GFX APIs before you understand the meaning of such an API and what exactly may be the advantages of replacing (or upgrading if you insist). DX11 is fully suitable to give BMS all the graphical bells and whistles you can think of (and again, FS2020 is a proof of that), so what you will see or not in BMS in future versions simply depend on what exactly we upgrade/implement rather than what low-level API we use.
Totally agree, it’ll take years before DX11 won’t be enough for BMS. Once this happen evaluating available APIs will be valid, now it’s kinda moot point. Regardles if it’ll be DX 1x, Vulkan or whatever it’s gonna be called it’ll be tremendous effort as basic paradigms of what GFX API is supposed to be has changed and it’ll change even more as 3D scenes probably gonna be fully raytraced rather than rasterized. But still it’s a song of the no so near future.
@De-Jay, kinda agree, but is current BMS particle system robust enough? Is there any planned changes in that area to use new features brought with migration to DX11? I understand that artists right now are more inclined to wait a bit to see if here’ll be any changes to their field of interest so their work ain’t gonna go in vain.
-
If we could use a vulkan version of bms on linux, assuming it is compatible with all products, joysticks, vr viewers … to be ready for the future, I would create a partition with linux only for bms
One can dream… IMNSHO I think BMS & Linux would be a match made in heaven if this platform ever received official support. A free, “best of breed” flightsim mod / F-16 study-level simulation running on a truly free (free as in speech and in beer) operating system, how much better can life get? :peace:
All the best,
Uwe
-
Forget VR that is yesterdays news
https://varjo.com/products/xr-3/
https://varjo.com/blog/case-dassault-aviation-developing-immersive-pilot-training/
115° FOV? WTF?