Slowness with many actors and possible mitigations

Discuss anything ZDoom-related that doesn't fall into one of the other categories.

Slowness with many actors and possible mitigations

Postby SuaveSteve » Fri Jan 11, 2019 11:07 am

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.
SuaveSteve
 
Joined: 05 Jul 2014

Re: Slowness with many actors and possible mitigations

Postby Matt » Fri Jan 11, 2019 11:47 am

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 6:39 pm, edited 2 times in total.
User avatar
Matt
Putting the XD into *xdeath since 2007
 
 
 
Joined: 04 Jan 2004
Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia

Re: Slowness with many actors and possible mitigations

Postby TDRR » Fri Jan 11, 2019 4:38 pm

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
TDRR
putting jelly on this hot dog
 
Joined: 11 Mar 2018
Location: The present

Re: Slowness with many actors and possible mitigations

Postby drfrag » Sat Jan 12, 2019 7:38 am

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?
User avatar
drfrag
I.R developer, I.R smart
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain

Re: Slowness with many actors and possible mitigations

Postby SuaveSteve » Sat Jan 12, 2019 1:29 pm

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 :)
SuaveSteve
 
Joined: 05 Jul 2014

Re: Slowness with many actors and possible mitigations

Postby Blue Shadow » Sat Jan 12, 2019 2:45 pm

There is this, but I don't know if it'll help or not.
User avatar
Blue Shadow
 
Joined: 14 Nov 2010

Re: Slowness with many actors and possible mitigations

Postby Caligari87 » Sat Jan 12, 2019 7:22 pm

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-)
User avatar
Caligari87
I'm just here for the community
User Accounts Assistant
 
Joined: 26 Feb 2004
Location: Salt Lake City, Utah, USA
Discord: Caligari87#3089

Re: Slowness with many actors and possible mitigations

Postby gramps » Sat Jan 12, 2019 7:31 pm

Should be easy enough to check, set renderstyle=none and see what happens to fps.
gramps
 
Joined: 18 Oct 2018

Re: Slowness with many actors and possible mitigations

Postby Graf Zahl » Mon Jan 14, 2019 7:24 am

Blue Shadow wrote:There is this, 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
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Slowness with many actors and possible mitigations

Postby Apeirogon » Mon Jan 14, 2019 8:45 am

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.
Apeirogon
I have a strange sense of humour
 
Joined: 12 Jun 2017

Re: Slowness with many actors and possible mitigations

Postby Graf Zahl » Mon Jan 14, 2019 9:14 am

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
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Slowness with many actors and possible mitigations

Postby Apeirogon » Mon Jan 14, 2019 3:42 pm

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.
Apeirogon
I have a strange sense of humour
 
Joined: 12 Jun 2017

Re: Slowness with many actors and possible mitigations

Postby Kinsie » Tue Jan 15, 2019 2:24 am

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
Kinsie
A Concept Utterly Obsolete
 
Joined: 22 Oct 2004
Location: MAP33
Discord: Find Me...
Twitch ID: thekinsie

Re: Slowness with many actors and possible mitigations

Postby Graf Zahl » Tue Jan 15, 2019 3:33 am

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
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Slowness with many actors and possible mitigations

Postby Apeirogon » Wed Jan 16, 2019 8:10 am

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?
Apeirogon
I have a strange sense of humour
 
Joined: 12 Jun 2017

Next

Return to General

Who is online

Users browsing this forum: Bing [Bot], wildweasel and 3 guests