you should never need to test nightmare or find a way of making it easier, it's supposed to be fucking hard :P 

not only should stuff be "on grid" meaning on the 1x1 grid, you should also build stuff so that it fits on the higher grid levels when possible. So if you have a 32-unit-thick wall, try to align it to the 32x32 grid. If you add an 8-unit-wide railing, try to align it to the 8x8 grid.

As for overlapping brushes, this is fine BUT the thing to avoid is having things overlap slightly, when they could just touch perfectly. So if you have two brushes side-by-side, don't just put them so they overlap by 3-5 pixels, make the edges actually line up flush. This is mainly for the same reason as the previous paragraph about aligning to the largest grid size possible. 

What is that information on grid alignment based on? Is that a gut feel thing, or is there a technical foundation behind it?

I'm not challenging you, but I've heard a lot of level design advice over the years that is basically couched in "this is the way I learned to do it". Well, great, but if there's no QBSP related reason to do it... :) 

Mostly gut feel, based on what i've seen, what i know about qbsp, and what i've absorbed from others. I think you are correct to challenge this advice as perhaps more "mapper lore" than solid fact.

Scientifically, i would have to make an entire map the "messy" way and compare it to a "clean" map to have any evidence that it mattered.

But, since brush faces determine BSP planes, it seems plausible that it would make a cleaner BSP if there were fewer unique planes and more nodes that cut along the same planes.

I can say from experience that maps with more orthogonal brushwork compile faster than maps with many angled planes, since i've done both of those types. And i see more (seemingly) extraneous face cuts in areas of maps that have a lot of non-orthogonal brushfaces.

I can also say from experience that when two nearby brushfaces are parallel but not coplanar, it is more likely to create additional cuts on nearby faces. (presumably because if they are coplanar there can only be one cut on nearby faces since there is only one plane.)

Qbsp does do a decent job of merging neighboring faces when it can, this mitigates the problem in terms of raw poly count, but i believe the extra bsp complexity is still there.

More facts on this topic would be useful. On the other hand, I have heard that even John Carmack has been suprised to hear certain results (such as the reported finding that 64-unit walls produced better vis than 32-unit walls.) [citation needed]

In terms of "advice to a newbie" i still feel better advising 'clean' brushwork, since it is proven successful, rather than 'messy' brushwork, which might be harmless but i don't think has the same track record. 

I spent about 1 week making a small test map in ut2k3, for a job application. I built everything the quake way, all clean and lined up on a grid and flush with each other (though of course i used the subtractive brushes to make the initial rooms and some of the smaller alcoves.)

... and had all sorts of headaches with compile errors, geometry errors, etc!

Then i opened up one of the ut2k3 maps in the editor to see how they did it. What i found was: 1. there were only about 15 brushes in the entire map (rest was static mesh), 2. all the brushes were subtractive, 3. and they were all random sized, non powers of 2, off-grid, and slightly overlapping! And of course it compiled perfectly.

I ended up getting a job on a Q3-engine game instead, so it all worked out in the end. :) 

Haha, yeah, we rarely use BSP for anything these days other than floors and the occasional wall. Everything else is meshes. 

really like the term "mapper lore". 

n 

I finished a map two years ago. It was broken and ruined with brushes used on all gridsizes.
When I realized I could never get a clean bsp, as the map started leaking and homming like a rascal, I decided to start again.

I compiled everything clean on grid. It was a repetive thing to me, but to my surprise the map rounded out good.

Then I decided to add a terrain map, which was a construction of triangle brushes ending up in sloped edges. Apart the map compiled well.
When I added the terrainmap I had to realign all brushes to fit them on grid.
And this broke up all my smooth pathway, but it worked. 

It's just good practice to keep stuff neat and orderly. 

please 

but now my smooth terrainmap only imports on rougher brushes by marking all on grid. Or I could ignore warnings.

Ricky.., you played the map. More or less..,
https://homedrive.ziggo.nl/gimli@home.nl/publiek/gimli30.htm

Is there something to do about model skins that keep get mirrored?
I broke an evening to get me a good baseframe,
and now it keeps removing front with backparts. 

http://members.home.nl/gimli/gimli30.htm 

Is this really a MadFox map?! Looks neat.
Though I suggest you change the texture on the railings to something without rivets, a simple brown or gray metal. 

Looks great, MadFox ! 

Railings are dxf files which have no shadows, same as the hillslopes. This makes lighting a little tricky seeing the clear dxf file near a brush. Could have another texture but the hexen2 wad is rather bloomish.

My concern is that the middle low pix is a sloped pathcorner around. In the testmap the pathcorner was well closed, while in this map it suddenly shook all brushes in it.

I had to use "force to grid" for all and now it has more of a stairway. But I wanted to make a map once whith all brushes integer.

When two maps with both integer brushes is put together, is the need to replace the imported brushes back into integer origins normal? 

Is Hammer 3.5 the one that can be coerced to work for Quake1 editing? I can't keep it straight anymore. 

Its the same thing really AFAIK.

Although I have heard of someone using Hammer for Quake ........ 

Is it the same?

OK, if not, where can I get 3.3?

And once I get it, do I need to do anything to it or will it "just work"? 

i'm using hammer 3.5, with out that fecking texture trouble off of WC3.3 

Cool! So I install 3.5 and then this QuakeAdapter thingamaroo and it's all good? 

You need to convert the wads though. It's semi automated - have to put them in the right folder. 

VeniVidiFuzi

is an awesome name :D 

This was discussed above, I know, but I need to ask again since none of the solutions up there are working.

I installed Worldcraft 3.3 and did the QuakeAdapter stuff. It loads up and seems to work but I can't select anything in the 3D view. I don't see anything about hardware acceleration in the Options dialog box so I'm kinda stumped.

Any ideas? 

Ahh, found this note in the help file:

"Note: if you are familiar with previous versions of Worldcraft, you may note the absence of the Hardware Acceleration checkbox. Worldcraft will now always attempt to run in OpenGL mode, and if that isn't available through hardware, it will attempt to emulate it in software."

Buh? Now what do I do? :-/