Quake3World

Bad brush in there or could it be something else?
There is no obvious bad brush anymore but I had an ad-infinitum brush in one instance that I was able to mark and delete within 1.6.3. Maybe some leftovers in the coords from that one brush?
What can I do? How do I find that brush plane with no normal? The map is nothing fancy at all, really. Nothing's off the grid. So, I am kinda confused by this.

Don't you have some zero width brushes in your map? That might cause the problem...

Start deleting until you find the issue =)

Try to select your whole map with a giant "select inside" brush und copy it over into a new map file. Don't forget to turn everything on like: clip, hint...

sst13 wrote:Try to select your whole map with a giant "select inside" brush und copy it over into a new map file. Don't forget to turn everything on like: clip, hint...

You're mixing German with English? Good point, btw

sst13 wrote:Try to select your whole map with a giant "select inside" brush und copy it over into a new map file. Don't forget to turn everything on like: clip, hint...

That did it. Had forgotten about that way. Thank you sst13.
What is causing it, though?

As I said, it may be some null width brushes (which appear invisible in your map and can't be selected without selecting all in your map using keyboard shortcut instead of very large brush). But this brush can cause a serious problem as nothing can have zero volume (unless it's a patch, that is one-side clipped, instead of a brush) and compiler doesn't know how to create a volume in that zero wide brush (especially when it's meant to be solid) and how to split BSP tree around that zero volume. Eventually you'd find yourself blocked by an invisible barrier somewhere in your map if that would be possible. So that's the reason why it happens. If you're using GtkRadiant 1.5, then it's no problem creating zero wide brushes even when you edit some (making a zero wide brush from a normal solid brush by overdoing shrink). That's also good reason to use latest version of GtkRadiant (or earlier, if 1.6 doesn't work for you - may be true on older systems like Windows XP where Radiant 1.4 works like a charm).

CZghost wrote:some null width brushes

.

I was expecting something like that from when I got the error. But there couldn't be any. Cause the map is not fancy, every brush is on grid 2 at least. I thought maybe there is a fix to that nowadays.
sst13`s work-around did the trick.
Without many words, do you have a solution for this bug?

I can't tell from no informations. It may be also duplicate planes, which creates exactly the same volume in another volume and may cause troubles. You can imagine pouring a one liter water and pouring another one liter water while preserving the one liter. It's impossible. And it's liquid! So you can't overlap two solid objects. That's why overlapping brushes are problem in Quake 3. Compiler creates extra BSP plane splits and volume gets computed incorrectly. One or few small sections don't matter, but when you overlap many brushes, it significantly slows down performace. So beware with using too much decals somewhere. For duplicate brush planes, there's just one not so simple solution: try to avoiding duplicate brush planes as much as possible. Especially with structural brushes. If you must have for some reason overlapping brushes (or even duplicate planes), make the second detail. That way compiler will take these in different stages and won't affect performance much. All clipping brushes must be detail brushes (you can filter detail brushes by Ctrl+D shortcut to see, where detail brushes are - they will simply disappear and you'll see only structural brushes, patches /which are always detail/ and entities). Clipping brushes are those entirely textured with commons/clip or commons/weapclip texture, which appears invisible in game (brush faces with these textures do not render at all).

So in short: there's no simple solution, but try to avoid zero wide brushes or duplicate planes as much as possible. Make sure that decals, (tiny) brushes that do not alter or create some major structure in map, clipping brushes and other content brushes that do not affect geometry or render (planar splits, vis blocking, lightmap) are actually detail brushes. And for major structure brushes, all brushes altering render and/or geometry, brushes sealing everything else from void (IMPORTANT!!!) are structural brushes instead.

Ferrao10 wrote:Without many words, do you have a solution for this bug?

Sometimes brushes collapse during weird vertex/edge editing. Shit happens...

At least you can inspect the faulty brush in a text editor.
Simply delete all the other brushes & entities by using the "select inside" methode again. Save the map under a new name. Now the faulty brush should be the only one left in the map file.

Wall of text against simple Bamm. Loving it .
Yeah, so probably I did accidentally vertex-edit some already problematic brush. Undid, bug happened. Got toasted.
The faulty map is gone, I'm afraid, no back-tracing possible. Saved the new (clear) map under the same name. Because the old was broken anyways.

Cheers.