if you are talking RED engine and this game exclusively , you might be right.
But in general , I am not convinced you are.
This game reminds me of ages past when this was so common no one payed attention to it.
Nope. It's every graphical engine ever created.
All engines have always used some form of it and will continue to for the conceivably far future. Yes, it will become less and less noticeable as new tricks and techniques are developed, but it will still be there.
_______________
Big Ol' Honkin' Esplenation:
Certain games, especially non-open-world games (those with individually loaded "levels") can limit what's actually shown on-screen at any moment, inherently limiting the assets to numbers that can be simultaneously rendered and drawn for a given scene. (Think the original Dark Souls games or the way Call of Duty levels are designed.) Compartmentalized loading for specific areas which are small enough that all assets are rendered once that separated area loads. But it will not be a contiguous open world -- it will be smaller regions separated by loading screens of some sort -- although such games often cleverly hide the loading with cutscenes, elevator rides, or squeezing through narrow places.
Any seamless open-world design will need to stream assets in based on what's called for at any instant, and it's impossible to load all assets in such games into the RAM simultaneously, as that would require something in the tune hundreds or even a >thousand GB of RAM and VRAM. To actually
draw all of those assets permanently at all times would take millions or even billions of terraflops per second.
As the distance from the camera increases, the number of assets in a scene increases exponentially. So, not only would I need each and every asset to be loaded into RAM at the same time, but I would need the processing power to render and draw each
instance of each asset at the same time.
So, take the example of a player character moving down the road with trees on both sides. A scene like this:
Let's pretend I have only one tree model, so I only need to load that one mesh and texture package into RAM. The engine can then copy-paste that tree model on both sides of the road, and if the road is mostly flat, that might mean drawing 2,000 copies of that tree. As the distance from the camera increases, more and more trees are needed because more will fit in the camera's cone of vision. So if the tree model consists of, say, 3,000 triangles (about average for most modern games with lots of detail,) that's 6,000,000 calculations per
frame that needs to be done. And modern GPUs are expected to generate between 60-120 frames every
second. So that's 360,000,000-720,000,000 calculations per second that the GPU has to process for just the 2,000 instances of that one tree model.
But, of course, I won't have just one tree model. I'll likely be using a procedural system with potentially hundreds of different models for variety. And of course, I need to draw in all the other 3D assets: bushes, clusters of grass, stumps, boulders and rocks, terrain features, animals, instects, blowing leaves, etc, etc, etc. Each of those things are individual assets with their own individual mesh and texture packages that need to be loaded into RAM at the same time in order to appear in the game. Things get full fast. (And this is just for
graphical processing -- I still need to reserve system resources for audio, input, GUI, game mechanics, AI pathfinding, and on and on. You know...all the stuff that makes a
game happen.)
So, it's not possible to load absolutely everything all at once.
_______________
I now have a few choices:
1.) Loading areas. I dump all the stuff for one spot out of RAM and put all the new stuff I need for the next area in RAM. This will likely mean that I can avoid pop-in altogether in most scenes, as it's just that one area that's loaded. But I'll need to have loading times between areas.
2.) Limit far field camera visibility. I make my game foggy or dark or something. Or I keep it in corridors with walls or something that always obstruct the view at a certain distance. That means I can make near-field more detailed and FPS higher overall.
3.) Asset streaming. This is what has been used in big, open worlds since
Spyro the Dragon first debuted the technique in the 1990s. I draw stuff in the far distance, but I decrease the amount of detail that is rendered and drawn on-screen the further away from the camera it gets. Hence, there will be "levels of detail" (LoD) for various objects, and certain objects that will only be streamed in at a given distance from the camera. This means the engine dynamically loads and unloads stuff from RAM on-the-fly based on what's needed for any scene at any point, but it has to work within the limitations of the operating environment. It's now a balancing act between available RAM, VRAM, CPU cycles available, GPU cycles available, and desired framerate.
