4.36 might very well answer the question, even from Microprose’s perspective.
Explain better pls
4.36 might very well answer the question, even from Microprose’s perspective.
Explain better pls
…@ TheFalcon: Be an actor of your dreams!
I would be more interested in creating a terrain shape that is not edgy and photorealistic terrain textures, bms really needs that.
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.
….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?
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
…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?
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?
I think VR support would be nice for….VR users. A large portion of us currently flying with TrackIR or other head tracking solutions will most likely keep flying the way we always have. With DX11 support I am more excited about the prospects (I am hoping) of having physical based rendering (PBR). It will require an updated renderer, but PBR together with a better lighting system will do a lot to breathe new life into Falcon.
But there is still a lot to do - I browsed through the tactical reference section again tonight and there are a lot of 3D models in need of a refresh. It would be great if members of the community could assist with modding and creating new 3D models. I know it is possible, but without an SDK or published guides it is hard to say what exactly is possible.
PBR looks good but how exactly does it work? specifically how would it impact fps in bms?
V-sync OFF*. It would defeat the point … triple-buffering is all about not tearing, while not blocking on the v-blank signal from the monitor.
(*If you have Nvidia graphics, the control panel offers a setting for v-sync called ‘Fast’ which is their implementation of triple-buffering. I really like v-sync=Fast, (a) because it works in all games, and (b) it also steps out of the way when running in windowed/borderless mode which is essentially triple-buffered always courtesy of how the DWM works.)
So, to recap… two ways to enjoy triple-buffering:
Nvidia control panel: v-sync=off; Falcon in-game: v-sync=off, triple=ON
…then be sure to run in fullscreen-exclusive mode; borderless/window will work ok but have extra latencyNvidia control panel: v-sync=Fast; Falcon in-game: v-sync=off, triple=off
…then run in either windowed, borderless or fullscreen, as you prefer, with no significant difference in latency
if my monitor has 60hz and if bms drops below 60fps with vsync off, what changes between tb(or nvidia fast vsync) on or off?