Ff you could have one thing in the next update it would be…
-
So not sure about the lighting bits, but in my opinion, I have always thought the ground textures for night actually look pretty legit under NVGs. I was impressed by that while flying around at Kunsan. The “lights” looked a lot more like the bloom effect you should normally see.
I was suggesting that the effects which we are discussing would need better tools, or better terrain tiles to create such effects. Any light sources should be able to reproduce what we see in the pictures you listed. NVG in BMS is pretty good, but you are discussing how to improve on such effects. Just mentioning ways to create those effects without getting too involved with the current level of lighting in the sim.
DX11 would allow for far better lighting effects using shader 5.0 instead of 3.0 for DX9.0c. Oclusion and tessalation tools would allow for many added features to BMS that have been requested from the community in this thread alone. I am an advocate for pushing the GFX engine up. It would solve some problems IMO. The GFX would certainly be better and the GPU would do more pre/post processing that could free up the CPU. Please, don’t get me wrong here. The GFX in BMS currently is excellent. But could it be better and create more headroom for the CPU? That only the devs testing the idea of using a higher DX engine could answer. I read a lot of requests for features that would really benefit from a higher GFX engine. Implementing that higher engine may not even be possible. Just don’t know. But if it could be done, and with a reasonable amount of effort (not taking 10+ years to implement a DX11 engine) then that would be the next level to pursue. Again, just my 2 cents here. To me, there seems to be a lot of requests for such an upgrade, but is it even possible. Just don’t know.
-
I wouldn’t bet on DX, Vulkan looks more promising and might save some or give the opportunity for those that can’t afford money wise.
Also we should have in mind that newer DX seeds the demon (meaning new juicy gfx options) in us , so there goes the performance gain.I don’t fully understand the gain of going from shader 3 to 5 but just as I read it (and not understand it) sounds inefficient.
Στάλθηκε από το MI 5 μου χρησιμοποιώντας Tapatalk
-
I wouldn’t bet on DX, Vulkan looks more promising and might save some or give the opportunity for those that can’t afford money wise.
Also we should have in mind that newer DX seeds the demon (meaning new juicy gfx options) in us , so there goes the performance gain.I don’t fully understand the gain of going from shader 3 to 5 but just as I read it (and not understand it) sounds inefficient.
Στάλθηκε από το MI 5 μου χρησιμοποιώντας Tapatalk
I agree that a change up to the DX engine would cause many here who don’t have GFX cards capable of supporting DX11. As I have been reading that the API process (pre) would not require much to change over. Instead of floating buffers (DX9.0c) you would have to arrange the stacks selectively to each buffer/pipeline. The addition of writing Tessalation code to use with existing code (vertex and index buffer code) could be the straw the breaks the camels back. That would require a bit of code rework. The following describes it better than I can…
“The initial port probably won’t be too hard for you. It’s not too hard to spend a week or two and get a DX9 renderer working on DX11. What’s harder is actually making it run fast (or faster), and integrating the new functionality that DX11 offers you. Constant buffers are usually the biggest performance problem for a quick and dirty port, since using them to emulate DX9 constant registers can actually be slower than doing the same thing in DX9. Past that you may need a lot of re-writing for things like handling structured buffers instead of just textures everywhere, having texturs/buffers bound to all shader stages, changing shaders to use integer ops or more robust branching/indexing, and so on.”
So, yes Arty, there could be a performance issue with porting BMS to DX11. The good news is that most modern GFX cards are fast enough, with enough pipeline rendering and horse power, that this should not be an issue. Better shaders would be the main for this discussion. 5.0 (almost ten times the shader levels than 3.0) could create very subtle gradient light features. Not to mention tessalation for things like explosions (particles of debris, ect.) to haze effects, fog and heat/motion blur. So, water under the bridge at this point, but it does look like it is possible. I still don’t know considering how complex the Falcon engine really is.
-
Yeap jhook… very good point I have read that reference in an article, or something like that.
If Vulkan is doing what it says and with the performance it says I believe dx11 is a no go. It offers IIRC same as dx12 features and talks directly to the Hardware.
Both solutions kills a large portion of HW to the recycle bin. IIRC both need dx11 compatible HW.
Now since the Vulkan does the same but with way better performance… I believe it’s a one way trip.
The dev will take the freak out either way. Why freak and the users to take them to buy 1070-1080Ti when they could get maybe a 1050 and enjoy same performance?
Additionally such a major change will be nice to be accompanied with the terrain engine that we all talk for years now and we know is needed.
But outside of the dance we can sing as many songs as we want… The dev’s have to carry the burden. We just take storage space on an hdd where those posts will be archived.
And roads are not covered with rose petals…
-
But outside of the dance we can sing as many songs as we want… The dev’s have to carry the burden. We just take storage space on an hdd where those posts will be archived.
And roads are not covered with rose petals…
yep
This part got my particular attention :
“The initial port probably won’t be too hard for you. It’s not too hard to spend a week or two and get a DX9 renderer working on DX11”
This is the kind of guy who has never seen what Falcon Code base is , from the 90’s ….
-
yep
This part got my particular attention :
“The initial port probably won’t be too hard for you. It’s not too hard to spend a week or two and get a DX9 renderer working on DX11”
This is the kind of guy who has never seen what Falcon Code base is , from the 90’s ….
Come on… give the man a break. He meant 3-4 weeks… :lol:
Sorry for the OT.
-
Yeap jhook… very good point I have read that reference in an article, or something like that.
If Vulkan is doing what it says and with the performance it says I believe dx11 is a no go. It offers IIRC same as dx12 features and talks directly to the Hardware.
Both solutions kills a large portion of HW to the recycle bin. IIRC both need dx11 compatible HW.
Now since the Vulkan does the same but with way better performance… I believe it’s a one way trip.
The dev will take the freak out either way. Why freak and the users to take them to buy 1070-1080Ti when they could get maybe a 1050 and enjoy same performance?
Additionally such a major change will be nice to be accompanied with the terrain engine that we all talk for years now and we know is needed.
But outside of the dance we can sing as many songs as we want… The dev’s have to carry the burden. We just take storage space on an hdd where those posts will be archived.
And roads are not covered with rose petals…
Vulkan does sound very promising. Either way, a newer GFX engine would allow for a lot of feature upgrades to the existing GFX. Such as explosion “shock waves” or dense fog at ground level for examples. It does not matter to me if BMS goes DX11 or Vulkan. Both seem to have the tools needed to create better NVG, or better looking terrain (at low altitudes for example). I have been observing Outerra for some time. The levels of detail are astounding! BMS may not reach that level, but it certainly could get close to it IMO. Time will tell if the Devs decide to upgrade the GFX engine side of BMS. Again, don’t get me wrong. BMS 4.33 looks and feels great as it is. Just suggestion that a newer GFX engine would allow for more features (graphically) to be implemented into the sim (such as improved NVG, as everyone was discussing).
-
This post is deleted! -
@MorteSil you seem to be the hidden ace around…
I can provide some >> RL << shots when time comes for comparison. You know where to find me.
-
1. TGP as standard loadout in ALL modes and missions
2. TGP maintain track during switch to strafe
3. JHMCS assisted ground markpoints
4. A way to get HAD coordinates into the system (prolly also mark function)
5. send TGP position via data link -
well, number 5 you can do already using even the IDM datalink BMS uses…
number 1 I dont fancy carrying an ATP on all missions - G limits are a bit restrictive.
number 2 Im not sure if you can do, either - in STRF the radar adopts AGR and that moves the SPI to the ranged point.
-
well, number 5 you can do already using even the IDM datalink BMS uses…
number 1 I dont fancy carrying an ATP on all missions - G limits are a bit restrictive.
number 2 Im not sure if you can do, either - in STRF the radar adopts AGR and that moves the SPI to the ranged point.
number 1: yes, i agree, but the possibilities in terms of VID are pretty convincing…
number 2: that’s the problem… I find a Target with the pod and switch to strafe and the TGP immediately loses the track and boresights on the pipper position… it’s kind of annoying to switch back and forth for the BDA… better would be following flow: I mark a position on the ground with JHMCS, slew my TGP onto it, establish a track, then select guns and I retain the track and the square in the HUD for TGT ID and I can immeadiately asses my hits.
number 5: i have only a very uncomfortable way method to enter the coordinate into the system. is there a way to do it easy? like a single button press will accept the coordinate into a waypoint store?
-
For your nr5 read the manual regarding markpoints
-
I had another thought. This is a not so important request, but I’d like to see the autopilot get some love. Altitude hold is sketchy at best and doesn’t lock onto the altitude you are currently at but probably within about 200-300 feet of that altitude, (i.e. the altitude I wanted.) Also, any significant turns (more than a few degrees) cause the aircraft to make abrupt 45 degree banks which also subsequently causes the aircraft to descend. Not the most bueno.
Every aircraft I have flown that has a multi axis autopilot has made turns at standard rate. At least changing the limit to 30 degree banks and damping the roll rate used by the autopilot would be great. Then I could probably use the autopilot with more confidence. Currently, the only mode I am ever comfortable with it pitch hold.
Also, a +1 to adding a working slip ball and a working turn indicator. Yes the FLCS “coordinates” your turn for you, but it’s still useful to know, and having a turn indicator that tells me if I am in a standard rate turn would be nice for flying Instruments. Then I don’t have to do mental math every time I am in a hold and want to practice using my standby instrument. Just saying…
The big one though is making the autopilot more reliable and less aggressive.
-
I had another thought. This is a not so important request, but I’d like to see the autopilot get some love. Altitude hold is sketchy at best and doesn’t lock onto the altitude you are currently at but probably within about 200-300 feet of that altitude, (i.e. the altitude I wanted.) Also, any significant turns (more than a few degrees) cause the aircraft to make abrupt 45 degree banks which also subsequently causes the aircraft to descend. Not the most bueno.
Every aircraft I have flown that has a multi axis autopilot has made turns at standard rate. At least changing the limit to 30 degree banks and damping the roll rate used by the autopilot would be great. Then I could probably use the autopilot with more confidence. Currently, the only mode I am ever comfortable with it pitch hold.
Also, a +1 to adding a working slip ball and a working turn indicator. Yes the FLCS “coordinates” your turn for you, but it’s still useful to know, and having a turn indicator that tells me if I am in a standard rate turn would be nice for flying Instruments. Then I don’t have to do mental math every time I am in a hold and want to practice using my standby instrument. Just saying…
The big one though is making the autopilot more reliable and less aggressive.
+1!
-
number 1: yes, i agree, but the possibilities in terms of VID are pretty convincing…
number 2: that’s the problem… I find a Target with the pod and switch to strafe and the TGP immediately loses the track and boresights on the pipper position… it’s kind of annoying to switch back and forth for the BDA… better would be following flow: I mark a position on the ground with JHMCS, slew my TGP onto it, establish a track, then select guns and I retain the track and the square in the HUD for TGT ID and I can immeadiately asses my hits.
number 5: i have only a very uncomfortable way method to enter the coordinate into the system. is there a way to do it easy? like a single button press will accept the coordinate into a waypoint store?
Well, number 1 is not prototypical. Number 2, you should be making the proposal to Lockheed Martin, not BMS. Number 5, yes there is.
-
C they try to bolt them on to an existing code base, which never works.
Well we must admit that BMS runs well on DX9 coming from DX5 / 7 ? so someone must do things properly somehow huh ?:p
-
Sure, but was it rewritten to take into account DX9 features? That is the point being made…
-
Well we must admit that BMS runs well on DX9 coming from DX5 / 7 ? so someone must do things properly somehow huh ?:p
Minimum requirement for Falcon 4.0 was DirectX 5.0, it came with an optional install of DirectX 6.0.
-
Sure, but was it rewritten to take into account DX9 features? That is the point being made…
of course it was rewritten , else we couldnt have ligthing, HDR, heat blur and many other Post Processing effects