Slowness with many actors and possible mitigations
-
- Posts: 76
- Joined: Sat Jul 05, 2014 7:38 am
Slowness with many actors and possible mitigations
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.
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.
- 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
I think that's the problem right there...I'm using a lot (~4000) of actors in one map that serve a purely cosmetic and not even physical purpose
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.
- TDRR
- Posts: 815
- Joined: Sun Mar 11, 2018 4:15 pm
- Preferred Pronouns: He/Him
- Operating System Version (Optional): Debian 12/ Manjaro
- Graphics Processor: nVidia with Vulkan support
- Location: Venezuela
Re: Slowness with many actors and possible mitigations
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.
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.
- 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
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?
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?
-
- Posts: 76
- Joined: Sat Jul 05, 2014 7:38 am
Re: Slowness with many actors and possible mitigations
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
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
-
- Posts: 4949
- Joined: Sun Nov 14, 2010 12:59 am
Re: Slowness with many actors and possible mitigations
There is [wiki=Actor_properties#DistanceCheck]this[/wiki], but I don't know if it'll help or not.
- 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
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.
Re: Slowness with many actors and possible mitigations
Should be easy enough to check, set renderstyle=none and see what happens to fps.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49067
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Slowness with many actors and possible mitigations
If you ultimately decide to do distance culling, USE THIS!Blue Shadow wrote:There is [wiki=Actor_properties#DistanceCheck]this[/wiki], but I don't know if it'll help or not.
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.
Re: Slowness with many actors and possible mitigations
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.
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.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49067
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Slowness with many actors and possible mitigations
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...
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...
Re: Slowness with many actors and possible mitigations
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.
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.
- 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
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).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.
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.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49067
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Slowness with many actors and possible mitigations
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.
Re: Slowness with many actors and possible mitigations
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?
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?