q3map2 issues/development

So don't get mad at me, but xonotic's q3map2 is by far the best maintained version I've found, so I've been using it for a different game (urban terror). So feel free to throw a book at me if I'm stupid or just tell me "unsupported" and I'll understand. =(

I have a couple issues:

(1) Origin points on moving brush entities (e.g. func_pendulum, func_ut_train, etc.) don't seem to work for me. It seems to pick a different point as the origin rather than the one I set -- I see my pendulum sweeping light years across the map; this never happened in other q3map2's. From comparing with some previous q3map2's, I found that map.c has a bunch of new code with "originbrush_origin" overwriting the ent->origin or some such. I tried reverting just these parts, and now my moving brush entities work fine, except for when I do multiple bounce radiosity compile. Plain -light -fast works fine. Any ideas for this one? I probably broke something (although it seems to work better than what was already there, at least for using it with urban terror).

(2) I've noticed for some really big maps -light compile, some brushes get full brightness. If I reduce the amount of stuff in the .map by basically just deleting half of it, the brushes are normally rendered again. Although... this might just be an old bug in q3map2 as I've never been able to even compile this big of a .map until the xonotic q3map2. So maybe that's not something you can help with.

(3 / not a bug) Also, I don't know if this is of interest to anyone, but I was bored and needed a break, so I multithreaded the "allocating" step of StoreSurfaceLightmaps, which took a significant amount of time on my maps (and I noticed it was only using 1 CPU during this time). Went from 770 seconds down to 597 seconds over the whole -light compile with a quad core i7, so pretty decent. Because of the data dependencies, I had to do multithreading at a very fine grained level, so it's probably less optimal than it could be. Anyway, if anyone found this interesting... ;p

Thanks, v

I tried that once too (used it for Jedi Academy) and it seems not to be supported. Urban Terror and Jedi Academy use the Quake 3 Arena Engine, Xonotic uses the Darkplaces Engine (based on the Quake Engine)... so that won´t be compatible.

Any idea what the xonotic q3map2 was based from then? So I can check some diffs or something? I really like 99% of the changes since the other most recent q3map2 I could find, which was... forever ago.

For Urban Terror you have q3map2 created by TwentySeven from Frozen Sands. It supports bump mapping, bump radiocity lights and autohinting.

For Urban Terror you have q3map2 created by TwentySeven from Frozen Sands. It supports bump mapping, bump radiocity lights and autohinting.

The q3map2 by TwentySeven is extremely old as far as I can tell (2 years old @ june 2010 --> http://code.google.com/p/urt-bumpy-q3map...ce/browse/ ). I'm also using UrT classic, not using UrT "HD", which is where the bumpmapping stuff comes in. I'd still prefer all the advancements in xonotic's fork as they have significantly improved the quality of math stuffs and limits while also resulting in a smaller .bsp.

You still can benefit from radiacity bump lights and autohint, but it's your choice :-) Specially new extra lighting is awesome and allows to create much better maps.

have significantly improved the quality of math stuffs and limits while also resulting in a smaller .bsp.

Could you decribe what's in Xonotic's q3map2?

You still can benefit from radiacity bump lights and autohint, but it's your choice :-) Specially new extra lighting is awesome and allows to create much better maps.

have significantly improved the quality of math stuffs and limits while also resulting in a smaller .bsp.

Could you decribe what's in Xonotic's q3map2?

I don't have a full list, but, for starters:

Q3MAP2_EXPERIMENTAL_HIGH_PRECISION_MATH_FIXES
Q3MAP2_EXPERIMENTAL_SNAP_PLANE_FIX
these (presumably) empirically resulting in a reduction in .bsp size for me by about 30% while also yielding much higher quality (bsp decompile on older q3map2's shows many possible "errors" of 0.001-0.005, which may have simply been why the storage size was larger, but also explains why the quality seems worse)
conversion of MAX_* to dynamic reallocations -- pretty much awesome for supporting ridiculously large maps that I have
runs faster

If you diff the code there's actually a huge number of changes. I'd rather see if I can adopt all these awesome changes back to UrT rather than adopt an old/out-of-date version that (currently) isn't even able to compile my .map file.

Or, if I knew where xonotic based their original fork from, maybe it would be easier to see where a recent fork may have became mildly incompatible.

isn't even able to compile my .map file.

Well, that's very strange argument, you might just have constructed map in bad/poor way.

So in exchange of smaller BSP you give out better lights and better performance? Strange barter

Look at this map for UrT:


It consists 400 models and has BSP size of 14 mb. What you are mapping there - 1:1 remake of Los Angeles?

isn't even able to compile my .map file.

Well, that's very strange argument, you might just have constructed map in bad/poor way.

It's a big map with a large number of brushes, not a graphically detailed map. (specifically, it's an icyjump map). It's not constructed poorly, it's simply massive. I'm not really concerned with making it look super good (most of the textures are checkerboards anyway).

Stock download of bumpy q3map2 gives an immediate error:

************ ERROR ************
MAX_MAP_BRUSHES (32768)

This is obviously correctable with a recompile, but that fork of q3map2 lacks all the other improvements that would ACTUALLY help what I'm trying to do (i.e. compile a massive map to a smaller more efficient size with less math errors leading, to better visual quality, since the geometry actually matters more than some neat lighting effects).

That's why you should use Blender/3ds Max. Over 30 000 of brushes is insane.

That's why you should use Blender/3ds Max. Over 30 000 of brushes is insane.

This makes absolutely no sense. Those programs would not help whatsoever. In fact they'd probably make my brush count worse as they are not designed for the custom surfaces I use, not to mention they probably CANT do it (due to the necessity of special geometry to promote sliding and preventing lemmings), not to mention they are probably terrible environments to design this kind of map in. My surface generators are already set at the lowest possible subdivisions to prevent bounces and other bugs that are necessary to make this kind of map work in UrT.
The xonotic q3map2 has no problems working with my size of .map, and the UrT client has no problem playing them.
Can we get back on track to my original question X instead of trying to get me to follow your non-useful track Y? =(

I tried that once too (used it for Jedi Academy) and it seems not to be supported. Urban Terror and Jedi Academy use the Quake 3 Arena Engine, Xonotic uses the Darkplaces Engine (based on the Quake Engine)... so that won´t be compatible.

while dp != q3, darkplaces does use the quake3bsp format, thus maps made with netradiant's q3map2 should work fine in other engine that support q3bsp too.

1: possibly you need to set some -game flag on you compile commandline.

2: really big map always was a touchy thing with q3map2. when you get unlit surfaces or other issues on such, try moving everything a little (no joke), and/or using a different -samplesize

3: patch plz

Perhaps a noob question but why isn't Darkplaces and Q3Map2 suitable for large maps? Why the 32768 limit?

As far as I know the limit also applies for the Quake 3 Engines... though I wouldn´t use that much brushes in one map. Indicates that your map has bad brushwork or is way too large.

So don't get mad at me, but xonotic's q3map2 is by far the best maintained version I've found, so I've been using it for a different game (urban terror). So feel free to throw a book at me if I'm stupid or just tell me "unsupported" and I'll understand. =(

I have a couple issues:

(1) Origin points on moving brush entities (e.g. func_pendulum, func_ut_train, etc.) don't seem to work for me. It seems to pick a different point as the origin rather than the one I set -- I see my pendulum sweeping light years across the map; this never happened in other q3map2's. From comparing with some previous q3map2's, I found that map.c has a bunch of new code with "originbrush_origin" overwriting the ent->origin or some such. I tried reverting just these parts, and now my moving brush entities work fine, except for when I do multiple bounce radiosity compile. Plain -light -fast works fine. Any ideas for this one? I probably broke something (although it seems to work better than what was already there, at least for using it with urban terror).

(2) I've noticed for some really big maps -light compile, some brushes get full brightness. If I reduce the amount of stuff in the .map by basically just deleting half of it, the brushes are normally rendered again. Although... this might just be an old bug in q3map2 as I've never been able to even compile this big of a .map until the xonotic q3map2. So maybe that's not something you can help with.

(3 / not a bug) Also, I don't know if this is of interest to anyone, but I was bored and needed a break, so I multithreaded the "allocating" step of StoreSurfaceLightmaps, which took a significant amount of time on my maps (and I noticed it was only using 1 CPU during this time). Went from 770 seconds down to 597 seconds over the whole -light compile with a quad core i7, so pretty decent. Because of the data dependencies, I had to do multithreading at a very fine grained level, so it's probably less optimal than it could be. Anyway, if anyone found this interesting... ;p

Thanks, v

As for (1): origin does work different in NetRadiant's q3map2. There, "origin" key actually moves the entity, like it moves any other entity. This was necessary in order to reliably be able to decompile maps, and it also worked very inconsistently for func_group vs other entities before. The proper way to set origin is to use an "origin brush" (brush textured with common/origin) that you then make part of the entity. Its center is the rotation origin.

There is actually a tool included to convert map files to apply this change: q3maporigin2originbrush.pl

Still, it MIGHT be possible to fix handling this case by an option. Maybe later.

As for (2): Probaby an old bug and hard to impossible to debug.

As for (3): patch welcome. But normally this step doesn't take that long... typically IlluminateRawLightmap is the only step taking a lot of time. Perhaps you used a too small samplesize, thus it made too many lightmaps? Note that rendering gets REALLY inefficient (low fps) once more than 16 lightmap pairs (32 tga files in mapname/ directory) were created.

"So don't get mad at me,"
They get mad at you for making a map that is "too big/complex". Welcome to the club. Next time just make a box map for the xonotic player community, or just no map for them (as you are now: why willingly enter where they don't want you?)

That's why you should use Blender/3ds Max. Over 30 000 of brushes is insane.

No it is not insane. It's insane of you to suggest using models for a _trickjump_ map.

Every time anyone goes over the "limit" no matter what it is, in this community, peeps come out of the woodwork to condemn them.

"Why would ANNNNYYYONNNEEE!!!1111 want to use more than 64 kilobits of memory!!!"
Luddites.

And they wonder why so few mappers make maps for this community (or why you are making a map for Urban Terror)

Fortunatly the developers aren't like the players.

Perhaps a noob question but why isn't Darkplaces and Q3Map2 suitable for large maps? Why the 32768 limit?

Because the luddite players say so. The original code of q3map2 had a limit and now that limit is GODS WORD to them. Same with every other limit, including weapon number (THERE BETTER NOT BE ANY MORE THAN 9 WEAPONS or 7 no THREE IS ENOUGH!)

As far as I know the limit also applies for the Quake 3 Engines... though I wouldn´t use that much brushes in one map. Indicates that your map has bad brushwork or is way too large.

The limit doesn't apply here so it's a moot point that you should not be arguing or holding to.

Every time anyone goes over the "limit" no matter what it is, in this community, peeps come out of the woodwork to condemn them.

Every game engine has it's limitations. Including idtech3, Source, etc.

They get mad at you for making a map that is "too big/complex". Welcome to the club. Next time just make a box map for the xonotic player community, or just no map for them (as you are now: why willingly enter where they don't want you?)

Don't get mad. Critique is part of the job

Thanks for the reply, and sorry for the slow response, was a really busy month.

For the complainers: Yes I have a very large map, and no, the brushwork is not inefficient like some super noobs that I have seen have inefficient brushwork. There's a big difference between being a bad mapper and thus having tons of bad brushes, and simply making a massive map. The engine itself accepts the map fine, so I'm fine with pushing the limits as a mapper.

(1) I'll check out the perl file. I saw it in there and thought it might have something to do with it, but wasn't exactly sure. My generator ends up using origin points instead of brushes just because it's generally easier with my generator.

(3) My guess then is that my map is just overly massive and therefore has a billion lightmaps. iirc when I was debugging it, it was at least several hundred lightmaps, and it seemed to be comparing every one against every other one in order to twin them up to save space. It ended up being a lot of time (many minutes) for that step as a result, so maybe it's not something normal people would find useful. :/ There is a lot of surface area to lightmap, but I typically try to samplesize the large walls to something like 32 (or was it 8? whichever side of default=16 made the bsp smaller).

The code is currently very win32 specific (I just spawned my own persistent threads because the function I multithreaded is not a large work block, but rather many short work blocks, so I didn't want to have the overhead of creating/destroying 8 threads or w/e each time that function got called). Anyway, maybe I can try to clean it up a little and cross-platformize it better.

For Urban Terror you have q3map2 created by TwentySeven from Frozen Sands. It supports bump mapping, bump radiocity lights and autohinting.

What is autohinting?
Cant find any decent info in internet, also no references in the code.