Maps with crap FPS

(bunnibunni) #1

I’d like to know what causes FPS lag on the majority of maps out there.

I never lag on the stock maps. There’s a few maps out there that are done so well I never get FPS lag, but most of them do. I have a great graphics card so I know it’s not my card.

What can map makers do to make there maps not lower our fps so much, and is there any way for those of us who run servers to fix these maps?

I always figured it had to do with too much open space, but even on some with little space it’s horrible fps.

Thanks,

!Slayer!

(psyco_mario) #2

Ah, well, this is quite a bit topic…

Many ways you can increase FPS
1: Caulk - Apply the caulk texture to any unseen faces of a brush
2: Hint brushes
3: Structure/Detail brushes

Here is some great tutorial/guides about it (By our favorite mapper, Marko!)
http://www.gamedesign-online.com/index.php?menu=Tutorials&t=ap
http://www.gamedesign-online.com/index.php?menu=Tutorials&t=bsp

(sodsm live) #3

are you getting this lag when just looking at the map(like in devmap mode) or is it when there are other/lots of players on a network game?

just wondering cuz i’ve got a crap agp GF6600, tired 32bit 3200XP and a measley gig of ram and i haven’t seen a map that slows it down yet. i do get an odd lag spike that happens about once every two minutes but that’s it.

(Loffy) #4

Hallo bunnibunni!
Some cool mapper once said “fps is king”, meaning that a map will not be played if it has fps 25-30. In sum, you are totally right.
I do not knwo what a server admin can do about it on a practical level. The thing you can do is to write to the mapper and tell him about this site (splashdamage.com/forums). We try to help new mappers with fps issues the best we can.
ETQW looks just perfect! Ops, I just had to shout that.
//L.

(kamikazee) #5

The first occurence I can found is posted by Sock: FPS is king :smiley:

(]UBC[ McNite) #6

1: Caulk - Apply the caulk texture to any unseen faces of a brush

This is overrated. If you do
a) clean brushwork and
b) good VIS-blocking,
the FPS you get from caulking is really not worth the effort.

What really makes the difference is:

a good layout of the map that enables you to do effective VIS-blocking.

Check TheRiver II Redux for a good example of how to do nice VIS-blocking even in a large open map (yea i made it :-P). Also there are tutorials out there on that.

(G0-Gerbil) #7

Caulking invisible faces is not over-rated, and should result from the proper workflow anyway - IE you model everything in caulk and then paint the faces you see.

Knowing how I love Marko, I should point out his tutorial 1 is in fact a complete waste of time, and worse than that, would help mappers create slow maps without understanding why.
Area portals are a hack at FPS that fails under most circumstances in multiplayer games and can lead to false FPS readings from the developer (note they are much more efficient in SP games).

Specifically:

  • Areas portals only cull when the door in question is closed.
  • In multiplayer games, there’s a good chance someone else in the game has opened the door, rendering the culling ineffective
  • Your FPS is only as good as it’s worst-case-scenario. In other words, if your FPS is fine with the door closed, but crap with the door open, then you have a problem.

Normal good VISing is your main recourse to decent framerates - specifically structural brushes and your placement of them (along with hint brushes for the adventurous).
Also note your structural hull should be simple, and caulk only (or some other specific caulk-hull texture that isn’t drawn in-game - I know a few mappers use a custom caulk-hull shader for example).

Framerates are really not that hard to make decent, but it helps massively if you understand structural vs detail brushes, and how VIS is calculated. And then, plan your map with VIS planned from the start, it’s a bugger to retrofit.

(]UBC[ McNite) #8

Still… if u do clean brushwork all hidden surfaces will get “deleted” during the compile anyways. So its just not necessary to caulk them.

(G0-Gerbil) #9

Clean is relative.
Two brushes can have their visible faces meet correctly yet their back-faces are not touching meaning they won’t be removed.
Remember that all your textured brushes should be detail, and it’s easy to see why ‘hidden’ faces will still get processed and attempted to be drawn*.

I cannot remember if anyone actually tested to find out if coplanar (but inverted) detail faces are culled at the compile stage - I seem to recall they weren’t (although my memory is not what it should be - if someone could confirm or deny this it would help), which would mean LOTS of extra drawn* but hidden faces.

*By drawn I mean go through the Q3 engine drawing pipeline - obviously they won’t actually ever be visible, since at the very least the faces would fail the Z-buffer test (Q3 engines render front to back for this speed gain), so it’s not a complete speed hit, but it can still have a large effect on framerates.

(G0-Gerbil) #10

After typing the above it occurred to me I should probably just test it :slight_smile:
Yes - coplanar detail faces are culled, which is something at least (and would account for the majority hidden detail faces).

However, it doesn’t account for all circumstances, so it’s still good practice to start caulk, and paint visible faces only, it’s just if you hadn’t done it to start with, going back and doing so won’t give you such a large speed gain.

The bottom line is, if mapping in a certain way results in better framerates, why would you do otherwise?
This particular issue isn’t a case of ‘you need to know XYZ to achieve better framerates’ (which I’ll say that proper structural vs detail + hint brushes is, it’s not easy for beginners to pick up).
It’s simply a case of ‘Do X and you will have better framerates’ - it’s a simple rule you can follow to help your poor little map out.

(SCDS_reyalP) #11

The other thing that often eats frame rate is overly complex collision geometry. This can both affect client frame rates, and in extreme situations cause lag by using all the available CPU on the server. This gets far less attention than clean brushwork and r_speeds, but can be very significant.

When you compile your map, all the drawing geometry is turned into triangles, but the brushes are kept for collision detection (this isn’t just for players, but for detecting where shots hit etc. Even nodraw/nonsolid brushes are kept and tested.) Both triangles and brushes are associated with BSP leafs.

Traces (the function used for collision detection) use the BSP to figure out which leafs they need to interact with, but within each leaf essentially do a linear test against every possible brush. There are early outs, but it is still costly. That means that if you for example, make a complex terrain which is all detail, with a large blocksize, you can get very poor performance because every frame has to look at every brush. While researching this, I made a map where a single player, in a single room with ~12 drawing triangles and ~16000 nodraw/nonsolid brushes brought my athlon 64 3000 down to < 50 fps on the client, and overloaded the CPU on an athlon 1.6 ghz server. The higher the client frame rate (regardless of maxpackets) the more load each client puts on the server. One client getting 333 fps on a ‘bad’ part of oasis used something like 11 percent of available CPU on the above mentioned server.

The lesson from this is that vis is important for more than just keeping triangles from being drawn. It should also be used to isolate complex geometry. However, this is a trade off too, because excess vis data has it’s own cost (I haven’t done detailed measurements, but some tuning I did on someone else’s map showed it to be significant. If you use the 2MB which is the max vis data, that gets touched every frame. Clearly, that will completely thrash your cache and put a big load on memory bandwidth.)

Another lesson is that using models and simple clip brushes can have a big performance gain. If you have complex geometry which isn’t reachable, you should use models.

Finally, maps can be ‘laggy’ on large servers if all the players are in each others PVS a the same time. A 64 player server hits the max rate a lot in this situation, even at the practical limit of 25000.

ps: good to see you again Gerbil!

(]UBC[ McNite) #12

If you have complex geometry which isn’t reachable, you should use models.

I take it you are talking about gamemodels, cuz models get backed into the BSP? And i guess i need clipweapon to clip them so I get a panzer exploding when shooting at them right?
Also I guess even when I use a horizontal clip and have detail brushes above it, so nobody can reach them, they will still be calculated for collision detection, right?

About the resource-limit when playing max_fps 333: I can confirm that. In the last playtest for Warbell I set max_fps 333 for me to check out FPS while playing with 20 players on the map, and i got quite some laggy situations. Switching max_fps back to 76 everything was fine.

(SCDS_reyalP) #13

[quote=]UBC[ McNite]

If you have complex geometry which isn’t reachable, you should use models.

I take it you are talking about gamemodels, cuz models get backed into the BSP?
[/quote]
No (although you could use them if you wanted). misc_model triangles get baked into the bsp, but there are no brushes associated with them. Thats why you need to manually create clip brushes for models (unless you use autoclip, but that would defeat the whole purpose of using models in this case.)

And i guess i need clipweapon to clip them so I get a panzer exploding when shooting at them right?
Also I guess even when I use a horizontal clip and have detail brushes above it, so nobody can reach them, they will still be calculated for collision detection, right?

You would want to use clip geometry that was simpler than the models. How to best do this depends on the situation.

About the resource-limit when playing max_fps 333: I can confirm that. In the last playtest for Warbell I set max_fps 333 for me to check out FPS while playing with 20 players on the map, and i got quite some laggy situations. Switching max_fps back to 76 everything was fine.

There are other things that break down at very high frame rates. If you see an intermittent connection interrupted icon, it is probably one of the other problems.

(DerSaidin) #14

I take it you are talking about gamemodels, cuz models get backed into the BSP? And i guess i need clipweapon to clip them so I get a panzer exploding when shooting at them right?

Models used multiple times should be gamemodels, but if your only using it once then baking it isnt such a bad thing.

Either way I generaly tend to do my own clipping, unless that model is pretty basic and I want it the clipping to be more exact (tree trunks).

(]UBC[ McNite) #15

Autoclipping sux… i always use my own clip brushes.
About using models several times and gamemodels: 10 of the big trees = 60KB BSP size comparing misc_models to misc_gamemodels (only the trees look shit as gamemodels due to bad lighting… they d need a new shader), so that s not really much of saving.

If you see an intermittent connection interrupted icon, it is probably one of the other problems.

Nope, its just a flickering/very fast slideshow, and the lagometer shows the connection gets stress.

(G0-Gerbil) #16

I tend to bake models, simply to make them lightmapped and match with the rest.
After all, polygons are polygons, and as long as your map isn’t slow to begin with, or approaching the hunkmegs limit, it’s not that big a deal. I do remember when I converted all the lamsp in HD to this form - so tiny that it made no visual difference and increased my BSP size noticably. I changed them all back, only to later hit the overall entity limit, and had to change them all back again to get under it :slight_smile:
I have yet to use the ‘autoclip’ feature though, seemed like overkill.
It seems though, in future, I should be more selective about what is a model and what isn’t - models with simplified clips being the preference for slower areas (either due to polygon count or potential number of players in that area at once).

Edit:

I just re-read your post reyalP - I missed the part where you said models baked into the BSP aren’t part of this because they don’t have brushes associated with them. Hurrah!

That’s a darn interesting note about the collision - I am pretty shocked to find the engine doesn’t seperate out non-clipping brushes entirely - I figured it would keep the ‘semi-clip’ (IE anything that is conditional, eg weapon clip). On the other hand, I can’t think of any situation bar a mistake where you’d have tons of entirely non-clipping brushes :slight_smile:

On a related matter, I just read up about subtlehint - I got the information from this thread: http://www.splashdamage.com/index.php?name=pnPHPbb2&file=printview&t=7003&start=0&sid=8437918a0683f0c74e64aba36f9fa08f
Made for some interesting reason, and means I should probably have been using subtlehint in my maps, instead of hint, since I generally only create localised hint brushes.
Would probably aid performance and compile times, so well worth a read.

ps: good to see you again Gerbil!
Thanks, it’s good to be back. I spent over 6 months without touching ET or Radiant due to real life. I finally got back after realising some people were still crying out for more maps - I honestly thought ET would be dead by now. Anyway, this is also why I’m back here - to keep myself ‘immersed’ in ET so I don’t lose enthusiasm again :slight_smile:

(]UBC[ McNite) #17

Iirc misc_gamemodels without script/targetname etc. don’t count against the entity limit, i think this was mentioned in some pro/con gamemodel discussion once. The lightmapping thing is what makes me dismiss gamemodels though. Could this be worked around with remapshading and giving the models a lightmapped shader?

(pakalatak) #18

I set max_fps 333 for me to check out FPS while playing with 20 players on the map, and i got quite some laggy situations.

networking is related to fps that’s why… You probably missed a lot of packets because of this value. I’ve read several time that max pakets should be set nearly half of the fps. That means you need > 50 fps to have a 25 images / second updated right for your gamer’s eye :smiley: Setting fps to 76 make sense (except for testing maps).

(G0-Gerbil) #19

Could this be worked around with remapshading and giving the models a lightmapped shader?
No, because lightmapped faces need more than just the shader definition - they need the lightmaps created and UV coordinates assigned, which is never done for yer bog standard game models.

(SCDS_reyalP) #20

FWIW, maxpackets barely matters at all. Q3 games generate one client command per client frame, no matter what. The server does a client_think for each client in response to each client command. Lower maxpackets simply stuffs more commands in a single packet, so the CPU load on the server is nearly the same. That is also why FPS, rather than maxpackets affects things like jumping on the server. You save bandwidth with lower maxpackets mainly because q3 command packets are so small they have a lot of overhead. Multiple commands can also be effeciently compressed into a single packet.

The ‘flashing jack’ you get at very high FPS (usually > 333, but it depends on connection and settings) happens when you hit the maximum number of commands you can stuff in a packet, if I remember right.

FWIW2, etpro’s b_optimizeprediction makes a huge difference in client CPU load due to physics. The test map I mentioned above goes from ~50FPS to ~230 turning it on. CPMA has the same optimization, not sure about etpub.

FWIW3, when doing the testing with collision brushes, I actually made a modified q3map2 which allows you to tell the compiler to discard brushes from specified geometry after the BSP phase (it’s a shader content param). This allows you to create things that are almost exactly as efficient as misc_models, but without the extra hassle of exporting to ASE. It also means that some ‘technical’ things like hint brushes can be discarded. Have to finish that up and release it one of these days.

edit:
more details of testing http://www.sonic.net/~rfm/et/mapstuff/q3_surfaces_and_brushes.html