Let's set some R_speeds limitations here people...

(damocles) #1

Ok, so Q3 comes out and you’re not supposed to go over 15000 verts. Q3TA/Wolf come along and they bump it up to 20000 verts. Fair enough, hardware moves on and the standard user base has a GPU capable of pushing out that many verts. ET comes along and the limitations are laughed at, dragged through the streets, put in the stockades, have moulding fruit thrown at them, hung, drawn, quartered and set on fire. Then possibly mugged.

So what have we got here? Free reign? Some of the SD maps have very high vert counts. On fuel dump if you stand by the first hut out of allied spawn and look towards the bridge, the r_speeds are in the 35-40k range!

I know it doesn’t bother me because my system can handle it, but there are a lot of people out there that cannot handle those kinds of poly counts. So I think the mapping commuinity should give this some consideration to this and try and set some standard limits. That’s not to say they won’t be borken repeatedly, but we should at least try and agree on a general limitation for people to aim for.

Given the increases in hardware since RTCW and the fact that ET maps almost HAVE to be huge, the R-speeds are going to have to follow suit, but personally I think we should be aiming for under 30k verts. Anyone want to add to this, agree to this or laugh in my face?

Remember, the lower your R_speeds, the more people will enjoy playing your map. Many people don’t play some custom RTCW maps simply because the fps they get ruins the experience. The maps may be great to play and look at, but they don’t get much airtime because of people’s system limitations.

(Shallow) #2

R_speeds have never been the definitive determinant of map performance that they have sometimes been made out to be. I could give you a tiny room with very low triangle counts that would bring a GeForce FX to its knees, and at the other end of the spectrum I’ve found huge areas with simple geometry can also be disproportionately slow in some cases even with ‘good’ r_speeds.

Something to bear in mind is that geometry that comes out of a Q3map2 -meta compile is a little different to an old style q3map build. Multiple brush surfaces are combined into larger metasurfaces. These surfaces can be rendered a bit faster than seperate brush faces because many triangles within them share vertices, so many less vertex calculations are performed, giving your card a bigger proportion of its time to spend filling pixels, which is what it’s supposed to be doing after all.

However if you’re ONLY going to look at the triangle count and ignore all the other numbers then a Q3map2 compile is going to look like it has very high triangle counts - even though in every case I’ve tried to date, a Q3map2 compile has given significantly better FPS than the same map in the old Q3map.

I’m not saying you should ignore r_speeds, I’m saying that relying on them completely is ill-advised, and that you should look at all the information they provide not just the triangle counts. I’m not saying you should forget about performance and build what you like, that’s going to ensure no-one plays your map.

Of course, the best way to find out how your map will run on a low-end system is to play it on a low-end system! If you can’t do that yourself, ask testers with older rigs to screenshot the worst cases, then analyse those locations.

OK, I’ll shut up now.

I hope you don’t make ydnar cry by starting an r_speeds thread :smiley:

(damocles) #3

You are right on one thing - r_speeds aren’t the definitive answer - but they are a large part of the equation. Another part is shaders/multi-texturing.

If you have low r_speeds and stupidly complex shaders then yes you can bring a good system to it’s knees.

One other thing to consider is the cpu overhead associated with portals. If you have a LOT of portals in the BSP then it can take older CPUs quite a bit of time to decide which ones are drawing and this can slow down systems with even the best GPUs.

However, both the shader issue and portals issue are things that you learn when you become advanced mappers. r_speeds are a good way for newer mappers to gauge how their map will play on older systems, which is why I think we should be looking to set a community guideline for them.

There are a LOT of new mappers coming onto the Q3 mapping scene with ET, and a lot of people will need some guidelines to help them avoid big mistakes. There is nothing worse than spending 3 months making a fantastic map only to have to take out 2/3 of it when you find out what r_speeds are for. (I know, it’s the one big mistake I made when I first started Q3 mapping)

Also, with ET there will be a lot of very open maps where you can’t reduce r_speeds by vis blocking, so people need to be aware of just how much detail they can put into these huge areas.

(wudan) #4

I thought that multiple texture shaders DID add to the number of verts, thereby increasing the time to render … it’s OpenGL, so that seems like what’s happening. I’ll be the first to admit I’m wrong, tho.

(damocles) #5

I’m not 100% sure on the shaders adding to the verts issue. I always thought they didn’t because they are using the same verts so the r_speeds calculations ignored them. I’ll wait for someone with a bit more knowledge on the subject to pipe up…

(SCDS_reyalP) #6

Yes, but OTOH, the ET maps have high r_speeds very poor performance. Coincidence ? You decide :moo: