Quake3World

My map is pretty much done but now I'm getting this nasty error message whenever I try to compile the level (but not when I compile just the BSP):

************ ERROR ************
MAX_TW_VERTS (12) exceeded

I googled the error message and found some instructions on how to fix it but so far haven't found anything that actually works. Then I started eliminating what I had built last until I had removed pretty much 1/3 of the level's brushwork, particularly all sloped surfaces (I, of course, saved a pre-elimination version of the map). I also tried the brush cleanup tool.

I'm out of ideas.

Edit: The game is Q3A and the editor is GTKR.

MAX_TW_VERTS = Max Trace Winding Vertexes

Technology: A trace winding is created for every triangle in the map and then chopped up into the BSP, then further chopped up until each of the raytracer's nodes is smaller than a certain size or complexity.

Explanation: Hitting MAX_TW_VERTS means you have got some clustercrunch of geometry getting sliced up too much. Run a BSP compile with -debugportals (assuming you have the q3map.shader installed & in shaderlist.txt, or you are editing with the newest version of Gtk) with no vis or light stage, and run around the map looking for areas with lots of portals.

Basically, you have a bunch of small brushes and you are creating a bunch of subdivided portals with each one, so many in fact that you hit the maximum trace winding vertexes limit. This usually happens when you map unclean. Try to limit the number of overlapping structural brushes and most importantly convert all non-vis-blocking brushes to detail.

Some reading for you... you can see the difference that changing a bit of geometry to detail makes even in this simple room.
http://www.quake3world.com/forum/viewtopic.php?t=3620

The description you quoted was actually the first one I came across as I was googling for help.

There is a section in the map that I sliced & diced quite a lot with the clipper tool. I naturally tried to fix the error by removing the whole structure (after trying to simply tidy it up) but that didn't help. Of course it could be that the section has got nothing to do with the error.

Anyways, what are portals and define "non-vis-blocking brushes"? Solid brushes you cannot see?

To optimize a map for performance, Q3 does a few things to cull (remove) polygons that can't be seen by the player. Without any culling, every single polygon is drawn at the same time, even if it's a polygon on the other side of the map that you can't visually see. It's still being drawn, just something else is being drawn on top.

To reduce this load, Q3Map2's -vis stage creates an index of what you can and cannot see from your player's position by dropping in a bunch of "portals" between brushes. If Q3Map2 has to create portals for each face of each brush in your map, sometimes the amount of data is overwhelming and you hit some sort of barrier. A lot of smaller brushes used as details and trim in the map are generating portals even though they don't actually help in hiding polygons in the next room over. These are inefficient and you will want to omit these brushes from creating portals.

To control which brushes create portals and which ones don't, we have two kinds of brushes that convert between each other, "structural" and "detail" brushes. We say that structural brushes "block-vis" because they generate portals during the -vis stage of compiling. Detail brushes are omitted from the -vis process. Generally speaking, large walls between rooms should be structural (default), any kind of details, trim, etc. should be converted to detail (select brush, right-click, make detail).

Read up on the caulk-hull method, and see the link above as well as the other articles I've linked in the tutorial. Maybe start off with Q's Sample Map tutorial.

Okay, I read some of that big topic you wrote about portals and such. The problem is that it deals with a small area that's easy to deal with. I think my problem is that the level I'm working on has a pretty big outdoor area.

Anyways, today I started turning structural brushes into detail brushes. So far it hasn't worked but I'll continue doing it. I remain skeptical because, as I said before, I tried removing a whole bunch of brushes and it didn't work either. I mean, if I was able to build 1000 brushes without any trouble but then the level started giving me the error at 1020 brushes and I remove at least the last 20 brushes the problem should go away, right?

I loaded a .prt file and it's a mess.

I noticed that if I convert a structural brush that's next to nothing (the grey area) into a detail brush I get a leak. Okay, but how does it affect if I convert a structural brush between two rooms into a detail brush? What's the loss? (Notice that I can't really check since the error prevents me from processing the light phase - I can only do VIS & BSP.)

Generally speaking, should a structure like this that's made of structural brushes turned into detail brushes (along with all other details in the picture):

It's not an issue with the total number of brushes in your map, it's the amount of portals that those brushes are creating. As you said, your .prt is a mess. You can certainly have more than 1000 brushes, you just have to make most of those brushes detail so that they don't create a million portals.

The term "detail" is perhaps a little misleading, it doesn't refer only to trim, but also to anything that isn't helping as far as blocking vis. That entire platform structure, pillars and bridge can be converted to detail.

What portals do is that they limit what is drawn and isn't drawn. If you do /r_showtris 1 in the console on a completed map, you'll see that other rooms on the other side of the map will pop in and out of view depending on your location. By preventing entire rooms from being drawn by the videocard, you get a significant performance boost as opposed to drawing everything all the time. The flip side is that if you have too many portals, you can run into issues. So we control this by converting stuff that isn't beneficial to blocking your visibility by converting them to detail so the compiler can ignore the surface during the -vis stage.

For example, those columns and platform isn't going to do anything as far as hiding any geometry behind it, so you might as well convert it to detail. That wall on the right with the door on the other hand will probably block the player from seeing the contents of the next room over, so leave that as structural (or if you're nifty, convert to detail and add a structural caulk brush behind it).

If you want, you can post the map here and I'll see if I can sort through it to see what's going on and give you a few examples.

obsidian wrote:It's not an issue with the total number of brushes in your map, it's the amount of portals that those brushes are creating.

Yeah, I got that, but at some point as I created a brush number 1001-1020 (or something like that) some of those 20 brushes caused the portal amount to go above the limit so if I remove the last 20 brushes shouldn't the excess portals get removed along with the brushes?

If you do /r_showtris 1 in the console on a completed map, you'll see that other rooms on the other side of the map will pop in and out of view depending on your location.

I checked and there are spots where almost everything gets drawn despite the fact that you really can't see the whole level even though the level is pretty open. I read here (and in that topic of yours) something about hint brushes. Could they be used to block visibility?

What about this "caulk" thing that was mentioned in the topic?

If you want, you can post the map here and I'll see if I can sort through it to see what's going on and give you a few examples.

I may do that but the level uses mostly third party textures so do you need them too?

caulk is pretty critical for Q3. textures/common/caulk. Use it on all unseen faces.

Hint's themselves don't block visibility, they are a way to manually create new portals.

If there aren't that many other textures, zip them up with the map. Otherwise, don't worry about it, it's not hard to retexture everything with a dummy texture just to view the brushwork.

I got it to compile. I converted all your brushes into detail and then added caulk behind major walls. What this tells me is that you have too many odd shaped structural brushes, some not entirely on a decent grid size and there is quite a bit of overlapping structural stuff and I think a few co-planar surfaces that is probably giving the compiler some grief. Both -bsp and -vis took less than a second to compile. -light takes a while as expected, but it did complete without errors.

If you map "clean" there's no reason why this map wouldn't compile. So a few tips:

• Keep your structural brushes on a fairly large grid size (~32 units depending on the usage).
• Keep your structural brushes down to a minimum and only place them in places that will help vis/stop leaks.
• Minimize overlapping structural brushes and especially textured co-planar structural faces (Q3Map2 hates these).
• Caulk, caulk, caulk. Everything that is solid, but you can't see, use caulk. I see you've used nodraw on a lot of faces. Don't do that. Use caulk. Use nodraw only on things that don't block light like windows and grates. I generally texture the whole brush with caulk and then manually texture only the faces I can see.

obsidian wrote:I generally texture the whole brush with caulk and then manually texture only the faces I can see.

Rule no. 1!

Thanks a lot dude. I converted pretty much every brush that doesn't touch the void into detail and it works now. I also started using caulk on non-visible faces and compiling is a lot faster than it used to be.

Still I find it a bit strange that this error appeared all the sudden and wouldn't go away until nearly every brush had been converted.

Btw, what kind of rules there are for using caulk brushes to block vis? For example, does it matter at all if they overlap detail brushes?

Anyways, before:



And after:

Caulk is invisible but does block light. Overlapping with detail is fine and is often times encouraged (if using the caulk-hull method of building).