Maps with crap FPS

(G0-Gerbil) #21

Ace write-up.
I find it hard to believe that such stuff is still ony just coming to light after so many years of the core engine existing!
I note you say that brushes that lie in more than cluster is more desirable than splitting the brushes along the split. I’m glad of this, because it’d be a pain to have to factor in the splits as you mapped :slight_smile:
I did get a little bit confused by the fact your ‘test case’ column rarely matches the ‘name’ column in the above table, but I got the idea enough to see what a difference it can make.

My question now would be how much would this affect a real-world case, since obviously your test maps were designed to highlight any differences, and as a result are probably not likely to reflect how brushes are used normally.
The immediately obvious case would be removing caulk hull brushes (so it’s about time I started using a custom shader for that methinks) - apart from that what other uses spring to mind?
I am probably missing the point, since only two other bits crop up:
1 - Unreachable geometry - remove it’s brushes completely and use proxy collisions if you feel the need for something
2 - Completely noclip brushes - erm… sunbeams etc?

(SCDS_reyalP) #22

People have known about it at some level (you can guess most of this just by looking at the .bsp file spec), but no one took the trouble to do detailed testing and write up the results. Also, until the Q3 engine source went GPL, you had to guess as to what was happening under the hood.

I did get a little bit confused by the fact your ‘test case’ column rarely matches the ‘name’ column in the above table, but I got the idea enough to see what a difference it can make.

Sorry about that, as stated this is an unfinished draft (the whole project has been sitting on my HD untouched for a long time :/), but I figured I throw it up there. I’ll try to sort that out soon.

My question now would be how much would this affect a real-world case, since obviously your test maps were designed to highlight any differences, and as a result are probably not likely to reflect how brushes are used normally.

Absolutely. This is only one of many performance factors, and not nearly such a big deal on real maps. However, it does give people some more things to consider beyond just r_speeds. The points that brush complexity does cost, and that BSP splits matter even if they don’t help vis is something that many experienced mappers seem to have missed.

The immediately obvious case would be removing caulk hull brushes (so it’s about time I started using a custom shader for that methinks) - apart from that what other uses spring to mind?

For caulk hull, it might make more sense to keep the hull and discard the drawing stuff. Imagine a flat wall with textured trim etc. The collision and BSP hull just need one simple shape, while the visual geometry could be made out of many. Of course, then you have to worry about where your detail interior deviates from the hull. There are additional complications with surfaceparams and marks (that’s one of the unfisnished bits of this project, and isn’t as simple as it might seem on first glance).

Unreachable geometry is significant on some maps. Think about maps like mp_assault, where you have huge, complex mountains (and buildings) that aren’t reachable at all. You could make some very simple clip to make sure people don’t end up there, and stray PFs explode, and have all the rest be brush free. That alone would probably be enough to turn assault into decent performing map.

Completely noclip brushes includes decals and hints as well. Also, lowering the cost of brushwork allows you do do things that would normally cause unacceptable performance hits. For example, you could make a tile floor that used hundreds of tiles of individual tiles. Of course, it doesn’t ultimately let you do much you couldn’t do with ASE models, but it simplifies the workflow a lot.

Another category is detailed geometry that can make use of a simple clip. For example, if you make a pile of rubble on the ground (with the individual bits made from brushes) they could cost you a lot, even though a simple pyramid of clip would suffice. In fact, many mappers would already use the simple clip to smooth out movement, but they still pay the cost of the brushes that are embedded in the clip.

It also allows you to create new and interesting map bugs :moo:

(G0-Gerbil) #23

The idea of having simplified overall collision data sounds nice, but time consuming to do.
On the other hand, as you point out, there are various circumstances you’d do this anyway, so I like to think of this as simply a speed up for mapping similarly to how you would anyway.

The bottom line though is - what do you require? You have a customised version of q2map2 and some new surfaceparms?
Do you have a ‘super’ q3map2 with all your changes rolled in (I don’t recall all the tweaks you’ve made, but the surfaceparm priority flags springs to mind).

And would I be mad if I asked for a version where you could specify what version number it gave the BSP? :slight_smile:

(]UBC[ McNite) #24

OK that sounds very theoretical. Question is: do we already have the possibility to create those no-collision brushes with what is already in ET? Or do we not? Because in the later case its nice to think about for theoretical exercises, but doesn’t give me anything as a simply practical mapper.

And I guess I m still right when I summarize that all these things are only interesting in huge open maps cuz in maps with effective VIS blocking there shouldn’t be too many collision surfaces ‘in calculation’ anyways?

(SCDS_reyalP) #25

[quote=]UBC[ McNite]OK that sounds very theoretical. Question is: do we already have the possibility to create those no-collision brushes with what is already in ET?
[/quote]
Sure. Make the brushwork, make an ASE from the brushwork, put it in your map as a misc_model or misc_gamemodel. Where this gets annoying is if you later want to adjust the brushwork.

Or do we not? Because in the later case its nice to think about for theoretical exercises, but doesn’t give me anything as a simply practical mapper.

Understanding the causes of performance problems should always help you to design your map in such a way as to avoid them. That is far more useful than any technical trick.

And I guess I m still right when I summarize that all these things are only interesting in huge open maps cuz in maps with effective VIS blocking there shouldn’t be too many collision surfaces ‘in calculation’ anyways?

Other places this happens are very detailed things made of brushwork and autoclipping complex models. I’ve seen noticable examples of these in maps that aren’t wide open or large.

(]UBC[ McNite) #26

Just to be sure: autoclipping with spawnflags 2 is exactly the same as using q3map_clipModel in the shader and then remapshading the model with this shader?

Looking at the rock models: I m not happy with simple clip brushwork around them. Working out complex clipping that gets close to the surfaces of the rock I guess I ll get the same collision data as I would get from q3map_clipModel in the remapped shader (plus all the clipbrushes). So I either can use q3map_clipModel in the shader for them, OR (don’t laugh) import the models in milkshape and export them as .map, and then have a lot of detail brushes. Doing that I can at least snap the vertexes to grid, which probably gives more clean collision data to process than from an autoclipped model.
Looking at the exported .map I d say the .map from a rock model gives me quite some more surfaces and collision data to calculate (compared to the q3map_clipModel’ed rockmodel). What does not work is making the brushes nodraw and texture only the surface… the rocks tend to be pretty nonsolid then. (Also a .map gives me all the disadvantages of resizing, rotating etc. too.)

Apart from that: I guess the rock models are not the ones that add to sucky performance when q3map_clipModel’ed cuz they r large models with not too small triangles, right?

@ Reyal: When asking about “do we have these no-collision thingies in ET already” I was talking about shader commands, not about making models from brushwork. The question would ve been better asked like this: Is it an option to write no-collision shaders for non-reachable terrain and clip it with simple clipbrushwork?

(]UBC[ McNite) #27

Here comes the result of a lil test:

Same map, same compiling settings, same location for observer aiming at the same spot:

rock_big3 as misc_model, _remap with q3map_clipModel in the shader:
114 FPS on screenshot, FPS visibly flickering from 111 to 122 or so

rock_big3 as .map (.md3 imported in milkshape, select all, snap to grid, exported as radiant .map, imported into the map as prefab, made to detail, caulked the whole rock, textured the visible surface triangles, deleted about 8 brushes that are not visible cuz they r in the terrain):
121 FPS on screenshot, FPS steady around 121 to 125

Well… I wouldn’t have thought that, but its an obvious result and way to go.

(SCDS_reyalP) #28

[quote=]UBC[ McNite]
ust to be sure: autoclipping with spawnflags 2 is exactly the same as using q3map_clipModel in the shader and then remapshading the model with this shader?
[/quote]
q3map_clipModel and spawnflags 2 should do exactly the same thing.

The question would ve been better asked like this: Is it an option to write no-collision shaders for non-reachable terrain and clip it with simple clipbrushwork?

Not in public versions of q3map2. My version also wouldn’t do the clipbrushwork for you. You need a human to decide what is both simpler and acceptable. As I said before, it essentially just saves you the step of making models (there are some other differences, but thats the main one). I do plan to release that at some point, but it needs some more testing and cleaning up, and my coding time is going to other things at the moment.

As for your test, the difference doesn’t seem huge, so unless you are having troubles with that area, it is probably better to do whatever suits your personal preference (without knowing your system, I can’t say if 112 fps is bad or good). If you do wish to improve performance in that area, try putting a brush of sutbtlehint so it tightly encloses the rock. That should keep all the rock clip out of the physics calculation of those players who aren’t actually touching it. Of course, that adds to your vis data, which is not completely free either.

It is also worth noting that in most cases, autoclipping does not create nearly as a nice brushwork as you could by hand, even if both conform exactly to the model. I’m not sure how milkshap .map export compares, but it might well be better than autoclip. If you want to see the difference, you of course use q3map generate the brushwork instead of milkshape: put the model in a box, compile to bsp with autoclip, then decompile back to map.

(mortis) #29

I think smart PVS design is one of the most manageable aspects of increasing fps. It’s a lot easier than fancy brush clipping or model tricks. A smart layout will give you ‘cover of caulk’ and limit the number of players/models visible to each other at any one time. Consider fueldump. The tank path follow a large U shape with a mountain range dividing the map into three parts, part 1, the tunnel, the fuel dump. Between each player spawn, the first allied spawn, the tunnel storeroom spawn, the (hacked, albeit) command post spawn, and the underground axis depot spawn you have a large caulked hills blocking -vis. These areas have the highest concentration of players. The players have to spread out a lot and can only see relatively small portions of the map. The placement of walls and terrain can greatly influence overall FPS by limiting visibility to a sane amount. Wide open maps, with three simultaneous artillery strikes and 20 players visible is going to grind things down to a halt. Narrow trenches in very hilly terrain with lots of small bunkers and foxholes would play a lot differently, if you can’t see 2 of the three artillery strikes, and only 4 of the 20 players. Smart terrain design, good brushwork, limited vis, and properly engineered choke points can really help.

(G0-Gerbil) #30

Well, chances are if you know what reyalP is going on about, you are already aware of the most basic things like reasonable structural layout, multiple paths to split up numbers etc.
There are many though have know all that - personally any framerate gains I can make in my maps, I’m happy to learn from.
Although I’d argue framerates are only one area that seperate poor/mediocre maps from great ones (obviously layout and visuals play a great part in this too), it’s a very important part.
The more information ‘out there’ about things that actually improve framerates (as opposed to bad things like portals based on openable doors…) is fine by me.

There’s always a trade-off between ‘framerate increase VS time to implement’ from the mapper’s point of view, and sometimes many of the more detailled tricks aren’t necessary (small maps and / or locations) but for those of us who need to squeeze that last bit of performance out (or who aren’t actually prepared to settle for sub-standard framerates), it’s fantastic :slight_smile:

Things like reyalP’s details show me how much I still have to learn about a technology that’s been out for so many years. You never really know it all!

(]UBC[ McNite) #31

One thing I m wondering about right now: I use custom blocksize 1024 1024 0 and do all horizontal stuff with hints.

Would there be a difference in VIS/performance if I set blocksize to 0 0 0 and set all the X/Y portals (dunno whether this is the right word) with hints? It would result in the same amount of leafs, that s for sure.

Ok i wouldn’t set them all then cuz in some areas bigger leafs would make a lot of sense, but that s for later. And I wouldnt have X/Y cuts in the leafs up in the sky cuz there s nothing in those leafs anyways, so they can be as big as can be.
In the end it would get me rid of some leafs that result in buildings etc. not ending at 1024*x borders now, so I m def toying with the idea of setting ALL leaf-borders with hints.

(G0-Gerbil) #32

If there’s big areas of the sky with nothing in, aren’t you simply better off bringing your sky level down a bit?

As for what you suggest about all manual portal creation, I guess it would indeed be the same, but I don’t really see much point - it’d just be more work for you for the same result.
If you have one area that ‘requires’ lower density of splits, then set that as your blocksize parameter and subdivide more where needed.

(SCDS_reyalP) #33

[quote=]UBC[ McNite]
Would there be a difference in VIS/performance if I set blocksize to 0 0 0 and set all the X/Y portals (dunno whether this is the right word) with hints? It would result in the same amount of leafs, that s for sure.[/quote]
You might be able to do better than the compiler, but it almost certainly isn’t worth the effort. Far better to design your map from the start so it doesn’t push the limits too hard, than to try to hand optimize a problematic map.

Doing the z plane manually is something of a special case, because RTCW/ET maps tend to be horizontally oriented. Again, using RTCWs mp_assault as an example, if you did the standard 1024 cube block size, you end up with a huge amount of useless splits and vis data. All that empty sky between the ridges would be chopped up into useless blocks. If you manually put a few hints just above the various heights a players head would likely reach, you would have far less splits, and at the same time, have better vis.

As Gerbil says, if you can just reduce the sky height, that’s even better, but it isn’t always a good option.

terminology: Blocks make bsp splits. These only result in portals if they separate two chunks of navigable space.

(Shaderman) #34

I’d say if the content of the portals is the same, there shouldn’t be an advantage because you’ll have the same amount of tris to be calculated.

As for what you suggest about all manual portal creation, I guess it would indeed be the same, but I don’t really see much point - it’d just be more work for you for the same result.

Of course it’s more work to block vis manually, but you’re able to control vis much better. IMO you can get less portals with better vis blocking results compared to a default blocksize.

If you have one area that ‘requires’ lower density of splits, then set that as your blocksize parameter and subdivide more where needed.

…which affects the whole map and may result in lots of needles portals.

(]UBC[ McNite) #35

Well I think I can judge on what will be best with regard to blocksize etc., I was just wondering whether the additional hint/skip brushes will add problems. As they will not, I ll do that stuff manually.
It will have some serious advantages over standard blocksize. I ll post the logfiles later on then.

About z-axis hinting: Doing this right gives you real good VIS-blocking. In TheRiver II Redux check the Castle area: if you look at the 2 wings as VIS barriers by using a horizontal hint exactly at the height of the upper level of the wings gives you much better FPS. Example: Player standing in the yard between both wings looking towards the flag: without any horizontal hints it would be very likely that he d draw leafs of the bridge side too. With horizontal hints and the same height as the structural of the bunker wing he draws nothing of the bridge side. This was actually the key to getting very decent FPS in that open map.

And: yea yea i know, do proper planning first etc pp blabla… what do u think I m doing? These things are only to get the max out of the map. I have about 120 almost everywhere right now (local host, playermodel running around), so I wouldn’t call this a problematical map as u suspect. Glad to see at least 1 pro thinking along the same lines as I do here.
Cheers Shaderman :drink:

(G0-Gerbil) #36

I’d say if the content of the portals is the same, there shouldn’t be an advantage because you’ll have the same amount of tris to be calculated.
Obviously, but he was referring to a case with the automatic splitting, which might well cause additional (and empty, but still to be calculated / stored) splits - hence bringing the ceiling down might help, if applicable to the map.

If you guys really really want to do all the splits yourself, feel free - who needs spare time anyway? :slight_smile:

(Shaderman) #37

[quote=]UBC[ McNite]Glad to see at least 1 pro thinking along the same lines as I do here.[/quote]If you’re talking about me… how many beer did you have last night? :suspicious:

But in both cases he would leave alone the Z-axis (blocksize set to 0) :wink:

[quote=]UBC[ McNite]I use custom blocksize 1024 1024 0
Would there be a difference in VIS/performance if I set blocksize to 0 0 0[/quote]

Does a mapper really care about spare time? :smiley: IMO +10% time on a 100+ hours map project don’t hurt a real mapper.
Call me crazy but for me it’s one of the interesting parts of mapping to do vis blocking myself :moo:

(]UBC[ McNite) #38

If you’re talking about me… how many beer did you have last night?

Not enough that s for sure :beer:

About the sky: it doesn’t matter to bring it down cuz there are no z-axis splits by blocksize… if the sky was 4096 units high it wouldnt give more tris/leafs compared to now. Also it is down already like u can see in the pic. Having a default split at 1024 would only result in a lot of additional leafs nobody needs…

IMO you can get less portals with better vis blocking results compared to a default blocksize.

As for doing the VIS by hand: its not only interesting, it gives real nice FPS too. Just improved the FPS in one of the bad spots from 100 to 120, just with a bit of well-set hinting. I don’t call that a waste of time.
For those who r still talking against manual z-axis hinting… just did a bit of testing. Map is Warbell, only diff between the 2 compiles is: custom vs. standard blocksize combined with 21 large horizontal hints i removed for the standard blocksize compile. Check the logfile snippets and pics below.

with a set z-axis blocksize:

 13567 total world brushes
13126 detail brushes (=441 structural brushes of which some are hint/skip, alphablend-markers etc... not drawing stuff)
...
Size: -4128, -4128,  -768 to  4128,  4128,  1568
...
block size = { 1024 1024 1024 } (= 1 split at z=0 and 1 at z=1024)
...
  1081 portalclusters
  2916 numportals
  3825 numfaces
  5832 active portals
   766 hint portals
visdatasize:147024
...
Average clusters visible: 230

FPS: 111 (no LIGHT stage in compile)
r_speeds: 390 leafs 31778 verts 22921/24859 tris

compile with removed z-axis blocksize and manually set z-axis hints:

 13588 total world brushes
13126 detail brushes (=462 structural brushes, the 21 more in here are all hint/skip for horizontal hinting)
...
Size: -4640, -4128,  -768 to  4128,  4128,  1568
...
block size = { 1024 1024 0 }
...
  1026 portalclusters
  2686 numportals
  3953 numfaces
  5372 active portals
  1300 hint portals
visdatasize:139544
...
Average clusters visible: 186

FPS: 173 (no LIGHT stage in compile)
r_speeds: 192 leafs 18658 verts 13218/13834 tris

Clear result: Not much of a difference in VISdata size, but a HUGE difference in average clusters visible and resulting FPS and tris drawn…
So if you plan with it, manual z-axis hinting can be MUCH better than any blocksize stuff.

You can check the screenshots for proof here:
z-axis Blocksize, r_speeds
z-axis Blocksize, r_showtris 2
z-axis with hints, r_speeds
z-axis with hints, r_showtris 2

(DerSaidin) #39

Good work, valuable information.

Could you post a screenshot of the hit brushes in the editor to clarify where you had them?

(G0-Gerbil) #40

I don’t recall once ever saying Z-hinting was bad - I’ve been doing it for years for the obvious benefits it brings.
I am not, however, a fan of removing blocksize entirely to do all hinting by hand - that is just overkill and a waste of time (which is what I was commenting on).
Now I understand the difference between hint and subtlehint my hinting will almost certainly be more efficient (less splits in the wrong part of the map - cheers reyalP) but you have to realise, it’s entirely likely I am working on maps upwards of 5 times the size of yours, and I’ve been on them for years already. I am not a slouch when it comes to determining ‘decent framerates’ with visuals (I spent a lot of effort in RTCW days making my maps look almost as nice in vertexlit mode than lightmapped - as far as I’m aware one of the only people to do so), and I do what I can within reason to ensure framerates are up.
Full manual VISing is, IMO, overkill. I have much better ways to spend my time, and only some of that is mapping :slight_smile:

Bear in mind, even with full manual hinting, you’ll never achieve ‘best’ framerates possible because we do not know the exact trade-off of ‘more leafs = fewer brushes’ VS ‘less leafs = more brushes’, and needless to say it would change entirely depending on circumstances in-game anyway. Hence, I’m not going to lose any sleep over it unless there’s an area that really really needs that final extra % of speed.