[Blade of Agony] Before and after screens | p184

[Graf Zahl]

You got a major, major GPU performance problem there. It is very obvious that your graphics card cannot keep up with the stuff it gets sent. I just had a look at a graphics card benchmarking site and the card you have is equivalent to a lower mid-level card like the Geforce 8600 from 12 years ago. I had such a thing from 2007 to 2012 and this had massive performance issues on wide open maps, like Hellcore's "Hobbs End Horror" with fps rates around 20. On the Geforce 550Ti I got afterward that map runs with 160 fps from the most problematic locations (obviously also on a faster computer.) I guess your system is roughly comparable to the one I had back then.

What do you get when you run with '-glversion 2'? That will disable the shaders which on such slow hardware might actually help. As a target for optimization such slow hardware won't do much good, though. The problems you fix will never appear on faster hardware.

[Wiw]

No - what causes it to run so sluggishly is the team's obsession for detail over playability and frame rate. Whether a system can handle it or not - they don't care. And sorry, I am going to be blunt here -

If they spent half as much time going over "gameplay do's and don't's" as they do bragging over their linedef counts, I think the mod would be a whole lot better for it in the end.

Portals don't destroy a scene. Portals + 20,000 linedefs and sprites on a single screen, do. In the end, this just is not worth it. It looks pretty, but it's not fun to play, and not just because it runs like ass on anything made before the year 2050. Oh, whoops, that's a few decades into the future!

All effort is being focused on the visual aspects of it, but literally none is being made toward the things that really matter: what the player finds fun and engaging, as well as running with at least 30 FPS on an average system that GZDoom runs on. I think the team really needs to realize that it's okay to sacrifice visual quality for the other two things. It would do something that's taken such a monumental effort, as this clearly has, some real justice, and ensure that none of that effort goes to waste.

I hate to say it, but I agree. I know you guys want to push the boundaries of what GZDoom can do, but don't you think you've pushed it a bit too far? Things worked a lot better before the tree sprites were replaced with models, for a start! Although I suppose splitting the maps further would help, would it not?

[RockstarRaccoon]

I know you guys want to push the boundaries of what GZDoom can do, but don't you think you've pushed it a bit too far?

There is a fine line between pushing the boundaries and simply exceeding engine limitations. And I'm pretty sure, after a few discussions in here, the md3 models aren't the problem, though the resolution of their textures and their poly count might be...

[Ozymandias81]

As a target for optimization such slow hardware won't do much good, though. The problems you fix will never appear on faster hardware.

How so since my playtests/fixes have always improved performance for all of us from the Team?
Did you had the time to test the old TITLEMAP with this improved one? There we have always the same issue, portals and models (which I tweaked with NOINTERACTIVE flag), but I got significant improvements overall.
Obviously removing shaders on my end would help, but what could use there some optimization imho on BoA are Fog actors probably.

[Nash]

the md3 models aren't the problem, though the resolution of their textures and their poly count might be...

Not quite true. The overdraw from the transparent parts on leaf textures actually cause a noticable performance dip on even my GTX 960. Even in my own project with much, much lower poly trees using lower res leave textures (128x128).

The overdraw situation worsens when SSAO is turned on, even at Low setting.

Goes without saying that the BoA trees just murder my framerate. :(

[Graf Zahl]

As a target for optimization such slow hardware won't do much good, though. The problems you fix will never appear on faster hardware.

How so since my playtests/fixes have always improved performance for all of us from the Team?
Did you had the time to test the old TITLEMAP with this improved one? There we have always the same issue, portals and models (which I tweaked with NOINTERACTIVE flag), but I got significant improvements overall.
Obviously removing shaders on my end would help, but what could use there some optimization imho on BoA are Fog actors probably.

Hard to tell. Your problems were entireyl on the GPU side, but there everything works without hiccups for me. Removing the trees making an improvement is not surprising as this actually removes quite a bit of data to be processed. But I cannot see how moving the portals changes things. For that to have an effect it'd have to increase the amount of processed geometry by a very significant margin, and I cannot see that.

[Ozymandias81]

Goes without saying that the BoA trees just murder my framerate.

Even if you set rendering distance (on ENH. Options) at 2048, like I do?

BTW skins used for trees on BoA are all 128x128, only a couple are 128x256 (set of leaves) and only 2 are 2048x2048, which we should check and probably reduce at 512x512. On that skybox sector there were 300+ trees scaled.

[Graf Zahl]

Texture size doesn't really matter here. How many vertices do these tree models have?

[Kinsie]

On that skybox sector there were 300+ trees scaled.

Without having grabbed the latest devbuild to check out the carnage for myself: How far from the camera are they, how many of them are models and how many of them could you get away with turning into sprites with no obvious loss in visual quality due to distance?

[Graf Zahl]

In a skybox? Possibly all of them. Don't forget that they will always be looked at from the same position so the sprites' flatness won't really come into play here.

[Nash]

Could probably take it a step further and even compose simple linedef textures made out of trees so that you won't have to actor-spam the skybox.

[Graf Zahl]

Indeed. That'd definitely reduce processing further.

[Kinsie]

Briefly looking at C3M3 in the latest build straight from Github with notarget turned on...

It looks like all the tree actors in the skybox are the same actors as in the playable area, using the same models, just scaled down to 0.1 in the map editor. This means that every tiny tree in the background is a full 3D model with 1440 triangles (in the case of Tree3). That's probably a bit inefficient when a two-triangle billboard can have much the same effect.

The area outside of the starting building, standing next to the staircase down into the cellar or basement or whatever, cuts my FPS down to ~30fps. This is on a powerful machine (Ryzen 5 1600, GTX 1070) that can eat max-settings Doom 2016 for lunch with room for dessert. It tends to clear up once I reach the bridge, but that still isn't a good sign. It dips right back down once I reach the camp and turn around to go back.

Going down the river and past the mines, my FPS drops to 12-16 upon leaving the river. What are you maniacs doing?

The town itself varies between 20-50fps depending on what direction you're looking, which I suspect is due to the lack of one-sided lines (I've committed this sin before...)

[Graf Zahl]

Going down the river and past the mines, my FPS drops to 12-16 upon leaving the river. What are you maniacs doing?

That's the one portal far in the back. Apparently your system is a bit slower than mine. I got 17 fps there in a previous iteration of the map with a weaker graphics card. With my current Geforce 1060 it's at 26-27 fps when emerging from the river. When I disable the portal it goes up to 30 fps. Near the start building, the staircase into the cellar is also a portal. It doesn't make my system choke but having a portal here in a relatively open scene is not good.

Still not good.

Regarding the trees in the skybox, I only can ask: What were they thinking? Why is it necessary to use scaled down high polygon models there? At some point even on good hardware the shader pipelines will be saturated and if each tree is 1000+ vertices, all those 300 or so trees require processing 300000 vertices, where 1200 would suffice if this were sprites...

You know, I have a lot of respect for Tormentor's mapping skills - but at some point it needs to be paired with an awareness of available resources to produce something good.

[Kinsie]

Apparently your system is a bit slower than mine.

Probably. That or I haven't configured my Ryzen drivers properly or something. Modern computers is hard.