Quake3World

I can see a part of my level through the sky box in another part of the level. Is it possible to block this? Apparently there is just enough height difference to let the top of 1 area "bleed" thru to the other.

I run into that pretty often aswell. Would be interesting to find a workaround.

I usually put nodraw on the faces that don`t point towards the playing area, which usually fixes this problem quite easily. I think blocking the brushes with caulk could work too.

You want a seperate caulk brush on top of your sky brush (even if the sky brush has caulking on the outer face, like it should, it won't fix this issue as it needs a seperate brush that is fully caulked).

This is by design, if you are on one side of a building, it's logical that you would be able to see the other side if you were on the opposite side of it.

Ideally, you would be able to just block out the backface of the building to make it look like it's the opposite side of the building.

And also it is because of bad VIS creation. You probably didn't do that, or try to recompile with differently placed HINT brushes. Because there is no other way how to block it (caulk is not solution - without VIS it is transparent).

I had a similar issue a few years ago, and ended up using an antiportal for one spot, and a portal surface with a camera pointing at my skybox for one other area (antiportal was impossible to use in said spot). Antiportals are very tricky to get right, however.

I've also had this problem a few times, quite annoying.

@Noruen: Could you give an example on how one should place those hint brushes?

@obsidian: While that is true logic is not important for many things in level design imo. And if you block it out (that's what I always did to "solve" this problem) you are forced to have a large skybox and thus very long compile time. Sometimes all you want is a tiny window with sky behind it but players can see the rest of the map through it which is really annoying.

I mean just map out the backface of the building, you don't need a skybox any larger than normal - you can still isolate each area with brushes with a sky shader, thus compile times and performance is the same. I know that there are circumstances where being able to just hide a portion of the map however illogical is preferred, I just wanted to point out it might be easier and better looking if he were to just create the backface.

This may be of some help:
viewtopic.php?f=10&t=38399

My understanding of antiportals is that it creates a bsp split, just like hint, only it blocks visibility between the newly created sections as though you had put a solid wall there. A simple test is to create a box map and then stick an antiportal right in the middle, splitting the room in two. When you are in one half, the far wall will disappear (since it is located entirely inside the second leaf), and when you move to the other half, the far wall in the leaf you were just in will disappear (the situation is symmetric).

The sky bug (if it can be called that) is pretty well known.
If you have two separate areas with sky brushes as part of the separating geometry, both within the same bsp leaf node, Q3 will try to render the geometry of one area whilst you are in the other. As Obsidian pointed out, in many cases this is logical, but in others it isn't. The problem is compounded by the geometry often being incorrectly drawn as a result of culled faces.
As already discussed there are some work arounds. The best approach is to build with block size in mind so that this problem can be anticipated. Quite often reducing _blocksize is the easiest option as it increases the likelihood of each area being inside a separate node.
Building geometry that blocks the player's view of the problem is also a useful work around in certain situations.

What is _blocksize and how do you reduce it?

_blocksize is the variable that controls the compiler's default BSP splitting. Basically it creates a split every _blocksize units from the origin on each axis. This is a worldspawn variable. Setting it to 0 will turn the splitting off.

The problem with blocksize 0 will be exactly the reason why the command exists. Too much brushes inside one portal will cause performance drops (I wonder if it happens only when you shoot, as it's the collision calculation that causes the drops).

Changing _blocksize values can either help or ruin performance. Handle with care. It's best to actually know what's going on rather than setting random values and pretending that it helps. It's possible to disable _blocksize and use hints completely, but that assumes you know how to create really optimal hints. In most cases, it's best to leave it on defaults. If you're going to play around with it, check your compile log and load your .prt (or use -debugportals) to see what's going on.

I'd rather waive the window.

But thanks for the clarification.