|
|
Post by NIN-Kitsune on Feb 7, 2015 16:02:53 GMT -5
Good summary as well to me, both you and Jay confirms what I've come to learn rather recently (though even on my most busy maps I don't think I went much more than a few hundred brushes, but compile time took long because I didn't quite yet understand vis fully, but now I pretty much do), I even separated the upper and lower levels from that one map I posted screenshots from a day or so ago in terms of vis and now I almost halved the r_speeds in each section, while even though the map has become increasingly complex since I last showed it's early progress, it has vis compile times in the mere seconds due to the geometry layout and efficient design despite being two rather large rooms with quite a bit of details instead of just one and gives me more room to beautify it and add more intricate bits of interest to it! Rather fun to see just how much you can do while respecting the Quake 2 engine restraints from knowing how it all works! Was why I agreed r_speed guidelines encourage (albeit a bit more modernized) a well designed map. But vis and r_speeds indeed can be highly separate in their results. Through mastering both, maps can be made both speedy to create and test, AND for players with dinosaurs to play (there are indeed surprising numbers of those players)!  |
|
|
|
Post by jitspoe on Feb 18, 2015 20:19:03 GMT -5
The correlation between r_speeds and net performance has to do more with how the map sightlines are broken up and visibility than purely a (wpoly) number. You could have a map with very simple geometry that is not broken up into discreet rooms, so the r_speeds are somewhat low, but all entities are visible pretty much all the time (and are thus transferred over the network). That's not good for net traffic. You can also have a map that's cleanly broken into different sections and only the geometry from one room is rendered at a time, but there is a ton of detail. Both these situations can generate roughly the same r_speeds, but one of them isn't good.
The more telling factor is you set gl_showtris 1 and see a bunch of geometry visible that shouldn't be. That's the kind of thing that should be focused on and can often be overlooked when simply looking at a number. It can also be very telling if somebody did something like wrap a box around the whole map to fix a leak. You'll see a lot of "dead" geometry (back sides of brushes and such that are never visible from the playable space).
I guess the point I'm trying to make is that there should be an appropriate correlation between the visible geometry and the r_speed wpoly count. If map A has twice the r_speeds of map B, but map A has twice the detail visible with fancy brushwork, that's not a bad thing. It's what you'd expect. If map A has twice the r_speeds as map B, but map A doesn't look like it has any more detail visible, then that's potentially a problem, and maybe the judges should deduct points. If a map looks visually stunning with lots of detail, but the r_speeds are really low, the judges should be adding points, since that's difficult to pull off.
That's my 2 cents.
|
|
|
|
Post by cocerello on Mar 14, 2015 6:31:59 GMT -5
Interesting discussion here
About the matter about r_speeds. Do for the judging of the map count epolys+wpolys, only wpolys, or the higher of the two? I suppose its wpolys only, but i want to be sure.
|
|
