Slowness with many actors and possible mitigations

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is OFF
Smilies are ON

Topic review
   

Expand view Topic review: Slowness with many actors and possible mitigations

Re: Slowness with many actors and possible mitigations

by Graf Zahl » Tue Feb 19, 2019 8:48 am

SuaveSteve wrote: So actors that can not be seen by the player and are within the view frustum are still taking rendering time. Which means GZDoom has no occlusion culling or its implementation isn't that good.
The big time waster here isn't processing an actor for rendering but hitting a cache miss for most of them. Even for the most trivial of checks the actor's data needs to be read which most likely involves one cache miss. After that all the rest becomes mostly irrelevant. As long as an actor is linked to a sector that gets rendered it needs to be looked at at least once.

Re: Slowness with many actors and possible mitigations

by gramps » Mon Feb 18, 2019 9:23 pm

Ah, so the think time was a red herring, and it's rendering causing the slowness as you suspected.

Thanks for following up on this, this is useful stuff to know.

Re: Slowness with many actors and possible mitigations

by SuaveSteve » Mon Feb 18, 2019 9:14 am

gramps wrote:Still would like to hear what happened to FPS with lots of things vs. lots of not-rendered things vs. not lots of things.

OP: did you get a chance to test this out?
I'm very certain with actors that don't do much thinking, it's a rendering thing. I did a test with setting bInvisible in batches:

I made an actor I call VisLinker* that makes a list of other actors within some radius (filtered by another list I provide) and hides/unhides them depending on distance to nearest player.

Look at this video:

https://my.mixtape.moe/hvjsak.m4v

You should notice two things: FPS going up as I move back, and the groups disappearing in the distance.

I only place the VisLinkers on one side of the map so the difference in FPS could be noticed.

But those are all in view, you may say, well... I've already started using these on a real map where you can't see all these cosmetic actors at once and I've already noticed an improvement on ~20FPS in some areas.

So actors that can not be seen by the player and are within the view frustum are still taking rendering time. Which means GZDoom has no occlusion culling or its implementation isn't that good.

I suppose another way to do this would be to segment your map by hand and turn the actors invisible/visible as the player passes segments, but then that sounds awful similar to what other engines like Doom 3 already do with visportals.

*Latest, slightly different to what is in vid, code if anyone is interested: https://pastebin.com/5pgFLHZ1

Re: Slowness with many actors and possible mitigations

by Marisa the Magician » Thu Jan 17, 2019 4:23 pm

Excuse me but in here there are people who know more than me about those engines. I'm only specialized in Unreal Engine 1 and 1.5. You give me too much credit.

And I can tell you that UE1 also has trouble with slowness (or even crashing) caused by too many actors (in fact, slowness tends to happen with actor counts in the hundreds, not thousands). The engine is single threaded, runs at a much higher tick rate (a variable one, even) and it has even more stuff to deal with for just one actor than GZDoom.

Re: Slowness with many actors and possible mitigations

by gramps » Thu Jan 17, 2019 3:49 pm

Still would like to hear what happened to FPS with lots of things vs. lots of not-rendered things vs. not lots of things.

OP: did you get a chance to test this out?

Re: Slowness with many actors and possible mitigations

by Apeirogon » Thu Jan 17, 2019 5:55 am

Nash wrote:
Apeirogon wrote: Or Im wrong and gdoom dont move to/cross "free game engine" line?
Yes, you're wrong. GZDoom is meant to, and will always be a Doom engine. At some point, a line is drawn.

You want something more, you should consider Unity or Unreal Engine 4. :)
Kinsie wrote:GZDoom is powerful and amazing and my friend, but it's still Doom under the surface and for some things you need to work with that in mind, otherwise you're basically going to spend all of your time trying to smash square-shaped pegs into round-shaped holes and getting frustrated.
If you thought that Unreal/Unity dont have some silly restrictions, your wrong. I dont touch it at all, but from my experience from working with other "home made" game engine, (serious sam/dawn of war/half life/disciples/HoMM/etc. engine) Im sure that it have some. But thanks to programmers from Epic/Unity it it contains very few of such restrictions. Most famous "free" game engine after all.
But that question to Marisa, since it only significant person here which know thing or two about it.

What I meant, the only differences of gzdoom from nowadays game engine that it runs only on one core and that the renderer try to render ALL that player POSSIBLE can see, instead if draw all that player ACTUALLY can see. From all other point of view, it generic nowadays game engine, since it have materials, shaders, Vulkan API (in near future), models, can runs in windows 10, etc. Or even more, since it have JIT compiler.
So now gzdoom in position "too far to reach, too low to get up" from the point of game engine, in my opinion.

Re: Slowness with many actors and possible mitigations

by Graf Zahl » Thu Jan 17, 2019 2:11 am

Kinsie wrote:otherwise you're basically going to spend all of your time trying to smash square-shaped pegs into round-shaped holes and getting frustrated.
... and you can take that quite literally, considering how the engine performs collision detection of actors... :mrgreen:

Re: Slowness with many actors and possible mitigations

by Nash » Thu Jan 17, 2019 1:54 am

Apeirogon wrote: Or Im wrong and gdoom dont move to/cross "free game engine" line?
Yes, you're wrong. GZDoom is meant to, and will always be a Doom engine. At some point, a line is drawn.

You want something more, you should consider Unity or Unreal Engine 4. :)

Re: Slowness with many actors and possible mitigations

by Kinsie » Thu Jan 17, 2019 1:49 am

GZDoom is powerful and amazing and my friend, but it's still Doom under the surface and for some things you need to work with that in mind, otherwise you're basically going to spend all of your time trying to smash square-shaped pegs into round-shaped holes and getting frustrated.

Re: Slowness with many actors and possible mitigations

by Apeirogon » Wed Jan 16, 2019 7: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?

Re: Slowness with many actors and possible mitigations

by Graf Zahl » Tue Jan 15, 2019 2: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.

Re: Slowness with many actors and possible mitigations

by Kinsie » Tue Jan 15, 2019 1: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.

Re: Slowness with many actors and possible mitigations

by Apeirogon » Mon Jan 14, 2019 2: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.

Re: Slowness with many actors and possible mitigations

by Graf Zahl » Mon Jan 14, 2019 8: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...

Top