How you measure r_speeds. (A guide for the judges)

[Null]

With the contest nearing completion, we'll soon need to measure r_speeds across all maps, in a systematic and consistent manner.

9 - Technical - This includes r_speeds, brush manipulation, map scaling.

r_speeds: High r_speeds = less tech points. Under 2500 in small areas and up to 3500 in general will be acceptable r_speeds, while anything over 3500 should severely reduce the technical score as this makes the map unplayable for some users.

The above is kind of vague, even though we have our core values. I think we still need to translate it into a more flesh out "step by step" guide.
Basically a walk through for the judges to ensure each map receives a rating reflective of it's actual r_speed performance.

[NIN-Kitsune]

I've come up with my own way of testing which seems fairly simple enough when it comes to maps with common rooms or open areas and rooms with doors that hopefully if possible are using area portals. And of course the map should be making proper use of vis compile, and knowing where and where not to use detail brushes.

Generally, the more stuff is onscreen/the amount of brushes, the higher your r_speeds will be. My method tests the worst case scenario in the following order in a large room with lots of details in this example map.

First is to get in the absolute corner of the room to get as much of the room or general area into my view as possible, thus the worst case scenario, and then look at the upper leftmost value (I still assume this is the one number that really matters more than the others), in this instance about the worst I get is a value of 2481.



Next is get to mid-side part of room and look towards center roughly, this nets me an average of 2078.



the third part here I look at a door or doors in my room that lead to a new area, if the door is properly using an area portal as it should and the adjacent area is isolated from the room you are in currently, the r_speeds value ought to be low as seen in this image below.



If the door is opened, the r_speed value shoots up immensely if the next room beyond the door has a lot of detail. If this door was not using an area portal it would really hurt the r_speeds in the earlier shots I took. So these are the things I use to judge my maps r_speeds. Since this door will only hurt r_speeds for the time it's open and only when you are looking towards it, a value of 2800+ or even 3000 isn't too bad in my opinion.

[jitspoe]

Just one thing to be aware of: Different engines measure r_speeds differently. For example, I think kmquake2 measures the actual number of triangles rendered, not polygons, which can result in r_speeds that are like 2-3x higher than vanilla Quake2 r_speeds.

[thehappyfriar]

I tried to keep my r_speeds low via hints (Q2 must not automatically block vis with doors like Q3A/D3), so eventually I said "SCREW THIS" and stopped caring. I want to say my higher spot was ~3000 & that was drawing most of the level.

[newash]

I wasn't familiar with this command and test point of view, but its easy and clear now. Thanks!

[jitspoe]

Mar 21, 2015 8:15:53 GMT -5 thehappyfriar said:

I tried to keep my r_speeds low via hints (Q2 must not automatically block vis with doors like Q3A/D3), so eventually I said "SCREW THIS" and stopped caring. I want to say my higher spot was ~3000 & that was drawing most of the level.

Haha, yeah, Q2's compilers are very arbitrary about what they'll vis. I had some areas that were blatantly out of view, and even with hint brushes, they were still rendering... then some other areas the hint brushes work perfectly.

As for doors, you have to use a func_areaportal in Quake2 to block vis when the doors are closed.

[thehappyfriar]

Now I know what the func_areaportal is for. Thanks.