If you're having trouble with clipping errors in your Q1 map (player walking/falling through solid brushes), you might be interested in the following procedure.

Compile the map with one of my compilers (http://user.tninet.se/~xir870k) and add the options "-solid" and "-hull 1". The first one just disables all liquid brushes and makes the sky solid and the second makes the player clipping hull visible. The build time will probably be longer than usual.

Then load the bsp into an engine, turn on gl_clear 1 in the console and noclip around in the map. Don't worry if the map looks a bit different than usual, all brushes are expanded a bit so it will look rather cramped at places.

If you notice something that looks like a HOM effect, then that area is likely to have clipping errors. After identifying the problems spots, inspect those areas carefully in the editor. There are probably some brush misalignments there. When the HOM effect disappears, the brushes are OK. 

When will you add the negative lights support in your light tool? 

I'll have to give this another try when I get my editor back up and running.

Note that 'gl_clear 1' will turn off the HOM effect and you'll just see a solid colour instead (red in normal GL Quake, void grey in FitzQuake/TyrQuake) 

As you already know, I've had this option for quite some time but I just discovered a couple of days ago this connection with clipping errors.

Normally one has to tediously move around in the map bumping every wall to discover the nasty clipping errors. This really helps in that process.

I must point out though that there could still be clipping errors even if there is no HOM, so it's no Magic Bullet.

PuLSaR: Sorry, no current plans on Antilights. 

could this be used to find spots where a player will get stuck on the joints of a 45� ramp? 

because one big reason for clipping errors is two or more brushes that meet in a non-axial manner and that are also not aligned properly.

I'm right now trying to use this "feature" on a large number of maps that I've had problems with to see how it can help finding spots that the compiler apparently has some difficulties to handle.

Typical causes are very tiny brush gaps, overlaps or faces, either directly on the proposed brush or in an adjacent one. Most of the time it's in a non-axial junction.

But as I mentioned above, it doesn't catch all cases and it's certainly no guarantee that there is an obvious problem spot where the HOM is found.

Still, I find it a major help in tracking down these evil map-traps. 

#935 posted by necros
>if you already have a map in there, then turn off floating point, quark simply rounds all the coordinates to the nearest integer. so you get lots of hairline fractures and offset brushes.

Thanks all, this will help.

> aguire made a pretty cool program that attempts to correct most of the problems that you get from converting floating point to integer coordinate maps. it's not completly succesful -- you'll still need to fix a few brushes, but for the most part, it saves tons of time.

I didn't see it on:
http://user.tninet.se/~xir870k/

Where is it?

as 

It has several conversion/fixup modes, but its original purpose was what necros mentioned; to convert a float map into an integer one with as little accuracy loss as possible. Check out the readme for details.

But if you use QuArK, I'd recommend that you don't disable float coords in map file, you'll just end up in Qoole hell. Load the decompiled map file into QuArK, roll up your sleeves and start the repair job (it might take a while).

Also, notice that there are many compiler warnings that you can safely ignore. 

I've now gone through a lot of maps armed with the -solid and -hull 1 options, looking for HOMs and thereby clipping errors. I find it very useful because there are normally not so many of them, so you can easily go through them one by one, checking if they're worth fixing.

Some maps can't be built this way right now; when loading the bsp, the engine aborts with a cross connected doors error. I suspect it to be two normally separated doors that melts together in hull 1.

In the next version of my compilers, I hope to have an option -noents that removes all entities from the map except world and players. This takes care of the door problem and furthermore, it makes it a lot easier and faster to navigate the map (especially a big one).

No more worrying about monsters chasing your tail, triggers that set off in your face or you accidentally stumbling into a teleporter or change_level portal. Freedom at last ...

Checking the map visually in hulls 1/2 also has another unexpected bonus. If your map is big and you're close to the max clipnode limit (32767), you might find that large parts of the map are not filled in hulls 1/2 due to brushes melting together.

With some simple modifications, you might be able to fill those areas and thus lowering the # clipnodes significantly without changing the appearance at all. 

i'm still not quite clear on what it means to compile with the hull1 or whatever... how does that relate to clipping?
*confused* 

someone would ask ...

Every Q1 map has three hulls 0-2. Hull 0 is what you build in the editor and is normally what you see in-game. This visual hull is not what the player (or other entities) is "clipped" against, i.e. checked for collision so you can "feel" the wall.

This is due to speed reasons, it's easy to clip a point sized (infinitely small) entity like a rocket against hull 0, but for bigger entities like the player, there is a bounding box around it that defines its volume in space. When Q1 was made in '96, it was probably considered too processing consuming to clip the entire bounding box against hull 0 in the game engine so another solution was made.

If the qbsp compiler would, instead of just building hull 0, automatically build two other hulls (1 and 2) by expanding all brushes in hull 0 outwards the same distance as the bounding box for player or shambler sized entities, it would be much easier for the game engine to clip the bigger entities. It then only has to clip the mid-point of the bounding box against one of the other hulls to see if they collide. This is the same thing as clipping a point sized entity against hull 0.

So each time you look at the compiler output, you'll see something like Processing hull # three times. This is when the compiler builds your map, first the normal visible hull, then automatically generating hulls 1/2 by expanding the brushes in hull 0. The end result is three separate hulls in each bsp that the engine will load and use while playing.

What I've done via the -hull # option is to trick the compiler to build hull 0 the same way as it does for the other hulls, by expanding the brushes a bit, thus making one of the other hulls "visible". First I did this for educational purposes, to better understand how a bsp is built and, like you, get a clearer picture of what these other strange hulls were.

I didn't know then that by inspecting the map in the shape of one of the other hulls, you might use certain visual anomalies (like HOMs) to identify areas with problems. After identifying the area, you just make a closer inspection of that area in the editor and hopefully find the cause of the problem (typically some kind of brush misalignment).

If all this still seems confusing, just build one of your own maps (preferrably a small one) using the -solid and -hull 1 options and load the bsp into an engine and I'll think you'll understand better. 

thanks for the explanation!
very useful :) 

i just tried hull 1 thingy on my map! oh my! it looked like bloated dungeon of fat evile! :) it was funny :)
and it's indeed useful, ispecially when you're not sure if player is able to get into some area, this option helps very much.
yet i've found the reason of weird clipping behaviour in some place thanks to this.

thanks again, bengt :) 

i just tried hull 1 thingy on my map! oh my! it looked like bloated dungeon of fat evile! :) it was funny :)

Yeah but what did it look like *with* the hull 1 option? ;-p 

If you think your map looked fat evile in hull 1, try hull 2 instead. Sometimes, the whole map melts together into a real mess ...

Fixing things in hull 2 only helps shamblers and the like, not as important as the player.

There is an interesting thing regarding the various entity sizes. I have many times noticed that scrags and spawn seem to be able to sometimes move through solids, very annoying when fighting them.

I haven't confirmed this, but could it be that they are in fact point sized entities, so the smallest crack between walls will let them through? Or is there another reason? 

i've noticed the scrag problem myself. it would happen sometimes in nesp09, in the underground lava cavern. the scrags would spawn by the falls, and would sometimes clip right through the wall into the cave. it seemed to happen when there were a lot of scrags bunched up, so i just reduced their numbers and the problem went away...
incidentally, the scrags do have bounding boxes, they are the same size as a player entity. so i don't know why this happens.

also, the hull1 hull2 thing explains alot regarding bounding boxes. i could never figure out how the big dragon in nesp06 was able to fit through smaller passageways even though it had a massive bounding box.

thanks a lot for the clarification 

maybe since they're monster_wizard they can turn on their NOCLIP? :) 

sv_move.c:SV_movestep treats normal and FL_FLY entities differently. I haven't time to examine it closely, but it looks a bit odd. aguiRe; see what you think. 

at QC, I've only made some minor fiddling with it. I was just curious whether the issue was related to the entity size but apparently it wasn't. Come to think of it, it probably would be a lot more difficult to hit a scrag with a bullet if it had no volume. 

don't actually use flying thing... they are set to movetype_step... it's confusing. 

i believe this means that the entity moves in discrete steps (becuase of the 10Hz think function) and not that they actually walk on the ground. 

makes sense, i guess. i just assumed it was walking, because there was movetype_fly as well. ;) 

aguiRe - Interesting explanation of Hulls. I learned something. I wonder if my map troubles are related to these offset surfaces. I can just imagine what Hull 1 and 2 look like on my trusses. Bleh...

BTW, I'm vising my slightly improved map. It still sucks. I'm working on the 2nd map and letting your vis program take all my PC's spare time.

I also used the light parameters (light -extra -soft -light 20 -sunlight 150 -sunmangle 225,-30 -sunlight2 40 e2m1a). It does make the map look nicer and more natural. The only drawback is that I lose some cool looking shadows (such as the lifting truss shadow against the rockface) but I think I'm inclined to go with your soft shadows anyway if this thing ever gets done. 

What do I need to do in Quake 3 so that arcitecture won't show up behind skybox brushes. There's a small part of an adjacent roof you can see through the sky in one of my maps, which is culled from some angles but not others and looks generally weird. 

Well if the surfaces you're seeing aren't ever visible by the player, you could caulk them. Otherwise, there's not much you can do.

I don't know how it works technically, but basically the skybox is drawn behind everything in the visibility table. So if VIS does not block Room A from being viewed in Room B, trying to hide Room A with a skybox won't work. This problem was evident in Quake 2 as well (load base1 and noclip to the top of the outside room; you'll be able to see the inside parts of adjacent rooms through the skybox).

The only real thing you can do is use areaportals and hint brushes to optimize VIS, or change the architecture so there's nothing to see behind the skybox (which is not what you want, surely).

I hope that made sense. If not, I defer to metlslime.