Slowness with many actors and possible mitigations

Discuss anything ZDoom-related that doesn't fall into one of the other categories.
SuaveSteve
Posts: 76
Joined: Sat Jul 05, 2014 7:38 am

Slowness with many actors and possible mitigations

Post by SuaveSteve »

Hi everyone.

I have some concerns and questions over how GZDoom is handling many actors. Some background: I'm using a lot (~4000) of actors in one map that serve a purely cosmetic and not even physical purpose (they have +NOINTERACTION). But I'm starting to perceive a slowness in that map, going from the 200FPS I use to have to 80-100FPS. This may not seem like a big deal, but I'm worried about people with graphics cards slower than mine.

I made a very simple test (DOOM2, UDMF) so that we all have a reference. It's just two classes, on that has partial transparency and one that has either fully transparent or opaque pixels. At first, I thought it may be that the majority of things in my map are using sprites with partial transparency, but this seems to not be the issue

https://www.dropbox.com/s/khyyab2716j0u ... 2.pk7?dl=0

What concerns me in this test is that it does not seem to matter which way you are looking. FPS does not change. Try standing right up to and looking at a wall. Try the two simple structures in the map that both block line of sight to your surroundings. The think time does not seem to be anywhere close to the frame time, so am I right in saying it's purely a rendering issue?

Some thoughts:

Would it be feasible for GZD to frustum cull just actors? I know this has been discussed before, but that included geometry. I'm wondering if culling actors out of rendering would help tremendously in my case.

Would it be feasible to implement draw distance for actors? How about a distance to have them skipped over entirely, as if not there (no "thinking")?

I don't mind making threads for this in the request forum, I just want to initiate some discussion first.
User avatar
Matt
Posts: 9696
Joined: Sun Jan 04, 2004 5:37 pm
Preferred Pronouns: They/Them
Operating System Version (Optional): Debian Bullseye
Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia
Contact:

Re: Slowness with many actors and possible mitigations

Post by Matt »

I'm using a lot (~4000) of actors in one map that serve a purely cosmetic and not even physical purpose
I think that's the problem right there...


EDIT: to elaborate, keep in mind that every single actor has to be processed in a way that, for reasons that go to really fundamental ways in which the Doom engine works, cannot rely on any modern multiprocessing - the program has to go through all the applicable calculations and checks for each actor, one at a time, in sequence, every tick, using no more than one of your CPU cores for everything. This means that your actor count is a major performance bottleneck.
Last edited by Matt on Fri Jan 11, 2019 5:39 pm, edited 2 times in total.
User avatar
TDRR
Posts: 815
Joined: Sun Mar 11, 2018 4:15 pm
Operating System Version (Optional): Manjaro/Win 8.1
Graphics Processor: Intel (Modern GZDoom)
Location: Venezuela

Re: Slowness with many actors and possible mitigations

Post by TDRR »

drfrag implemented sprite draw distance in ZDoomLE and i think ZDoom32, in the case of ZDoom32 it's limited to the software renderer.

I don't think it's going to help much, as many actors really start to cause a strain in the CPU. Try using midtextures as decorative sprites if the player won't get close to them.
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:

Re: Slowness with many actors and possible mitigations

Post by drfrag »

I ported dpJudas sprite and wall cull code to ZDoom, and he was kind enough to help in the process. It's only for the software renderer, wall cull is far more effective. That's why LZDoom is faster on crappy hardware, besides D3D (main reason) the cull options are enabled by default with reasonable values. Big difference with maps such as Planisphere 2.

On the actors, their number must be limited by the mods. What would you do? Add an option to destroy certain actors automatically after a while? And how?
SuaveSteve
Posts: 76
Joined: Sat Jul 05, 2014 7:38 am

Re: Slowness with many actors and possible mitigations

Post by SuaveSteve »

Okay, so I decided to play a bit around with implementing view distance myself in ZScript.

It was pretty simple, just using CheckProximity. Without any random delays to checking, you get terrible performance. With a delay (like 35 tics), you get a stutter each time each actor does the check. This is all to be expected, I guess. The best method I found is that by using a delay and ZDoom's regular random first state delay, thus the checks are staggered over time; it was okay, but not by much and the pop in was noticeable. Increasing the check distance or decreasing the delay just increases average think time per frame and so diminishes returns.

So that didn't work out.

This is a real bummer cause I find actors to be extremely useful for lots of things. For example, I made one that will spawn others in a sector to a configurable density, https://imgur.com/a/vQ3Fd4o

Using mid-textures is okay, but you lose out on many features. With actors, I can make my grass have a random size, a random rotation if I'm using WALLSPRITE, they are more reusable and flexible. You also don't have to flip the texture on the opposite side of the linedef if using an actor with WALLSPRITE.

I know nothing of graphics programming, but would it not be possible to give actors a renderDistance, then pass this on to the GPUs LOD mechanism to get such a thing for "free"?

In the meantime, I will try to keep my usage down, but I hope the situation improves. I have some other ideas, but I'd prefer to just, you know, map :)
Blue Shadow
Posts: 4949
Joined: Sun Nov 14, 2010 12:59 am

Re: Slowness with many actors and possible mitigations

Post by Blue Shadow »

There is [wiki=Actor_properties#DistanceCheck]this[/wiki], but I don't know if it'll help or not.
User avatar
Caligari87
Admin
Posts: 6174
Joined: Thu Feb 26, 2004 3:02 pm
Preferred Pronouns: He/Him
Contact:

Re: Slowness with many actors and possible mitigations

Post by Caligari87 »

Before chasing rendering checks, it may be worth it to determine if its rendering or thinking taking the time. I'd be willing to bet in cases with tons of actors, it's a think time issue. Making the actor invisible doesn't help that because the engine still needs to iterate over it and have it do all think checks (even with +NOINTERACTION, though that helps cut a lot of stuff), and adding a distance or LoS check is likely making the problem worse.

8-)
gramps
Posts: 300
Joined: Thu Oct 18, 2018 2:16 pm

Re: Slowness with many actors and possible mitigations

Post by gramps »

Should be easy enough to check, set renderstyle=none and see what happens to fps.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Slowness with many actors and possible mitigations

Post by Graf Zahl »

Blue Shadow wrote:There is [wiki=Actor_properties#DistanceCheck]this[/wiki], but I don't know if it'll help or not.
If you ultimately decide to do distance culling, USE THIS!
Doing these checks in script code is ultimately self-defeating and will massively increase processing time. Using the distance check is virtually free, it has been designed to be done as a very cheap pre-rendering query of the given CVAR. And it lets the user alter the value depending on the system, it's being used on.
User avatar
Apeirogon
Posts: 1605
Joined: Mon Jun 12, 2017 12:57 am

Re: Slowness with many actors and possible mitigations

Post by Apeirogon »

About rendering of map geometry...
It is possible to decrease amount of sectors gzdoom must draw, without breaking up the BSP tree, but this require some additions to gzdoom. Minimum, link to sector gzdoom currently want to/do render and some way to make lines..."unrederable", so that any sectors behind that line, relative to player, were excluded from BSP tree iteration.
With it, some script can check what sector gzdoom wants to draw, then count sectors area and/or amount of lines, and if some of this numbers become higher than X just make lines of next sector(s) "unrenderable". Or even intelligently find all most distant lines and dont draw anything behind it, make several previous sectors sink in "distance renderer fog", etc.

But this makes some quirks.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Slowness with many actors and possible mitigations

Post by Graf Zahl »

Let's just phrase it this way: If you need such features it is time to rethink your map design.
For sprites and models it is understandable, but if you want to create maps open anf large enough that the renderer chokes on them, something is wrong...
User avatar
Apeirogon
Posts: 1605
Joined: Mon Jun 12, 2017 12:57 am

Re: Slowness with many actors and possible mitigations

Post by Apeirogon »

For map like this I dont think any rethink, tautology, will bring anything useful.
https://www.youtube.com/watch?v=C5f-VKEq0JA
I mean, sometimes map need some "dummy" space just for the sake of significance/atmosphere, to show BOOM BADABOOM and some scripted cutscene-animation-etc somewhere there.
User avatar
Kinsie
Posts: 7399
Joined: Fri Oct 22, 2004 9:22 am
Graphics Processor: nVidia with Vulkan support
Location: MAP33
Contact:

Re: Slowness with many actors and possible mitigations

Post by Kinsie »

Apeirogon wrote:For map like this I dont think any rethink, tautology, will bring anything useful.
https://www.youtube.com/watch?v=C5f-VKEq0JA
I mean, sometimes map need some "dummy" space just for the sake of significance/atmosphere, to show BOOM BADABOOM and some scripted cutscene-animation-etc somewhere there.
I can think of a good variety of ways to handle this specific scene in more performance-sane ways using a variety of smoke and mirrors (ie. transitioning from a cutscene boat to a gameplay-area boat during a massive explosion-triggered camera shake) and consideration during the level design of the gameplay area (ie. having low enough ceilings in at least one area to allow for the usage of render-culling one-sided lines).

In addition, I believe one of Enjay's maps was able to do a big impressive hectic beach landing sequence without having to render the entire map at once, and this was with way worse tools and considerably fewer engine features than we have now.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Slowness with many actors and possible mitigations

Post by Graf Zahl »

Kinsie wrote: In addition, I believe one of Enjay's maps was able to do a big impressive hectic beach landing sequence without having to render the entire map at once, and this was with way worse tools and considerably fewer engine features than we have now.

That was "Operation Overlord" and it used the classic way to do this stuff. Make the higher parts of the map void space and lay it all out so that the player never gets high enough to see how this is done.
Of course back in the day this map was quite taxing to hardware of its vintage. These days a good system doesn't break a sweat on it.

The map was also fairly low detail overall and quite efficient in making it look like there's more than there really is. I think this is an art lost on most of those who feel to be in need of such crutches.
User avatar
Apeirogon
Posts: 1605
Joined: Mon Jun 12, 2017 12:57 am

Re: Slowness with many actors and possible mitigations

Post by Apeirogon »

Thats...not exactly what I meant.
Now gzdoom slowly, but surely, moves from "port of a nearly forgotten game from old as dinosaur computer era" to "brand new GPL game engine with materials and shaders". So more and more modders would be needed to have more control over the engine to make things, like the ones i mentioned.

Or Im wrong and gdoom dont move to/cross "free game engine" line?
Post Reply

Return to “General”