I heard that the amount of portals “on the screen” affect the framerate. I can’t see how this could be true, since a visibility list is precalculated, not calculated on the fly (where it might be an issue). Is this at all true?
Note: Actual framerate, not compile times and that.
Portals aren’t loaded by the game, and therefore have no effect on the framerate.
However, the complexity of the map’s BSP tree can affect framerate somewhat.
y
That’s what I thought.
However, the complexity of the map’s BSP tree can affect framerate somewhat.
How much?
Negligible. Surface counts, vertex counts, triangle counts, and shader passes affect rendering more.
y
Portals are polygons created by the BSP process between BSP leaves. They are used for vis calculation. They are not used by the game or any other part of the compile process.
y
That’s what I thought.
Quote:
However, the complexity of the map’s BSP tree can affect framerate somewhat.
How much?
I too thought it was negligible performance hit, until I managed to make a map that thought otherwise. A map I released for RTCW (bankraid) had a problem with the BSP tree being too complicated. The polycount/shader coutn etc were fine. People with a good cpu but poor graphics card could play the level fine. People with a great graphics card but slow cpu were complainign about terrible frame rates.
I’ll admit the BSP tree was overly complex, but I made the mistake of thinking it wasn’t that big a deal (because I’d followed the guidelines for poly counts, hadn’r used many shaders or multitexturing) but it was.
Like all things when mapping - never take it for granted. If you can reduce your BSPO complexity, do it. Don’t just ignore it because it means more work.
just a quick (hopefully) question to make sure i’m clear on this.
the bsp complexity is reduced by making stuff detail right?
Making stuff detail is one way of reducing the complexity of the .bsp. I generally us a very large block size in my worldspawn or no default splits at all (_blocksize 0) and then create splits only where I think they would be useful. In many cases, I think, mappers do lots of hinting that is just fine but the default splits caused by the blocksize make further splits that are not necessarily expected, creating a boatload of “tiny portals”
RC
Sometimes tiny portals are better than big ones. Remember, when the game is running, each leaf node has a table of otehr node sit can potentially see and must check against all of them. If you create large portals, then one portal could potentially see hundreds, perhaps even thousands of other portals making the visibility searches slower. The trick is to find a balance of size and complexity rather than just making enormours portals. Increasing block size is fine for maps with little structural brushwork and large open areas, but turning them off altogether is definitely not recommended.
And I repeat:
Portals aren’t loaded by the game, and therefore have no effect on the framerate.
Walking the BSP tree and vis table is extremely fast. That’s one benefit of a BSP tree.
Small portals, large portals, it doesn’t matter one iota in-game.
y