optimizing VIS but FPS stays the same

(]UBC[ McNite) #1

The VIS could be improved quite a bit in The River, so I am constantly working on my structural brushes, cutting here, merging there, reducing the number of structural surfaces in the map.
This is the VIS of a compile about a week ago:

--- Vis ---
Loading E:\ETmap\etmain\maps\mp_theriver_2nd.bsp
Loading E:\ETmap\etmain\maps\mp_theriver_2nd.prt
  1281 portalclusters
  3356 numportals
  4138 numfaces
  6712 active portals
   400 hint portals
visdatasize:215216

--- BasePortalVis (6712) ---
0...1...2...3...4...5...6...7...8...9... (5)
      6 average number of passages per leaf
     16 MB required passage memory

--- CreatePassages (6712) ---
0...1...2...3...4...5...6...7...8...9... (9)

--- PassagePortalFlow (6712) ---
0...1...2...3...4...5...6...7...8...9... (205)
creating leaf vis...
cluster    0 :  281 visible
Total visible clusters: 447500
Average clusters visible: 349
Writing E:\ETmap\etmain\maps\mp_theriver_2nd.bsp
Wrote 9.7 MB (10179256 bytes)
      240 seconds elapsed

Not so cool you d say? Yepp, I knew there was still lots of potential in my structurals.
So after quite some work on them, this is what I had today :

--- Vis ---
Loading E:\ETmap\etmain\maps\mp_theriver_2nd.bsp
Loading E:\ETmap\etmain\maps\mp_theriver_2nd.prt
  1057 portalclusters
  2659 numportals
  3430 numfaces
  5318 active portals
   360 hint portals
visdatasize:143760

--- BasePortalVis (5318) ---
0...1...2...3...4...5...6...7...8...9... (3)
      5 average number of passages per leaf
      9 MB required passage memory

--- CreatePassages (5318) ---
0...1...2...3...4...5...6...7...8...9... (5)

--- PassagePortalFlow (5318) ---
0...1...2...3...4...5...6...7...8...9... (96)
creating leaf vis...
cluster    0 :  237 visible
Total visible clusters: 334929
Average clusters visible: 316
Writing E:\ETmap\etmain\maps\mp_theriver_2nd.bsp
Wrote 9.4 MB (9818008 bytes)
      119 seconds elapsed

Nice, isn’t it? Visdatasize from 215.000 down to 145.000, duration of VIS stage down to 50% only by re-doing structurals, looking at where to cut them and where to merge (and yea I enable show blocks so I know where i can cut them).

Then I tried something out: I moved the whole map in z-axis direction. This had the effect that I could lower the sky to 3072 while not getting a whole level of new blocks (1024x1024x1024) at the bottom. All in all I got quite an improvement with regard to VIS according to the logfiles:

--- Vis ---
Loading E:\ETmap\etmain\maps\mp_theriver_2nd.bsp
Loading E:\ETmap\etmain\maps\mp_theriver_2nd.prt
   961 portalclusters
  2370 numportals
  3421 numfaces
  4740 active portals
   114 hint portals
visdatasize:123016

--- BasePortalVis (4740) ---
0...1...2...3...4...5...6...7...8...9... (3)
      5 average number of passages per leaf
      8 MB required passage memory

--- CreatePassages (4740) ---
0...1...2...3...4...5...6...7...8...9... (4)

--- PassagePortalFlow (4740) ---
0...1...2...3...4...5...6...7...8...9... (58)
creating leaf vis...
cluster    0 :  246 visible
Total visible clusters: 258197
Average clusters visible: 268
Writing E:\ETmap\etmain\maps\mp_theriver_2nd.bsp
Wrote 9.4 MB (9820060 bytes)
       79 seconds elapsed

Looks like serious improvement, doesn’t it?
(The reduction of hint portals is because in the first verison I have a large horizontal layer of hint in the castle area. This completely separates the inner yard from the 2 outer areas west and east from the yard. By moving the whole map I don’t need these hints anymore because the 2048-blockline where the blocks cut the leafs is exactly where the horizontal hint layer created the leaf-cut.)

I mean, down from 316 to 268 average clusters visible you d expect your fps to get a bit of a boost don’t you?

Problem is: I didn’t get ANY recognizable improvement in FPS since the compile shown in the first logfile :banghead: :banghead: :banghead:
In fact after the last compile in some places in the castle-yard the FPS got worse (ok I know why, its not such a biggie).
But WTF no improvement in the whole map? After cutting down visdatasize by about 45% and reducing average clusters visible 349 to 268?
I always test with the same cfg, so there has been no change…

Comments anyone?

(blushing_bride) #2

perhaps ive misunderstood your post but making your vis data more efficient wont necessarily cut the number of triangles and shaders on screen and they’re the thing that effect fps most (or at leasts thats the impression ive always had).

(The Wanderer) #3

reducing the vis size wont affect your fps…only your compile time and the final size of the bsp.
Imporving the vis splits will affect your fps but that has nothing to do with the vis size.

(SCDS_reyalP) #4

That isn’t always true. In some cases it can provide a quite significant gain. In others, it can be no gain at all.

Imporving the vis splits will affect your fps but that has nothing to do with the vis size.

???
Depending on your definition of ‘improve’ I suppose.

]UBC[ McNite:
In any case, the reduced vis size gives you faster compile times, which makes testing/tuning easier. It also leaves you some room to add hints or other structure where you need it, without huge compile times. You should use the portal viewer in radiant, along with r_showtris 2 and r_rspeeds 1 in game to further tune things. Learn to use the hint, subtlehint and skip shaders for maximum control. You may find that reducing your block size and putting hints where you need them helps things out.

(]UBC[ McNite) #5

maybe I m wrong but:

less visible surfaces of structurals = less leafnodes = simpler VIS structure = less effort for the engine while playing?

Or is the thing I should be after with hints and blocking to get less leaf nodes into my “sight” (showtris 2) and thus reducing the number of tris the gfx card has to calculate?
If it is that I d say a lot of VIS and hint tutorials don’t get the right message over… i always understood that the simpler the VIS structure the better.
Simple VIS structure = as few leafnodes as possible + short “looking” distances (in means of how many leafnodes can possibly be seen from the one I stand in)

If I should reduce visible tris (visible = showtris 2), then I could win quite a bit by making the VIS-structure more complicated and putting in some hints to get additional leafnodes that can’t be seen from everywhere. I d cut out some areas from vision by that. This would be trading less average tris visible for more average clusters visible…

@ Wanderer: how do you improve vis splits then? The reduction of visdatasize is only a side effect of me trying to simplify my VIS structure by having less splits.

(]UBC[ McNite) #6

Ok, maybe i need to go 1 step back and ask a simple question:

Is what showtris 2 shows me exactly working like visible leafnodes/ VIS tree?
Using showtris 2 in my map gives me the impression that this assumption is wrong because I can see tris in places that never is in leafnodes that can be seen from the ones I stand in.

So what is the basic way of reducing tris count then? (apart from not having many tris at all in the map :smiley: )

Btw I don’t use the prt-viewer cuz I can’t recognise anything in that one. I use -debugportals in the BSP stage to get an impression of my VIS splits and leafnodes.

Maybe this is right here too: when I used worldspawn fog in the map I reduced the average visible clusters seriously too, but FPS went down in the critical areas from 40 to 25 (I guess that s because the gfx engine has to calculate the fog all the time). Critical areas are those where you can see a lot of the map.

(The Wanderer) #7

[quote=]UBC[ McNite]
less visible surfaces of structurals = less leafnodes = simpler VIS structure = less effort for the engine while playing?
[/quote]
Just because you have less leaf nodes doen’t mean the engine is rendering less surfaces…quite the contrary. Imagine a map with the minimum number of leafs possible…1 .
That means all the brushes in the map are detail (except for the skybox ) and the whole map is just one giant leaf. The vis structure is extremely simple and the size very small, but the perfomance would be horrible because at any point in the map every object in the view is rendered all the way to the map border.
By “improving” the vis splits I mean place your structurals and hints such that at any point in the map the player should see as little “extra” triangles (basically triangles that are behind other objects in his view and should not be visible) as possible. In much simpler terms that means try to match the triangles shown with r_showtris 2 as much as possible with the ones shown in r_showtris 1.
What I’m trying to say is that it’s not the number of leafs that you see that makes the difference but the ammount of visible geometry in each leaf.

@SCDS_reyalP It’s my understanding that the vis table is just a bit array showing which leafs are visible from every leaf. Access time for the array should change very little with the change in size, unless you’re going through extreme cases, in which case page faults etc. might make some small diference.
Of course i’ve never actually gone through the code or anything …this is mostly stuff i’ve read in forums etc. so please correct me if I’m wrong.

(]UBC[ McNite) #8

Here s a pic of one of the critical areas:

Of course long views over the whole map are the sucky ones. Within the areas where the fighting will be or even from where you normally run around in the open terrain and shoot at ppl the FPS usually is 50-70 in. The critical spots are few and not where you usually camp :cool: anyway I d like to improve this.

@ Wanderer: agreed on showtris 2 = showtris 1 would be perfect. So what is blocking tris not directly visible from getting calculated in showtris 2? If I get you right its placing hints or natural splits caused by structural in a way not too many leafnodes can possibly be seen from the leafnode I am standing in, right? And, yea I m not going to make my map all detail :smiley:

(The Wanderer) #9

well…you can look at it that way if it helps you but i think that’s missleading.
You’re trying to reduce the NUMBER of leafs visible and what i’m saying is you should try to reduce the SIZE of the visible leafs at any one point. If you can reduce the number of the leafs visible WITHOUT changing their size then yes you’re improving your vis splits, but if you eliminated some leafs but in doing so you increased the size of the remaining visible leafs…then you really didn’t gain that much. In the end all that matters is the tris count.

(]UBC[ McNite) #10

Thx Wanderer. Seems that I simplified my VIS table, improved compile-performance in the VIS stage but messed up my tris count. Of course leafs got bigger in the process :bump:

(Gringo Starr) #11

Like wanderer said, in the end it is tris that will have the greatest effect on FPS. It’s good to know how to optimize, but that should be done after reaching an acceptable level of blockage, followed by testing to make sure it didn’t break anything. The visdata size of the RTCW map I’m working on is 1,300,000, requires 96 MB, and takes over an hour to run vis. BTW, nice map! :slight_smile: I could take a look at the brushwork to see how optimized that is, if you want. I won’t steal anything from it, or give it to anyone, I just enjoy nit picking brushwork :). gringostarr@the-wildwest.com

BTW, you could try compiling with -notjunc in the BSP phase. Depending on your brushwork, it can save quite a few tris. Rarely have I seen sparklies as a result of not fixing t-junctions.

(]UBC[ McNite) #12

@ Gringo: let me just finish brushwork, then you can have a look. While we ll do the final testing, I ll do the improving of tris and I guess I can do with feedback of some pro’s then :smiley:

(SCDS_reyalP) #13

Based on direct experience, overly complex bsp can a significant impact on performance. This is common sense… vis data and extra leafs that doesn’t help you reduce your r_speeds simply pollutes your cache and increases the working set touched by each frame. This is especially true in open maps. Not only is the complex vis data not reducing your r_speeds, each leafs list of visible leafs is huge. I didn’t expect this to be as significant as it was, until I started helping someone who had map that was very bad in this respect.

However, it seems ]UBC[ McNite has neglected to keep track of his r_speeds as he simplified the bsp, which is usually not a good idea. What you want to do is to have the minimal structural complexity, while also having the minimal r_speeds. When in doubt, favor r_speeds. To really tune things, you need to use the portal viewer and r_showtris 2 and make sure that your structure is actually doing what you want.

Correct use of hint, subtlehint and skip can help you out there. You need to really understand why a given set of triangles is being drawn or not. It is easy to do something, expect it to work, and when it doesn’t, just dismiss it as ‘the compiler is messing up, because I know I did it right’ The compiler very rarely messes up. If something is being drawn that you don’t expect, you have failed to understand the compiler and engines rules. Go back to the editor and portal view until you understand why you were wrong.

A point that many people are not aware of:
q3map2 with -meta batches groups of triangles with the same shader together, into ‘metasurfaces’. In general, this is a good thing, because it renders more efficiently. However, the entire metasurface will be rendered if any one of its triangles is in view. If you have large area of one shader, this can have a negative impact on performance. You can control this either with func_groups, or by putting in some other textures at key points. Terrain is also compiled into metasurfaces, but you have little control of this.

For the technically inclined, the following may give a better idea of how these things work:
http://www.gametutorials.com/Tutorials/OpenGL/Quake3Format.htm
http://www.planetquake.com/spog/stuff/technical.html

(G0-Gerbil) #14

http://www.gametutorials.com/Tutorials/OpenGL/Quake3Format.htm
Never did like that article since it’s just a rip from http://graphics.stanford.edu/~kekoa/q3/.
I know credits the guy for his huge help, but there’s a difference between helping a lot and copying verbatim :slight_smile:

(]UBC[ McNite) #15

BTW, you could try compiling with -notjunc in the BSP phase. Depending on your brushwork, it can save quite a few tris. Rarely have I seen sparklies as a result of not fixing t-junctions.

Tried that today. Gives me about 2-4 FPS more in the bad places, but adds a lot of sparklies (especially where I got large brushes touching).

(SCDS_reyalP) #16

In general, automatic t-junction generation exists for a reason. Sometimes you can rework your geometry to produce less verts, but beware that upping the brush count to do so can also have negative effects.

@gerbil: ahh, I didn’t realize. I’ll link the original in the future.

(Loffy) #17

Hi!
Great map!
The low fps is due to the r_speed’s verts 30000+. I would go to that section in the screenshot (see above), in the editor, and start deleting small brushes. Lots of them. I would start with the ones in the shadows (I don’t really need details in dark areas) and then proceed until I got verts 20-25000.
Drakir and I got some low fps problems when we made North Pole, which is a fairly open terrain map. Our solution was to delete tons of detail from the buildings and inside the buildings.
A sidenote: Is it only me, but doesn’t fps vary between compiles, sometimes - although you haven’t actually done any fps-improving? I mean, I can have 50-60 fps in an outdoor area - then I recompile, for some reason, and suddenly the same area has a whooping 80-90 fps. It’s like the compiler is having a “bad hair day” (i.e. “a bad compile day”), when I get those 50-60 fps.
:slight_smile:
// Loffy

(SCDS_reyalP) #18

Identical maps should compile identically. Given identical inputs, the compiler will almost certainly produce identical outputs. However, just loading and saving a map changes it, because the editor does like to change the brush and plane order around every save. This can have some effect, but I wouldn’t expect it to be significant most of the time. Minor changes to structure or even texturing can also occasionally have significant results.

The other thing that can happen is your machine suddenly producing much lower FPS for some reason. This can happen from having the editor open, or some other program that grabbed resources and perhaps neglected to release them.

(G0-Gerbil) #19

Also, particularly in outside areas where VIS portals can get a bit crazy, it’s sometimes possible that being in a slightly different location can produce vastly different FPS - eg 50-60 then a quick tiny sidestep drops to 30 fps.
I doubt that’s yer case Loffy cos you know enough about maps to understand this, but thought I’d mention it for others in case they wonder.

(]UBC[ McNite) #20

Well the tiny sidesteps are well explainable. I go through the map with r_showtris 2 and also use -debugportals in the BSP-stage on exactly the same .map. That way I get a real good idea of where the splits are.
I d say my chance to reduce tris is by consequently separating inner rooms with their detail from the outer areas in a way there will be only very few brushes drawn from inner rooms when you run around in the open.
The spot on the screeny is a real bad place because it draws nearly all open space with all the trees and the whole terrain…

edit: My main mistake was that I thought I had to favor VIS when in doubt… but reyalP said I was wrong about that. Seems like what I got of FPS-improving from simpler VIS table was completely consumed by larger tris count.