antiportals

[jal_]

Anyone has a link to the details of the use of antiportals? I know what they are and I really want to start using them, but lack the most basic info, and I can't find it.

Thnx in advance.

[spookmineer]

Googled it, found it here heheh...

Topic: Antiportal

The last 2 posts in that thread seem useful.

[jal_]

Antiportals cannot be visible in playable space or they will give you the nasty HOM effect. You must bury the antiportal faces of the brush inside of detail and/or structural brushes.

Hmm... if they have to be hiden inside brushes, what's the point of using them. The brushes can be made vis blocking themselves. Is this information really correct? Cause if it is, I think I'll pass and create an entity to close an areaportal based on the viewer distance to it.

[fKd]

ya use em for doors and shit

[GONNAFISTYA]

The antiportal (or areaportal? ...it's been a while) is "turned off" when the door opens, therefore you don't see the HOM effect. Once the door is closed, the portal enables, blocks the vis into the next area and is hidden within the geometry...all you see is your pretty door. A function_door doesn't block vis, therefore you need the portal.

Antiportal brushes should be fairly thin (obviously for fitting inside doors) and should overlap into the hull geometry (outside hulls). You can of course make the portal flush with the geometry but it doesn't hurt to sink it in 1 or 2 units.

You really only need the areaportal if you really want to block vis into the next room. If you're having trouble with framerates, areaportals can help control the r_speeds from room to room (of course they're useless when the door is open) but if you don't need to lower r_speeds in an area from room to room, don't bother using them. They're just another way to break up your level into bite-sized pieces the renderer can handle.

[ix-ir]

Anti-portals in doors block specs flying around which can be irritating. The framerate hit when the door opens is also a very bad thing, it's better to design the corridor to naturally block vis with a corner.

[GONNAFISTYA]

Anti-portals in doors block specs flying around which can be irritating. The framerate hit when the door opens is also a very bad thing, it's better to design the corridor to naturally block vis with a corner.

[jal_]

The antiportal (or areaportal? ...it's been a while) is "turned off" when the door opens, therefore you don't see the HOM effect. Once the door is closed, the portal enables, blocks the vis into the next area and is hidden within the geometry...all you see is your pretty door. A function_door doesn't block vis, therefore you need the portal.

That's areaportals.

We are talking about ways of forcing map areas to be blocked when they are not visible but q3map2 has no ways to block that vis. Quake's were designed to be indoors so vising is optimized for corridors, and it fails on more open enviroments.

This is not for "fixing" a bad designed map, but for implementing a way of correctly culling open maps.

[a13n]

as long as players are not allowed to rocket jump over antiportal, right?

[obsidian]

I haven't gotten antiportals to work quite right yet. I still keep getting HOM in funny places in the most unexpected ways. If I ever find out, I'll write about it. Right now, it just seems to cull everything behind it causing HOM. Sometimes, it'll work but then cause HOM elsewhere. It's rather unpredictable so I can't troubleshoot exactly what I'm doing wrong. I'm on vacation and not at home so I won't be able to write in any more detail than that. See the link posted above, I was asking the same thing and I think I linked to the document written by Raven.

[jal_]

I was once given a link to a small article made by the ETF team. The explanation wasn't complete, but it seemed like they were succesfully using them. Unfortunately, their site seems to be gone and I don't find that article anywhere else.

[Raven]

Ydnar made these for very specific reasons and they are a bit touchy. If you lined the antiportal up with any structural splits or the 1024X1024 grid splits it will HOM. You have to make sure it is not lined up with any structural splits already in the map.

[ix-ir]

I played around with these and think I have them figured out. To understand you need to bone up on your leafs and portals again. Basically a leaf is one of the convex volumes created in the vis process, the results of which you see with: Plugins prtview Load .prt file

An antiportal texture creates a plane (so you can use a small brush, it's not like clip) that extends until the edges of the leaf that contains it. So if you have an x/y axes antiportal texture, imagine that expanding until it hits the edges of the leaf it's in in the x/y axes.

We'll start off assuming you're standing in the same leaf as the antiportal. The antiportal is double-sided with only 1 application of an antiportal texture face. Hall of Mirrors just means the engine has nothing to draw, antiportals do not inevitably cause this and once you understand them you can avoid HOM. The leaf is divided into 2 halves by the antiportal plane. Imagine the left half of the leaf contains you and a little crate made of detail brushes. You can see the crate. If the crate were in the right half of the leaf you could not see the crate. If you move into the right half the crate will appear.

Now where can you see the antiportal from and when does it cull? Imagine the antiportal in the x/y axis - extend it up lots and down lots in the z axis so what was a 64 unit by 64 unit square is now 64 by 64 by infinity. There are 2 conditions for something to be culled. One you must be standing in a leaf that's entirely contained by an extrusion of the antiportal's plane, otherwise nothing is culled. Second - only things that are in a leaf (including the leaf containing the antiportal) on the other side of the antiportal that's entirely contained by its extrusion are culled.

This is a little hard to get your head around and I've probably not explained it well. I'll possibly do some pics and example maps at some point. Here's a taster:

http://www.filedropper.com/antiportal2

To explain what's going on - I've made the map so it contains two kinds of leafs, the hint brushes forming the leaf shapes. Short ones and tall ones. The leaf containing the antiportal cuts the whole lower level of the map. If you are in a short leaf the things in short leafs on the other side of the antiportal are culled. If you are in a tall leaf nothing is culled. The antiportal is roughly in the middle of the room but is limited in height by a leaf cut, if you jump in a short leaf you will see the culled things reappear as you enter a tall leaf above you.

The stairs are a tall leaf so you will see nothing is culled (and the stairs are never culled as their leaf is bigger than the antiportal leaf) when you stand on them. The chrome pillars are in short leafs so will be culled when you're in a short leaf (the area around the stairs). The lava pillars are in a tall leaf so never culled. The antiportal is just beyond the stairs and culls the first chrome pillars which are in the same leaf as it. It also culls the 2nd set of chrome pillars which are in a seperate leaf that's smaller than the antiportal leaf but ignores the middle lava set because their leaf is too tall.

obsidian: your test map is doing exactly what you'd expect given the way the portals are set up. To fix it you'll need to hint so that the antiportal is lower in z than the end walls so it doesn't cull them, then make the middle corridors higher in z than the antiportal so they're not culled as well. Even that's a bit funky because players will appear and disappear while in view in the corridor. Without massive messing around the best fix is to put the corridor out of the extrusion of the cull - above, around or below.

For reference (my skip shader was initially incorrect):

// ydnar: antiportal works like hint, but suppresses portals
// add this to your common.shader file
textures/common/antiportal
{
qer_nocarve
qer_trans 0.30
surfaceparm nodraw
surfaceparm nonsolid
surfaceparm structural
surfaceparm trans
surfaceparm noimpact
surfaceparm antiportal
}

// ydnar: skip works like quake 2 hint: it doesn't generate bsp splits
// use on sides of hint brushes where you don't want bsp splits or portals
// add this to your common.shader file
textures/common/skip
{
qer_nocarve
qer_trans 0.30
surfaceparm nodraw
surfaceparm nonsolid
surfaceparm structural
surfaceparm trans
surfaceparm noimpact
surfaceparm skip
}

[jal_]

nice job ix-ir. I'll try that.

[wattro]

yup, great deductive work and experimentation. it makes sense as you have described it.

nice job!

[sock]

Ydnar made these for very specific reasons

During the development of RTCW:ET we had area's of the map which were seperated by sky brushes buried into large terrain brushwork. One specific area is the sky brushes between the two main sides of the Fueldump map. These sky brushes would often leave shadow artifacts on the terrain and it would look ugly. We needed a brush that would split areas but would not affect the shadow map. Unfortunately due to time limitations we did not have a chance to implement antiportals between the map area's.

Sims

[ix-ir]

Having messed around with antiportals further I'm struggling to figure out any use for them. You're doing something wrong, even on an ET-scale map if you're hitting vis limitations. Normal hints can solve that situation you list sock without needing a separating skybrush, maybe I misunderstand the situation as I'm sure you know how to do this already. The process of making sure the antiportal will work where you want it to will usually generate as many bsp cuts as without and often looks identical to me.

[ydnar]

Hi,

• A Hint face dynamically blocks visibility without affecting physics..

• An Antiportal face statically blocks visibility without affecting physics.

Like Hint, Antiportal lets you create a specific BSP split. Unlike Hint, the area bound by the brush face does not create portals between the leaves on each side of the split.

The most simple test for this is to create a single box room, and place a brush bisecting it in the middle with 5 sides of Skip, and one side of Hint. When compiled, this map will look normal—you can see and walk from one side to the other. If the Hint face is changed to Antiportal, then that face will block visibility, but not affect physics/motion.

Historically, Areaportals were created by applying the Areaportal shader to all 6 sides of a box brush. At some point during the development of Q3Map2, the preferred method was changed to use 5 Skip + 1 Areaportal faces, similar to how Antiportal is used.

Randy

[a13n]

Hi

Hi.

At some point during the development of Q3Map2, the preferred method was changed to use 5 Skip + 1 Areaportal faces, similar to how Antiportal is used.

which means a "5 Skip + 1 Areaportal cubic brush" is equivalent to the one on which only antiportal is applied?

[Grenader]

Duhhhhhhhhh ching ching woia.

[a13n]

Never mind.
I got it wrong.

[Quack]

antiportalTest.pk3

File contains working map, bsp & aas file. Single structural hulll 2048x2048x576, everything else is detail brushes, antiportal, skip or hint. Added a few entities and spawns so you can test with a bot. It seems like the antiportals can be further optimized with proper placement and carefully added hint brushes.

The antiportals work where they are placed, but I worked on this for a few hours with different degrees of success. Not so much because the antiportals weren't working, but because the placement of the antiportals, and the resulting vis data that the antiportals were trying to block was not properly optimized. I don't know a lot about antiportals, I remember working on this years ago with no success. Hope the map file isn't too difficult to understand. For now, I need to take a break before my head gets sucked into the portal void

[obsidian]

Thanks, haven't had much time to look at this, but bookmarked. Antiportals have bugged me for a long long time.