Fallout 4 0.311

[FiftyTifty]

HI Boris,

I know that you have said that the Fallout 4 engine is difficult to work with, but is there any chance you could look into occlusion culling?

From what I understand Fallout 4 includes precalculated occlusion data for almost every static object in the game, no need to do it in real time. The problem is that Bethesda's actual culling seems really bad, you can stand right up against a wall and nothing on the other side is culled, even though none of it is visible. The further you get away from walls the less they cull, too, even if what's behind them is not visible.

I think that performance in the laggiest parts of the game, like the city, could be fixed with better occlusion culling, but I understand that it might not be possible or worth your effort.

This was brought up before. Since D3D 11's draw calls execute twice as fast as D3D 9's, it costs as much CPU time to draw an object, as it would to calculate (dynamically) if the object should be culled.

[ENBSeries]

Giggily
Occlusion culling must be done inside engine, any attempts to implement it "outside" are slow and buggy. And as FiftyTifty said, it's not an easy and need various hierarchy based algorithms to improve performance instead of just waste it. Without source code it's impossible.

[Giggily]

This was brought up before. Since D3D 11's draw calls execute twice as fast as D3D 9's, it costs as much CPU time to draw an object, as it would to calculate (dynamically) if the object should be culled.

Fallout 4 includes precalculated visibility graphs based on NIFs, which are stored in .UVD files, so there shouldn't be any dynamic calculation happening. The problem is that either the visibility graphs are very bad, or Bethesda's way of using the visibility graphs is bad.

.

Giggily
Occlusion culling must be done inside engine, any attempts to implement it "outside" are slow and buggy. And as FiftyTifty said, it's not an easy and need various hierarchy based algorithms to improve performance instead of just waste it. Without source code it's impossible.

That's too bad, I wish that you were working on their engine instead of Bethesda.

[kingeric1992]

*edit

[PulseR HD]

hi you probably already know this but noticed a weird blurry bug in the distance when using extremely low value of any of the fog parameters i thought it was a bug with the depth of field so i turn it off but the problem still persist i dont know if this is a bug with the way the fog was made or if its the enbs



q1 can you add water and skin controls that would be sick
q2 are only vertial fate and distance fate coded or is my game broken

[ENBSeries]

It's Bethesda games exclusive feature, not the bug of the mod.

q1 can you add water and skin controls that would be sick

Can't answer yet, even water takes lot of time.

q2 are only vertial fate and distance fate coded or is my game broken

All parameters listed in editor do works

[SMB92]

This was brought up before. Since D3D 11's draw calls execute twice as fast as D3D 9's, it costs as much CPU time to draw an object, as it would to calculate (dynamically) if the object should be culled.

Fallout 4 includes precalculated visibility graphs based on NIFs, which are stored in .UVD files, so there shouldn't be any dynamic calculation happening. The problem is that either the visibility graphs are very bad, or Bethesda's way of using the visibility graphs is bad.

.

Giggily
Occlusion culling must be done inside engine, any attempts to implement it "outside" are slow and buggy. And as FiftyTifty said, it's not an easy and need various hierarchy based algorithms to improve performance instead of just waste it. Without source code it's impossible.

That's too bad, I wish that you were working on their engine instead of Bethesda.

There is dynamic Vis apparently, Bethesda mentions some objects loaded in without regenerating get looked at by the system as well but not calaculated optimally. In CK you get 2 options to regen Vis, one just for Vis and one for precombined Vis. Obviously the latter looks only at precommed meshes, and in fact you can just gen that without doing the former option just fine (pointless the other way around though)

I'm also convinced Beth only uses 1 UVD at a time in game, for the relevant 3x3 grid your in. In real world tests, this explains why I see more performance gain in juat precombining meshes then both passes of Vis combined. Not to say the gain isn't there though. This could also explain how they could have dynamic culling at all without destroying performance altogether, but on the contrary i am more inclined to think its the application of planes at generation that does this rather than dynamic calculation.

[FiftyTifty]

Did a bit of poking around with users on Anandtech, and a couple...Interesting things were found.

Nvidia's Flex, even when deactivated on a system with an AMD GPU, seems to be taking up a significant amount of CPU time.



Using fast DDR4 (3000Mhz vs 2400Mhz) added a solid 8fps in Diamond City, on an i5 6600k. With 2400Mhz, 49fps. With 3000Mhz, 57fps. But 2600Mhz with an i7 7700k nets 67fps at Diamond City. With equally fast RAM that was used with the i5, we'd probably get a framerate in the mid-70s or low 80s.

Also got scores for Corvega the top of corvega, including draw call count and framerate. Thread's here: https://forums.anandtech.com/threads/ry ... 467/page-2

Ryzen R7's not giving too good a show. Performs a bit slower than a 6600k at the same clocks, when using similarly spec'd RAM at Corvega. They perform the same in Diamond City. Really want to see a user try out the save files with only one CCX active. Should give a big uplift, as the CCX penalty is horrific.

[tapioks]

Hi Boris,

I know you have not been working on ENB very much these days, no problem. I did want to ask, though, if you might have any plans of adding Point Lighting controls for to ENB for Fallout 4 at some point?

[ENBSeries]

No idea, i don't remember anything about F4. And i'm working very hard on the mod actually.