Field of View - Performance Impact

[OptimusShepard]

@vladislavbelov, @Angen

As I'm not the pro in graphics programming I want to share my, I think, interesting observations with you.
Normally only the objects the user could see should be rendered. So nearly only the field of view should be interesting (with some exceptions because of shadows, reflections etc).
As I recognized that some big battles, which aren't in this field of view (only near to it), have a big impact to the performance, I decided to make some tests.
In the following pictures you can see, that the area of performance impact (I would guess the area of the renderer) is minimum doubled to the field of view. I guess minimizing this area could have a big performance increase to the game.
In the following pictures you can see (on the mini map) a big blue dot, that's the 500 test units. You can also see the field of view in different orientations to this dot. The map size is chosen normal. As you can see on the FPS display in the right upper corner, I made this screenshots at the borders to this (renderer?) area. Especially in the front of the field of view there is a huge offset to the are of performance impact.

[Stan`]

To see what is actually rendered you need to tick the lock cull camera options. If you tilt the camera you will see that more is rendered. if it's low enough, it will render a straight line through the entire map.

[OptimusShepard]

Did you meant this Engine.GameView_SetLockCullcameraEnabled(true)?

I've tested it with this command again, but as you can see in the following screenshot, the units (I have them tabbed to show them) are not in the shown render area. I had nearly 30 FPS. If I pushed the field of view a little bit more to the bottom I got 60 FPS. So what is going on there?

[Stan`]

7 minutes ago, OptimusShepard said:

Engine.GameView_SetLockCullcameraEnabled(true)

Yes

10 minutes ago, OptimusShepard said:

I've tested it with this command again, but as you can see in the following screenshot, the units (I have them tabbed to show them) are not in the shown render area. I had nearly 30 FPS. If I pushed the field of view a little bit more to the bottom I got 60 FPS. So what is going on there?

Well the tabbing should be culled but its not currently there is a patch for it. i believe.

I guess maybe somethings is computed depending on the orientation? Could be sound maybe

 

[OptimusShepard]

40 minutes ago, Stan` said:

I guess maybe somethings is computed depending on the orientation? Could be sound maybe

Does the sound uses draw calls and model tris?

I've found the hotkey F11 to show the draw calls. What I see, is looking really strange to me.

If the units were in the render area I got ~14.000 draw calls and ~4,4 million model tris.

If the units were "near" to the render area, as in the shown screenshots above,  I got ~6-8.000 draw calls and ~2,1 million tris.

If I left this area I got ~470 draw calls and ~84.000 model tris.

So it seems to me that there is a area around the render area where a greater part of the unit models gets rendered anyway.

My chosen settings were Anatolian plateau, one player, normal size, 500 units. Can someone confirm this?

Edited April 25, 2020 by OptimusShepard

[asterix]

1 hour ago, OptimusShepard said:

Did you meant this Engine.GameView_SetLockCullcameraEnabled(true)?

I've tested it with this command again, but as you can see in the following screenshot, the units (I have them tabbed to show them) are not in the shown render area. I had nearly 30 FPS. If I pushed the field of view a little bit more to the bottom I got 60 FPS. So what is going on there?

Well this could help a little https://code.wildfiregames.com/D1437  about culling I only found commited stuff  so I do not know also since on linux some threads could be named https://code.wildfiregames.com/D2479 it could be figured out where it leads. Also at last fosdem @vladislavbelov had presentation  about graphics. 

 

maybe this can also help https://code.wildfiregames.com/D1493 plus patches about Lod https://code.wildfiregames.com/D1926, https://code.wildfiregames.com/D2440 and low poly to high poly modes

Edited April 25, 2020 by asterix

[OptimusShepard]

Just now, asterix said:

Well this could help a little https://code.wildfiregames.com/D1437  about culling I only found commited stuff  so I do not know also since on linux some threads could be named https://code.wildfiregames.com/D2479 it could be figured out where it leads. Also at last fosdem @vladislavbelov had presentation  about graphics. 

 

maybe this can also help https://code.wildfiregames.com/D1493 plus patches about Lod https://code.wildfiregames.com/D1926, https://code.wildfiregames.com/D2440 and low poly to high poly modes

@asterix I think you misunderstood my intention

As it seems to me that there is a greater area outside the render area where models get rendered, my question is, if this is necessary, or a misbehaviour/bug, which could be solved to increase the game performance.

Edited April 25, 2020 by OptimusShepard

[Stan`]

@OptimusShepard was it SVN or A23B ?

[OptimusShepard]

19 minutes ago, Stan` said:

@OptimusShepard was it SVN or A23B ?

Both

[Stan`]

 Can confirm it's because the vision bounding box might be a bit too big.

[OptimusShepard]

26 minutes ago, Stan` said:

Can confirm it's because the vision bounding box might be a bit too big.

So its easy to fix? 

[Silier]

1 hour ago, Stan` said:

Can confirm it's because the vision bounding box might be a bit too big.

i dont know too much about that graphic rendering part. 

 

might be because shadows, it needs to be bigger to render shadows of entities out from vision box so one will see them.

also that's case for water reflection rendering

but looks like normal camera view could throw it away

[vladislavbelov]

Yes, it happens because of bounding boxes bigger than actual models. If even a small piece (like 1cmx1cmx1cm) of a bounding box is visible then the whole model is going to be rendered.

Possible solution is to use occlusion queries, but it doesn't fit good for old hardware/drivers or low-poly models.

Another problem is that it's still possible to see all these models, from a hill for a example. So it might make sense to make angle limits smaller (mostly vertical cameras).

Also you might use developer panel (Alt + D) to enable/disable culling and debug camera bounds instead of calling JS functions.

[OptimusShepard]

So, I tested, as @vladislavbelov said, with the developer panel. As @Angen mentioned, the draw calls I had seen were used for shadow rendering.  When the models are inside this render area, they are rendered to be displayed. Also, any model that is inside the red/blue box is rendered for shadows and reflections.

Depending on the orientation of the camera/render area, the shadow/reflection boxes (red/blue) may fit less or better into this area. The first image shows a relatively good fit of this area with the boxes. So almost every shadow that is rendered could be seen by the player.

The second and third images show the worst case. Here, the fit between the render area and the shadow render box has a bad adjustment. This means that many shadows are rendered that the player can't see, so it's a waste.

Optimizing the shadow renderer therefore means to achieve the best case of matching the boxes to the render area. I don't know if there are plans or if this has already been abandoned, but my thought is, is it possible to rotate the red box along the longitudinal axis? Since the longitudinal axis does not change its direction/orientation, the direction of the shadows will not change. So, the direction of the rotation around the longitudinal axis should depend on the orientation of the camera.

(Please ask/comment if I have not explained something clearly or misunderstood something.)

[vladislavbelov]

2 hours ago, OptimusShepard said:

Optimizing the shadow renderer therefore means to achieve the best case of matching the boxes to the render area. I don't know if there are plans or if this has already been abandoned, but my thought is, is it possible to rotate the red box along the longitudinal axis? Since the longitudinal axis does not change its direction/orientation, the direction of the shadows will not change. So, the direction of the rotation around the longitudinal axis should depend on the orientation of the camera.

There is a fixed shadows feature, that I committed a couple of months ago (see default.cfg). It decreases the shadow box, also in future it's going to be used for a more precise shadow rendering.

[OptimusShepard]

Nice feature

So you planend more than one, but smaller shadow boxes to have only shadows on the rendered area?

[vladislavbelov]

7 minutes ago, OptimusShepard said:

So you planend more than one, but smaller shadow boxes to have only shadows on the rendered area?

Not with absolute precision, because it's pretty complicated task, but I plan to reduce number of renderered in shadow map objects that don't cast shadows in the visible view.

[OptimusShepard]

Thank you for this interesting information’s. I think this thread could be closed now.

[Stan`]

Locked on your request