Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
snapshot

3D Floors and Performance.

Recommended Posts

Hi again.

 

I've been working on a large openworld level in my spare time but before I continue I want to ask how many 3D Floors can GZDoom handle before FPS starts to drop ?, what are the factors that can cause the FPS to drop, and should I even use this method or use teleports instead ? Thanks in advance.

Edited by dmg_64 : Misspelled word on title

Share this post


Link to post

I don't know about performance, but depending on what you're doing you should consider using portals. The more complex the environment becomes, the more attractive portals get. Of course you can mix both features, i.e. simple 3D platforms are more easily done with 3D floors than with portals.

Share this post


Link to post

I would like to create some buildings with at least 2 floors and allow players to shoot through windows, Portals seem limited :/ .

 

Edit : nevermind looks like it's possible with portals, Thanks for the tip :)

 

Edit #2: woop, another trouble, can't have two portals above each other (for the windows)

Edited by dmg_64

Share this post


Link to post

Whether you use 3D floors or portals in your buildings will very much depend on the size and complexity of your map. Although 3D floors are notorious for causing performance to drop substantially if used excessively or if too many are being rendered at once, there's no clear way of telling how many it takes to slow the game down because everyone's computer is different. Some people may not see any noticeable performance drop while others may experience lots of lag from only seeing a couple of 3D floors.

 

If you intend to use 3D floors in your map, try to use them sparingly or use them only for creating the second floor of the building. Otherwise, if the buildings are supposed to have lots of detail (furniture, rugs, lighting, etc.), it might be better to use sector portals instead, as boris suggested above.

Share this post


Link to post

In one map I converted from Doom 64, I used 3D floors to create these connecting beams and these floating blocks between the beams. For the floating blocks, there's a middle pillar under them and the surrounding edge. Using 3D floors for both the part above the pillar and the surrounding edge produced some stuttering and a tiny drop in FPS. When I removed the 3D floor from above the pillars and instead raised the pillar to meet with the surrounding edge, it went away. That might be hard to follow but the point was: too many 3D floors in one area created mini-lag for me.

Share this post


Link to post
22 hours ago, dmg_64 said:

Hi again.

 

I've been working on a large openworld level in my spare time but before I continue I want to ask how many 3D Floors can GZDoom handle before FPS starts to drop ?, what are the factors that can cause the FPS to drop, and should I even use this method or use teleports instead ? Thanks in advance.

I've found that using textures designed for the mid sidedef (Grates, fences, ect) will procude much more fps lag than solid 3d floors. But it really depends on the computer really.

Share this post


Link to post
20 hours ago, dmg_64 said:

Portals seem limited :/

 

The only limitation (EE) portals have is the available mapping space in your editor of choice. Moving polyobject-portals are currently still a bit iffy.

 

For "open world" levels your best strategy is to approach the level as a cake. Each layer represents 128-192+ units of height, and you try to fit your map geometry in such a way that it makes the most use of these 'default' portal layers. The more layers you use, the smaller your level will have to be since you're using up the available mapping space. For details (mostly in buildings) you can use additional portals. For furniture-like details, you can use edge portals to great effect.

 

Only geometry that requires lots of different 3D heights (such as 3D stairs) are much easier to set up with 3D Floors.

Share this post


Link to post

I played around with that a bit, and apparently 3D floors can cause a lot of overdraw. If you check out the following video (at 19:15), you can see that the bridge support beam in the back is fully rendered, just to be overdrawn by the walkable part.

 

 

So it's probably save to say that the more 3D floors you have visible, the slower it will become. This also seems to be mostly a problem in the software renderer, which makes sense considering how hardware rendering works. Using truecolor in software mode makes it slower, too (which, again, makes sense).

 

I made a small test map (see attachment) with 512 3D floors and a lowering wall, slowly revealing them. And you can see the FPS drop the more become visible:

 

 

30 minutes ago, Mordeth said:

 

The only limitation (EE) portals have is the available mapping space in your editor of choice.

But you can't have two different portals on one line, can you? That's what you'd need to place two windows right above each other.

many3dfloors.zip

Share this post


Link to post
5 minutes ago, boris said:

But you can't have two different portals on one line, can you? That's what you'd need to place two windows right above each other.

 

Why not? Not sure what you mean by 'windows', though.

Share this post


Link to post
9 minutes ago, Mordeth said:

 

Not sure what you mean by 'windows', though.

He means "Building windows", AFAIK you can't have two Portal effects in the same linedef.

Share this post


Link to post

Making a few 3D floors does not cause any problems, going berserk like Blade of Agony did and make buildings' roofs out of 3D floors will cause a problem, specially because if you have no one-sided linedefs for the building's walls, the engine will render everything behind it. Since you are going for a building, make sure you always have one-sided linedefs preventing the player from looking from one window into another, this will significantly reduce the performance issues. Also make sure you merge all the similar sectors. 
Or instead of making linedef portals, consider using sector portals (the upper sector and lower sector things).

Share this post


Link to post

You can't put different portals on the same linedef; but you can put a floor/ceiling portal on the whole sector, so that you get two different linedefs stacked vertically in-game, and then these two different linedefs that are one above the other can each have their own portal.

 

While portals and 3D floors can both be used largely for the same things; they are each optimal for different purposes.

Share this post


Link to post
3 hours ago, dmg_64 said:

He means "Building windows", AFAIK you can't have two Portal effects in the same linedef.

Um, yeah, you can build a skyscraper with each floor having windows right above or below the one in the other plane. And you can attach different portals to the lower, middle and/or upper part of a linedef (using edge portals).

 

Disclaimer: talking strictly about Eternity's original implementation. I don't know how zdoom does things.

 

Quote

Since you are going for a building, make sure you always have one-sided linedefs preventing the player from looking from one window into another

 

This is solid advice. Use the regular level geometry to your advantage. This is another advantage of portals: it's actual level geometry, with all the usual rules, while 3D Floors are placed afterwards in a sector already rendered (the overdraw issue mentioned above in the video link). But like said before: both have their uses and strength/weaknesses in a given situation.

Share this post


Link to post

Sergeant Mark is spot on about using proper level geometry. Unlike later engines, Doom has no manual way of telling the engine not to draw certain parts of the map. You have to use proper one sided linedefs to do it.

 

With that in mind, if what you're trying to create is (for example) a building with two floors, sector portals are the way to go: that way the "floor" of a building can be its own proper room off at the side with proper one sided linedefs around. I'd then use line portals positioned around the edge of the outside of your building to simulate windows.

Share this post


Link to post

It is true that software rendering and 3D floors do not mix well. I do not use software rendering and can confirm what has been said before: Under OpenGL even a modestly large amount of 3D floors will not cause much of a problem, provided you have up to date computing hardware. On that even a map like the Inca HQ from Enjay's Burghead mod easily runs at 60 fps without hiccups and that is probably the most extreme use of 3D floors I have ever seen that is not encumbered by other mapping sins that slow it down.

 

Regarding portals it should never be forgotten that the price per portal is a lot steeper than the price per 3D floor

 

Share this post


Link to post

Another way to fake this is to create copies of your building many times over and then make the outside area identical from outside the windows view, then simply raise or lower your "floor" to simulate if you are higher or lower. Then use a silent teleport or something to move the player (or ACS) between each copy of the building or each "floor" if you will. That would give you no FPS problems whatsoever. This would also allow you to give each floor much more detail, since you don't need to do 3D floors on everything.

Share this post


Link to post

I already thought about that, It won't allow players to shoot through windows or allow players near the building to see who are behind the windows, also projectiles and hitscans don't get teleported.

Share this post


Link to post

The physical size of the 3D floors is the biggest performance issue. That's because of overdraw, as Boris says. Overdraw is particularly nasty, as it wreaks havoc on the computer's memory caches. Writing the pixels once the way Doom draws is bad enough. But re-writing them beats the cache to death, as it tries to always match main memory. When you overdraw, the cache becomes invalidated, and it's up to the hardware as to when it clears and refills the cache. But the overdraw continues to invalidate the cache over and over for a long enough time to cause multiple flushes and refills of the same memory representation. There are CPU instructions to minimize this, but using them requires an intimate knowledge of the memory system, the cache system, and the write patterns of the renderer. It's a lot of work, and it is different for each resolution, somewhat.

 

The smaller the 3Dfloor is, the less overdraw that occurs, and the better the performance is. This is, at least true for the software renderer.

 

Share this post


Link to post

By the way, and to relativize a bit, other things that cause overdraw in Doom's software rendering engine include sprites (all of them) and mid textures on two-sided lines.

 

On the rendering video posted by Boris, at around 7:55, there's a scene from Frozen Time. From about 8:55 to 12:12, it just draws the midtextures for a vanilla bridge. I can guarantee you a 3D floor bridge would have been a lot faster, as well as better-looking. :p

Share this post


Link to post

IMO the biggest problem with overdraw isn't cache, but rather that 100% overdraw means twice as much drawn, meaning twice as many instructions needs to be executed. This includes executing drawers, column/span setup, texture selection, light, etc.

Share this post


Link to post
1 hour ago, dpJudas said:

IMO the biggest problem with overdraw isn't cache, but rather that 100% overdraw means twice as much drawn, meaning twice as many instructions needs to be executed. This includes executing drawers, column/span setup, texture selection, light, etc.

Yes. It's actually more than twice as much, because of the insane effect overdraw has on the cache. If you play a hectic game, and happen to kill a bunch of monsters in one spot, and walk up to the pile of corpses, the frame rate takes a big hit - more than expected. I've even seen a bunch of +1 armors overlayed cause a significant frame rate hit - a lot more than I expected. It's a bizarre situation that defies reason. It has something to do with dirty cache refresh delay vs. the penalty when the cache is busy vs. the speed the renderer overwrites the same pixel. I don't claim to fully understand it, but I've seen it.

 

I wonder if some type of 3D BSP, or some other technique could prevent a lot of that overdraw. You'd have to horizontally split up walls, or something. Sounds complicated. :(

Share this post


Link to post

Is there no way to tell the engine to limit how many 3D Floors can be rendered at once, Like change draw distance ?

Share this post


Link to post

Oh, of course you could do that, but you'd have to do it in a way that's smart and then you can run into a problem where attempting to find out if the 3D floor can be skipped safely will take more time than just rendering it.

 

To go back to the rendering video, look at the 3D floor drawing scene. Notice the order in which the 3D floors are drawn? Imagine you skip the last one (which is the main part of the bridge) and how that would look like.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×