Devs real question
-
I reported this once. I think I also had Janhas wall model and pylons too, so I will start from Clean Install than only install Janhas F-16 to compare to pure stock one later.
“TOPGUN VIEW” setting might also help to fix angle to a specific degree.OK Now I remember this thread of yours. I saw the vid now again and a few observations:
1. The Hit with the Janhas model is MUCH more critical - 60 to 30
2. With default model it feels like there is a very minor hit and actually as you get away from the center of the AB you are getting away from the stack of features and have less objects in view so you gain 6-7 and later 10-11 FPS, that makes sense.
3. I honestly don’t know to explain the hit with Janhas model without doing some dedicated debugging. Maybe he has something crazy in the Gear, but it’s hard to tell without serious profiling for that…
-
I believe the JanHas models use a lot of transparencies. That may be the cause of a lot of draw calls.
-
Because even 100ft low-pass flying won’t hit FPS but touching the ground hit FPS…
I’ve already seen tow other ppl reporting for big FPS drop as soon as they touch the ground but on my side I’ve never had such issue.
They’ve never managed to find why. One of them had the issue vanished after updating to up3 if I remember corectly. The other one solved after full re’install.
http://www.checksix-forums.com/viewtopic.php?f=281&t=200437&p=1646453&hilit=FPS#p1646453
You are the third person talking about it.
EDITED after check related thread in French forum for correct informations.
-
Wow I seem to have contributed to kicking the hornets nest a little (haha)
For the record, I was in no way suggesting that what BMS is doing is wrong or should be changed.
You guys rock, and I wouldn’t want to try to mess with perfection. Seriously.My suggestions were in no way meant to be applied to any modification of any existing Falcon code (1.08, sp4, whatever).
I was talking blank sheet design. And I think my post was fairly realistic about the downsides involved.Just throwing that out there.
Good fun, everybody :lol:
-
VR…
lol
-
The DCS VR has exactly the same issues as its a hardware limitation, not a software one. The F-16 on the other hand has quite a bit more emphasis on its displays than does the Huey.
Given that you are shooting down b.s. for suggesting a new sim made from scratch open source, its pretty hard to say that making a new sim would kill Falcon 4.
I would say that’s somewhat true regarding being more dependent on gauges. I don’t have the Huey but I do have the L39 which has and uses many gauges and hard to see radio dials and it works fine. In fact I had a harder time seeing everything with TIR than I do with the Rift. What’s made me hopeful are the videos I’ve seen and discussions on Reddit where guys like us are trying different things and getting pretty damn good results without rewriting code and instead using available programs and probably some hacks. In the videos I’ve seen, the inside of the pit looked fine for the most part. It was getting it to sync with the outside aircraft textures they had issues with and many others I’m sure.
For me, I don’t need a whole new sim. Falcon is more complete now than I ever thought it would be when I started and for that I’m grateful. In fact I really don’t see anything else that needs to be added to it other than making the few remaining systems not enabled in the jet function and adding VR support. Once done it will be a perfect F-16 with dynamic campaign simulation. It was never an F/A18, F15 or any other jet sim. To those of you that say the graphics in VR are bad, how long have you flown Falcon? It’s still on the ass end of visual quality compared to other sims apart from the pit so who cares? The immersion makes up for shitty resolutions. Besides, how many people flying BMS have a system that allows them to crank all settings and get even 60FPS? So it’s not like anyone is getting visual ecstasy as it stands now. Lastly, the code in DCS is still not optimized completely for VR. Put on an HMD and fly the new IL2 Sturmovik and then get back to me on VR graphics hardware limitations. -
You can try and revive Open Falcon…that should get you where you want to go…yeah…
That’s what happened last time there were a couple different teams working on Falcon…
-
To those of you that say the graphics in VR are bad, how long have you flown Falcon? It’s still on the ass end of visual quality compared to other sims apart from the pit so who cares? The immersion makes up for shitty resolutions.
when your resolution gives you a quarter mile tally range, you have to start recognising that the resolution is too low.
-
I have a number of commercially produced flight sims on my shelf that are no longer supported and I can’t run on my current system. BMS still runs, gets better all the time, and has not cost me a cent. I kind of like the way things are.
-
when your resolution gives you a quarter mile tally range, you have to start recognising that the resolution is too low.
Ok, ok, fair enough lol.
-
when your resolution gives you a quarter mile tally range, you have to start recognising that the resolution is too low.
I used to play AF @ 1280x1024 and don’t remember having problems with tally. In DCS, I can actually spot things easier in VR (although still abysmal) than on a 32" 1080p, and I can spot things way easier in BMS @ 1080p than I can in DCS @ 4k. I think the game engine has more to do with tally than does res. Besides, they already have higher res versions coming out.
-
I used to play AF @ 1280x1024 and don’t remember having problems with tally. In DCS, I can actually spot things easier in VR (although still abysmal) than on a 32" 1080p, and I can spot things way easier in BMS @ 1080p than I can in DCS @ 4k. I think the game engine has more to do with tally than does res. Besides, they already have higher res versions coming out.
Well, thats should be because of SmartScaling factor if you enable it.
and this is why it is needs to be there.
This isDCS draws 1 dot point when the drawing size of the airframe becomes 1 pixel or less. this will work when only planes are 10nm or more away, but will not work in WVR range as plane will be larger than a dot there.
2-3px planes are almost as unvisible as 1 dot plane. BMS draws same plane in 6 or 7 pixels(if enabled SS) But be careful SS is not mainly for tally but for orientation detection.
Why you tally easily in VR is because of RL FOV and In-Game FOV matches in VR. So you will see things in 1:1 angular size. Far distant black “dot” also becomes larger as screen becomes lower less.
-
I used to play AF @ 1280x1024 and don’t remember having problems with tally. In DCS, I can actually spot things easier in VR (although still abysmal) than on a 32" 1080p, and I can spot things way easier in BMS @ 1080p than I can in DCS @ 4k. I think the game engine has more to do with tally than does res. Besides, they already have higher res versions coming out.
I should use more precise terminology. Im talking angular resolution here.
VR with a 210 degree FOV would need over 4k resolution before it even approximates the current angular resolution offered by a 1080p monitor at 80 degree FOV.
scaling effects in the game engine are attempts to get around these hardware limitations, yes.
-
Well 8K is on the way along with 20K so those things in 10-20 years for flight Sims might totally replace monitors as trackir did for the POV button on sticks.
Στάλθηκε από το MI 5 μου χρησιμοποιώντας Tapatalk
-
This post is deleted! -
I’m curious what kind of “big” changes occur when the aircraft touches down vs being in the air? I wouldn’t jump straight to rendering or graphics per se, even though it’s an easy target to pick on. As you said, the GPU isn’t really being taxed that much, and most high-end systems rarely see double-digit CPU usage either. Are there “environmental” changes in the code which occur only when the aircraft is on the ground? Bubble changes from Player/Aircraft to airfield? ATC system changes? Something specific to a WoW check? FM shock/strut/bounce calculations/wheel slip? Extra collision detection for ground structures? AI Taxi code checks? Change in terrain rendering? Change in Tree drawing? Different light processing? Obviously it is tied to the graphics in some way if the issue is exacerbated with higher-poly models, but it really sounds like that may be more of a symptom than a root cause. I have a hard time believing there is enough detail in the Gear to cause a problem like that, and even if that were the case, it should present itself when you lower the gear, not when the gear touches the ground. If transparency was an issue it shouldn’t be limited to only on the ground, even if the transparency is specifically tied to the gear, it goes back to why doesn’t it present when you lower the gear instead of only on the ground?
I’m guessing the plethora of “environment” changes are dependent on the WoW check, so it sounds like that’s a more likely candidate for a culprit. IMO anyway. Happy coding.
Hi,
First of all let’s clear some points:
1. The fact that the CPU in BMS doesn’t work too hard (compared to a multi-core task) doesn’t mean anything, it only means that BMS doesn’t utilize it efficiently. So even though the CPU only utilize 1-2 cores for BMS really, still your code better be efficient cause bad code will have an effect.2. GPU doesn’t work too hard either, but that’s mainly due to the engine not able to feed it fast enough. That can translate directly to number of draw calls. It is known that as number of draw calls increase, the app is becoming more CPU-bounded and less GPU-bounded. So if for example a model’s GEAR system is VERY heavy, it may decrease FPS easily…
I don’t know really from where the drop comes from for sure, but the fact that you see a WAY more severe drop with the Janhas model means that there is something bad with that model. If it was such a generic problem with any model in the sim, I’m sure it would have been investigated deeper and the bug would have been found.
The fact that we “dismiss it as model/rendering” is simply because we never seen such a serious drop with the default model. And we aren’t going to care about rendering for now because that’s why there are the model/textures size limits that we recommended everyone to adopt, but if someone don’t want to follow, it’s his choice, just don’t come complaining if you used the product out of its recommended use-conditions
-
I’m guessing the plethora of “environment” changes are dependent on the WoW check, so it sounds like that’s a more likely candidate for a culprit. IMO anyway. Happy coding.
your assumptions are totally incorrect
nothing much change when aircraft is on ground, actually many things are not running anymore when on ground, so the code is lighter
-
This post is deleted! -
It was a question more than an assumption, hence why I started with “I’m curious…”. But the fact remains the problem presents when the aircraft touches the ground, not when the aircraft changes configuration (IE When the model displays the gear). And I asked “what changes” not “What gets heavier” so the fact there are changes being made, even if it’s in the form of removing other processes, means from a troubleshooting perspective it doesn’t make sense to entirely dismiss the idea, just like it doesn’t make sense to entirely dismiss the render/draw call idea. Lighter doesn’t always mean simpler, especially if the still-running routines are looking for something in the not-running-anymore routines.
But whatever, I’m not trying to tell anyone how to do anything, just trying to spark some thoughts on things which may be outside the normal box that might lead to some light bulbs. No harm intended.
Look I’ll tell you this, I always had a VERY sharp eye for FPS changes, it’s a habit I got since I started deving Falcon at Particle system area which is can be disastrous to FPS. I can assure you that if there was really something interesting between ground/no-ground, I would have noticed that, as I also fly with my VFS full missions from time to time. I don’t remember ever seeing something that is out of the ordinary.
If Janhas model cause a 50% FPS drop while default model only gets a none-conclusive 10%, nobody from the coding team would care, really. We do WHATEVER we can to make people understand the limitations, but if someone like to bang his head against the wall, what I can do about it? I promise you that if there was a real issue here, we would have have profiled/debugged it to death until the issue is found, it’s not such a big deal to put a timer on any function and get the time it eats out of a given frame…
-
well at the very least does the BMS team accept donations?
maybe a feature poll, get the community more involved etc. etc.