Hello Developers - Does our Game world also disappear around my view

Probably totally boring question for Developers.

But maybe interesting for us Gamers.

If you click on this Reddit Link you will see how interesting we Non Developers Customers find a simple thing like getting told that the Game World Renders during the Time we move our Camera?

https://www.reddit.com/r/gaming/comments/65zr3h/heres_whats_happening_in_horizon_zero_dawn_every/

So i actually got curious and would like to know - is this the Same at SotA?
Is behind the direction my Avatar looks - nothing - empty Space?

Or the other way - if i am fast enough to look over a edge of a mountain i might see how a animation starts?

https://gfycat.com/HarshFirstGallowaycow


Kind regards

Myrcello

 

Or paraphrased: "If a tree falls in the woods and no-one is there to see it, does it still render?"

I think SOTA works this way too, maybe not exactly but it you walk into a busy scene with a slow computer you can see objects pop in and out of existence. Not sure if items behind your FOV are excluded but there is some of this going on.

 

Of course... when you talk about something being "rendered" that just means its drawn on a graphics device. There are many angles to view many spots in the game scene, and your computer has to draw then when you get there. But it doesn't mean the stuff that isn't rendered doesn't exist to the game. If an NPC is on a schedule and he's behind you, he's still changing positions in the game world behind you even though he's not rendered.

But ,anyway, you can see what the reddit thread is talking about by the fact that if you change camera angles, often your FPS will change. So, for instance, on my machine, I have problems doing combat rolls with low FPS because the game doesn't recognize my double taps. I'll change my camera angle to something where there is less rendered, my FPS will go up, and I can do the combat rolls.

 

Among other things it does, Unity renders (draws) what you see every frame. It renders what is in the camera's field of view. The field of view is an arc that extends in front of the camera where the point of the arc is the camera, the arc is defined to sweep x degrees and extends for y units. So for example the field of view can be defined as an arc 60 degrees wide , 30'degrees on each side of the camera's 0 degrees, from-30'to 30 degrees. Then it can extend for 1000 units out. Any object that falls in this arc is rendered that frame. As you move about, objects move in and out of the arc. The old objects that aren't in the arc still exist, just not drawn. So that when you swing around they appear. Those objects that appear on the screen are considered visible and those that don't are considered invisible. As objects become visible and invisible they can be manipulated; for example they can be made active and inactive (or enabled and disabled). Enabled objects are touched each frame and considered for drawing, but aren't drawn if the aren't in the cameras field of view. Disabled objects don't take any time frame time, and aren't considered for drawing.

So while there can be active, enabled objects not in the direction that the camera is pointing and the field of view arc that it sees from the fulcrum, they need not be included in the wha tisndrawn in the screen. So yes there may be objects behind you, to both sides of, or even in front of you that may not be drawn on the screen and that you don't see. And these hidden, indrawn objects can be sucking valuable computing cycles and time that affect your frame rate.

As to why things pop in and out, that is a combination of how the lod is handled as things enter the field of view of the camera and the frame rate and other things.

In reality a lot things happen, and this is a sort of simplified version of what goes on behind the scenes in drawing what you see on the screen.

 

l

A lot goes into calculating frames per seconds and when things get drawn than just what goes on the screen. This link https://docs.unity3d.com/Manual/ExecutionOrder.html shows a high level view of what goes on during 1 frame in Unity. It goes through each of these phases for every frame. If you have a frame rate of 10fps then this cycle has been completed 10 times that second. If you have 30 fps then the cycle completed 30'times during that second.

Part of that cycle is used to determine what should be drawn on the screen during that frame. Part of that cycle may be used to determine things like what the NYC are doing. And parts of th cycle may be used to send data back and forth to port's game servers.

Bringing it back, yes objects can exist outside what is drawn on the screen. But what you see on the screen is only what is in the camera's field of view, that arc that extends from the camera's centre point.

As to the combat roll issue, or single clicking, double clicking, or other kinds of input; it's about time, the time that is spent on a single frame of execution. Low frames rates cause the input routines to execute far apart, so things like double clicks may not be considered double clicks, because of the time gap. Things like double taps, may not be thought of as double taps because of the time between the input routine's discovery of the first tap and the second tap. And the time it takes to render the graphics can impact the time spent in each frame. So the number of objects, even if not rendered on screen, that are considered for rendering can impact when the game executes the input routines and is able to sense your input and can act on it. Input code is executed when a specific keyword is executed in the script, so many things need to come together for the proper execution of a double tap or click. The more time the code can be executed per second, the more input can be sensed and things like double taps can then be considered as double taps instead of being considered as two single taps.

And now we get into other topics on how graphic designrensring can influence frame execution, such as culling and batching as well as visibility and invisibility and also enabled and diaabledmobjects and other tricks can be used to speed up the rendering pipeline. This is an art and science unto itself.

 

We do things like this quite often to improve performance - for example NPC AI only works if a player is nearby.

 

@jiirc

Yea, its mainly the rendering causing the low FPS and lag on input polling, though. If I change the resolution or lower the graphics setting, double clicks, double taps will be recognized. Usually.

 

I can't even get to the point where I can use double commands... I could at first but then it worsened...

@Lum the Mad, that is nice to have such improvements and will be needed anyways for the long term and save server bandwidth cost... but the real culprit is the shader routines and they way they are hooked up in unity.

I did many tests and it requires adjustement from both ends... other end of course in a visually oriented game like we have its going to require alot of spriting and blurring work to get to a satisfactory level... not sure we have ressources for that ? :/

When you can't change the shaders themselves, its the only option, and one of the most boring things to do

If it was me I'd pay the 20k extra to have a licence and do custom shaders.

 

I'm not really sure what you're asking but only objects that intersect the view frustum are actually rendered. This is true of every 3D game.