OpenXRay
Anomaly
- we already have SSA checks which should work better than distance culling. If not -- need to tweak SSA thresholds
- the code is inefficient and full of hardcoded constants. Is there any equation to derive them? If it works for one case, how we can prove it will be working in another?
- just a simple thing that should break this: a large mesh (but large enough to be visible) at a far distance
- we already have SSA checks which should work better than distance culling. If not -- need to tweak SSA thresholds
I do not know what SSA is, I saw that trees and bushes are not rendered at a certain distance, but they are cut off rigidly, with the same code - there is a smooth dimensional geometry shutdown, and it looks much better. Well, besides - apparently there is very little sense from this SSA, since one large location drops FPS to 20-40, in this case / by code - already at the first stage of setup gives an increase in FPS by 2-3 times ... Here is a simple test on a huge location - OpenXRay - optimize geom. test #6
- the code is inefficient and full of hardcoded constants. Is there any equation to derive them? If it works for one case, how we can prove it will be working in another?
That's the thing - this code works smoothly, at different distances, the geometry is cut in different ways, and smoothly, randomly, everything is optional, the player himself can adjust the necessary level of optimization in the options, or disable it altogether. Yes, it may be of little use for a vanilla game (although I don't have the opportunity to test on a weak computer, it may be useful there), because in the original game, the visibility range is cut off by the weather no further than 350 meters, but when using mods, for example, "Atmosfer3" - where the weather range is up to 1000 meters, and when using huge locations - seamless locations - the performance of the engine drops to the floor ... Come on - it's 2022, modding has been developing for more than 15 years - and we are still unable to use seamless locations on the X-Ray engine??? OpenXRay - optimize geom. test #5
- just a simple thing that should break this: a large mesh (but large enough to be visible) at a far distance
Once again, here is a test on a huge location, with a large visibility drawing - OpenXRay - optimize geom. test #6
What was supposed to break here? Or do you mean - the player will see how the geometry disappears? Yes, this is possible - but at the large stages of optimization settings in the game options, almost nothing is noticeable at the first stage, but the first stage of adjustment already gives an increase in fps by at least 2 times - and this is not a bad result, and besides - in many games, in the same "FarCray", I also noticed geometry optimization, and much at short distances - I didn't see people complaining about it... And the player himself has the right to choose how to set up the game. Some players, with weak computers, do go to any tricks - and the textures are put in low resolution, and the detail is reduced to a minimum - turning the game picture into complete squalor - just to somehow play... For me, such optimization is one of the least "evils".
@vTurbine if you know an alternative optimization method - at least with the same result - show it to me!?
Okay, I'm glad you've asked about alternatives. But first, to be clear:
- SSA(= screen space area) checks work in the same way but more reliable than distance culling. The way it should be implemented is to estimate a ratio between projected object bounding volume area and identity one. This will give you actual object importance: small objects at near distance will have high ratio; large objects on far distance will have acceptable ratio. Such technique usually used for LOD estimation, but since we don't have ones (only progressive visuals have LODs) we can simply drop object in this case.
- The "fix" changes game visual appearance in comparison with original, as well as playing experience (you tweaked static objects visibility, but what if NPC is hiding behind a bush which is disappeared?). I think this is the main thing Xottab is fighting against.
- You didn't convinced me that having tons of params is flexible and handy for players. Who will check every level and adjust them? Should I go to the settings tab and increase draw distance every time I going indoor level after outdoor? I know that mod community likes magic tweaks and overcomplication, but come on -- it's 2022, people want run&play.
How we can achieve higher fps without silly popping geometry? The answer is to implement proper occlusion culling. Choose anything you like:
- Software rasterization of occluders (I tried it with Intel solution previously and it was slow as hell, may be worth check it again with multithreaded approach)
- Using occlusion queries (we already use them for light volumes visibility estimation, so easily can get out of pool which will lead to significant lag and inefficiency of occlusion checks)
- Using trivial HZB tests on GPU (needs to revive existing prepass code. Will add a sync point on visibility readback but it will be ok in current engine architecture) I can give more details if you will want to play with any of them.
- SSA(= screen space area) checks work in the same way but more reliable than distance culling. The way it should be implemented is to estimate a ratio between projected object bounding volume area and identity one. This will give you actual object importance: small objects at near distance will have high ratio; large objects on far distance will have acceptable ratio. Such technique usually used for LOD estimation, but since we don't have ones (only progressive visuals have LODs) we can simply drop object in this case.
Okay, good:
- Is it possible with this method to make options in the game settings so that the player chooses the level of optimization that suits him better, for his computer, from weak optimization to strong?
- With this method, will the geometry be randomly cut off, or as I see it now - at a certain distance, everything is simply cut off rigidly?
- With this method, will the geometry /polygons be cut off from the terrain of the location, because now I don't see it - and this is also important on huge seamless locations ...?
- Does this SSA work only for static geometry, or does it also work for dynamic geometry?
- The "fix" changes game visual appearance in comparison with original, as well as playing experience (you tweaked static objects visibility, but what if NPC is hiding behind a bush which is disappeared?). I think this is the main thing Xottab is fighting against.
Well, firstly - it's worth testing - and already accurately setting acceptable distances, at the first stage of setting up this optimization - the distance is 150 meters, and the volume of hidden geometry is quite low - this is quite enough to practically not notice the disappearing geometry - and the further stages of setting - the player already doing it on its own, accepting such inconveniences, in exchange for more productivity... Secondly, the visibility of dynamic geometry is also configured there in parallel - that is, you can adjust the uniform visibility of static = dynamic ...
- You didn't convinced me that having tons of params is flexible and handy for players. Who will check every level and adjust them?
Why check and correct them every time? Once, at the beginning of the game - the player, in accordance with his performance - if he has enough performance, then he does not need to configure anything at all, just leave the function disabled, and if the player has low performance - he adjusts the required level of settings in the options, using trials and checks , and with this setting plays the whole game ...
- Should I go to the settings tab and increase draw distance every time I going indoor level after outdoor?
Of course not - why? That would be weird..
- I know that mod community likes magic tweaks and overcomplication, but come on -- it's 2022, people want run&play.
Many players like it when they are given a choice, when they are given the opportunity - to choose for themselves - how to customize all aspects of the game, and not when the developer decides everything for the player ...
Choose anything you like:
I'm not a programmer - I don't even understand half of what is written below.. I can't choose or implement any of the suggestions below - I haven't seen the visual results from what is written below... Above I provided visual video tests (links to videos), how this optimization works, how it works visually - and what results in performance... - Can you show the same visual example of an alternative method - with the same results, both visually and in terms of performance???
The "fix" changes game visual appearance in comparison with original, as well as playing experience (you tweaked static objects visibility, but what if NPC is hiding behind a bush which is disappeared?). I think this is the main thing Xottab is fighting against.
To be honest, I didn't even think about that. :D
My main concern was new argument Fmatrix* pTransform added to add_* functions. It shouldn't be there and it's being dereferenced while being nullptr. (and it doesn't crash, really strange)
My main concern was new argument
Fmatrix* pTransformadded toadd_*functions. It shouldn't be there and it's being dereferenced while beingnullptr. (and it doesn't crash, really strange)
Oh, by the way about this - can there be suggestions on how to change the code differently? Try to test it and see the code...
Closing this for now. Hopefully, we can see some renderer optimizations by @vTurbine soon :)))