Rules for the judges

[Null]

After some deliberation,

We've decided to remove r_speeds from the list. It was a highly technical thing to ask of most new judges, and beginners. We now leave it up to the mappers general discretion to check for this.
There are other advantages of maintaining lower r_speeds as Margaal mentioned. By having so you're actually doing yourself a favor cutting compile times drastically and frustration to a minimum. From hours to mere minutes. So if you notice that your map is taking an awfully long time to compile, you're actually penalizing yourself, and it's time to check those pesky r_speeds.

Note: If anyone still feels that this is one criteria that we really need to be judging for, we're considering appointing a panel of technical specialists to do it. This way we can reduce confusion and make sure this result is consistent and fair across the board. Either way new judges will not need to worry about this

[redangel121]

Feb 4, 2015 16:24:52 GMT -5 Wixen1 [Q2C] said:

There might still be some players out there with computers with an age of 5+ years, so...should we take it out of the rules, what do you guys think?

-W1

I don't find that removing a rule is the best way to handle it... not all the way. We need to have limits on the r_speeds for a good reason if not to limit the maps geometry than to limit the mappers complexity and keep it challenging. I like the idea of raising it to a level acceptable for today's standards. I believe 2500 can be normal and high spots should not exceed 4000 in my opinion. it would be a good trade off for today's standards of computing and have greater flexibility for the makers but still keeping it within a limit that would challenge them to come up with the best of the best for the 10th contest!

[Wixen1 [Q2C]]

Hmmm.. should we have poll about having the r_speeds in the rules and if yes, with what numbers?

-W1

[NIN-Kitsune]

I think 1500 can be considered optimal in any case for all areas in tpyical DM style maps, 2000 can be considered still acceptable in most cases, while 2500 plus should be limited to very particular areas where it can be justified, being around or above 2500 in most areas of the map can be a deduction of technical points. I'd say it also sort of depends on what the map is setting out to accomplish in the contest and how well it does so with it's given r_speeds. After all this IS still vanilla Quake 2. Let's remember why we all love mapping for Quake 2, it has simple elegant beauty it pulls off with so little that most other modern games completely miss the point of and kill fun factor and performance at the same time.

Anyway, how much for example going over 2500 on average should deduct in points should depend on the execution of the map and how aesthetically pleasing it succeeds at being in regards to it's r_speeds, cause if a mapper makes a map that had lots of inefficient geometry and tends to average over 2500 and still doesn't create the most pleasing sight to look at (gameplay should always be good too in addition to aesthetics), it should suffer points there. But if say a mapper produced one of the most beautiful maps ever seen that induces the Ooo's and Ahh's, and frequently hit about 2500, then it should suffer less points loss, it's all relative in my mind. So that's my take on this. The point of this contest in my eyes is to make the most pleasing and enjoyable well executed map design that doesn't overly abuse things in sloppy manner that makes the map suffer in some aspect heavily for minimal gain in other aspects. Be efficient and graceful in design, that's the key.

So, we shouldn't completely throw r_speeds out, it teaches us to make the most of our work and it will be better for it!

[redangel121]

Feb 5, 2015 4:00:26 GMT -5 NIN-Kitsune said:

I think 1500 can be considered optimal in any case for all areas in typical DM style maps, 2000 can be considered still acceptable in most cases, while 2500 plus should be limited to very particular areas where it can be justified, being around or above 2500 in most areas of the map can be a deduction of technical points...

So, we shouldn't completely throw r_speeds out, it teaches us to make the most of our work and it will be better for it!

This is exactly what I had in mind and I couldn't have put it better myself. Also slightly off topic but kinda relevant... Are ctf maps going to be submitted?

[jaydolan]

Feb 4, 2015 18:12:04 GMT -5 Null said:

After some deliberation,

We've decided to remove r_speeds from the list. It was a highly technical thing to ask of most new judges, and beginners. We now leave it up to the mappers general discretion to check for this.
There are other advantages of maintaining lower r_speeds as Margaal mentioned. By having so you're actually doing yourself a favor cutting compile times drastically and frustration to a minimum. From hours to mere minutes. So if you notice that your map is taking an awfully long time to compile, you're actually penalizing yourself, and it's time to check those pesky r_speeds.

Note: If anyone still feels that this is one criteria that we really need to be judging for, we're considering appointing a panel of technical specialists to do it. This way we can reduce confusion and make sure this result is consistent and fair across the board. Either way new judges will not need to worry about this

Long compile times are not implicitly tied to r_speeds at all. This is akin to the "high r_speeds causes problems for the net code" myth. While there may be a correlation for some sub-optimal maps, there is absolutely not a causal relationship.

The BSP portion of a map compile is almost always the shortest, and it's at this stage where brushes are chopped up into faces and the BSP tree is constructed. The Quake2World map "Penumbral Wake" by TRaK has over 50,000 surfaces, but it's BSP compile time is only 40 seconds on my i7 Macbook Pro. It's total compile time (BSP, VIS, LIGHT) is roughly 4 minutes. How?

The longest portion of a map compile is typically the visibility stage, and this stage will grow exponentially if your map is not properly hinted, does not make use of CONTENTS_DETAIL, or just suffers from a very wide-open design. TRaK's map has a VIS compile time of maybe 20 seconds. Why? Because almost everything in it is CONTENTS_DETAIL.

TRaK created a "visibility hull" for the map from very large, very simple brushwork, and then added hint brushes to fill the playable area of the map, taking care to split the hint brushes along prominent lines of sight. The visibility hull itself is not actually visible to the player; it exists only to occlude portions of the map.

The visibility hull and hint brushes give the VIS compiler stage *and* the game itself a very simple PVS lump to negotiate, and this is hugely important for both the client and server. The PVS allows the renderer to "shortcut" entire sections of the BSP tree, and likewise allows the server to quickly filter the set of entities that are relevant to a given client.

You want the visibility lump to be as small as possible. A big VIS lump means your map is likely sub-optimal and would benefit from further detailing / hinting. How big is too big? If your map takes more than a few minutes to VIS, you have a problem. Hours to VIS? Rethink your design.

The BSP tree, the structure containing all of the face information, is consulted for collision detection and for rendering. It's a tree, which means that the complexity of looping over it is roughly log(n), where n is the number of leafs and nodes in the tree. This is a good thing: it means that the complexity of iterating a map with 1,000 nodes is 8, while the complexity for a map with 10,000 is only 13.

In other words, a BSP tree scales up to moderate polygon counts fairly gracefully. If your map is centered on the origin, your BSP tree should be fairly well balanced by the map compiler, and will recurse pretty efficiently for the renderer, allowing you to draw several thousand surfaces per frame.

Everyone making maps for Quake-based engines should understand these concepts, at least at a rudimentary level. If you're interested in seeing how TRaK was able to push > 10K r_speeds in a Quake2 engine, his map file can be found here:

github.com/jdolan/quake2world-data/blob/master/src/default/maps/wake.map

Other excellent .map resources that show how to create efficient BSPs are:

Aggressor by Tryann:
github.com/jdolan/quake2world-data/blob/master/src/default/maps/aggressor.map

Gehenna by Jester:

github.com/jdolan/quake2world-data/blob/master/src/default/maps/gehenna.map

[Wixen1 [Q2C]]

Feb 5, 2015 18:20:51 GMT -5 jaydolan said:

Everyone making maps for Quake-based engines should understand these concepts, at least at a rudimentary level. If you're interested in seeing how TRaK was able to push > 10K r_speeds in a Quake2 engine, his map file can be found here:

github.com/jdolan/quake2world-data/blob/master/src/default/maps/wake.map

Other excellent .map resources that show how to create efficient BSPs are:

Aggressor by Tryann:
github.com/jdolan/quake2world-data/blob/master/src/default/maps/aggressor.map

Gehenna by Jester:

github.com/jdolan/quake2world-data/blob/master/src/default/maps/gehenna.map

Is it only me, who has problems with download links?

-W1

[ace]

Downloads are fine, just save the raw text as a .map file, then load it up in your editor.

[Null]

OK, So here's where everyone stands on r_speeds so far:

Wixen:	I am thinking 1500... anything over 2500 should severely reduce the technical score
Kitsune:	I think staying under 2000 and 2500 at tops when possible is still a reasonable standard to maintain
Margaal:	1500 is pretty average for a complex map.... 2200 in open space, and in the corners 2800
redangel121:	I believe 2500 can be normal and high spots should not exceed 4000 in my opinion.
ace:	Yeah, we have a few maps in rotation that can hit r_speeds of 4000+

Would anyone have any objections if we were to make the new standard r_speed: stay under 2500 and 3500 tops, before losing any points?

[NIN-Kitsune]

A better standard than nothing, after all, I think the circumstances (frequency of) and the quality of aesthetics in relation to high r_speeds around those points is what I think should determine the points loss most or lack of loss thereof. Like said before, if it looks poor and has high r_speeds, major loss, but if a true work of art at high said r_speeds, less loss at the judges discretion. I think it can be fairly simple from here on ^w^

[redangel121]

Feb 6, 2015 3:29:48 GMT -5 Null said:

Would anyone have any objections if we were to make the new standard r_speed: stay under 2500 and 3500 tops, before losing any points?

No objection, sounds good.

[Wixen1 [Q2C]]

Feb 6, 2015 3:29:48 GMT -5 Null said:

Would anyone have any objections if we were to make the new standard r_speed: stay under 2500 and 3500 tops, before losing any points?

Sounds fine with me.

-W1

[spirit]

Same here, fine with me.

[Null]

Awesome! That settles it then, now that everyone agrees

[Deleted]

Jaydolan

that's is a very good explanation, about the compile toolz..

==========================================

This is by the way the last thing I write about R_speed..

to avoid mapping problems, I often mentioned on this forum, that newbies mappers should keep their rooms small 512x512 Max.....
mapping this way R_speed stays good 1500, compile tool timvis3 work quickly.

newbies mappers often start too big , and do not blocking the line of sight between open areas, timvis3 compile tool is suffocating and need more time......Bla bla bla...

ANd...About hint brushes..
Only experienced or perfectionist mappers use hint brushes..
i have never seen it in a normal Q2 maps source, because it is not needed..hehe..
have used it only once in margaal17clip ----> crossing the Q2,limits,boundaries.

My experience with normal Q2 mapping..( with no tricks ).
is that the Q2 Engine give problems when mapper reach 14.000 brushes..
( Error too many surfaces )..this is the Q2 Engine limit.

the maximally brushes i reach was 13.939 and in other map 13.710..
Reaching this number the disturbances appeared in places where the map was good....
....I knew the design layout was a failure i made too much brushes....
But back then I was obsessed, the complexity challenged me to repair,fix,leak holes,shadow and light failures...

I never do this Q2 limit mapping again , Yeah I learned a lot but pffff...
best is re-design the layout and or smart mapping with less brushes..

=====================================
Good Map Design - R_speed guidelines
=====================================

600 - 1000 = Good design rooms ( be proud! ).
1000 - 1500 = with rocks walls, odd floor, and open rooms (be proud!).
1500 - 2000 = more rocks walls, odd floor, and open rooms ( good design!).
2000 - 2500 = mapper has too many ideas in rooms. ( still good design).
2500 - 3000 = can be a masterpiece, but map design is wrong.
3000 - Higher = you like mapping, but there is no balance for the Q2 engine.

=====================================