Quake3World

Just an odd little thing I noticed.

If you have a vertical visportal, e.g. the standard portal-in-a-door arrangement, the tris in the zone beyond the portal won't be drawn until the portal itself is visible on your screen.

But if you have a horizontal visportal, e.g. you're in the bottom of a well with a portal across the mouth above you, the tris in the zone beyond the portal will always be drawn. Regardless of whether the portal is visible on your screen.

I don't think it has anything to do with horizontal portals. I've used them and they've worked just fine. Maybe you're not totally closing off an area and it is "leaking"?

Hm I've got a similar tunnel situation here but two portals help to cut whats drawn.

two screenshots below. Player is in a bottom room connected via a jumppad that sends you up a tunnel to the room above. There are visportals at the top and at the bottom of the tunnel. Until the portals align as the player moves toward the tunnel the room above is not drawn.


[lvlshot]http://mhgaming.com/forums/portals1.jpg[/lvlshot]

[lvlshot]http://mhgaming.com/forums/portals2.jpg[/lvlshot]

wviperw wrote:I don't think it has anything to do with horizontal portals. I've used them and they've worked just fine. Maybe you're not totally closing off an area and it is "leaking"?

Nope. It's a simple cube map that I was using to test various visportal behaviors.

Edit: If you're curious, I'll put it up for download somewhere in a minute.

Here it be: http://www.neogeographica.com/temp/vistest2.map

And interestingly, here's a slightly different one that does _not_ exhibit the weird behavior: http://www.neogeographica.com/temp/vistest3.map

Later I'll take a look at the bsp output to see if that has anything interesting in it, and maybe snap pictures. Right now need to go damp down some emergencies at work.

Hmm, maybe I'm not understanding you completely. I just tested vistest2 and it seemed to have the correct behavior. When I can see the portal it renders all tris in the region behind the portal (the ceiling) but does not render any of the side rooms. When I can't see the portal it doesn't render the ceiling or any of the side rooms.

Sounds like you understand... but are seeing something different. Weird.

Hmmn. The map (vistest2) works fine for me as well.

Are you saying that the tris in the two other rooms (without the player start) are being drawn for you when you're in the first room and below the portal? If so, that's really weird.

I'd be curious to know what the difference is on your rig, and why you're getting that behavior. You shouldn't be...

pjw wrote:Hmmn. The map (vistest2) works fine for me as well.

Are you saying that the tris in the two other rooms (without the player start) are being drawn for you when you're in the first room and below the portal? If so, that's really weird.

Nope, the other two rooms aren't being drawn, so it's clear that the portal is working in some way. But the ceiling is being drawn even when I am not looking at the portal.

I will take ze pictures!

OK, here is me in vistest2 looking up at the portal. The ceiling is visible as you would expect.



Now this is me with my face to the wall. Ceiling is still visible.



I guess this all comes down to how bsp decides to carve up the portals. If it leaves the visportal face of the "portal brush" as one big portal (rather than only creating portals where it crosses empty space), then technically the extent of the portal is still overlapping my screen here. And in fact it seems like the lower boundary of the tris is a slightly different color... if that's from r_showPortals then it confirms that the visportal face was preserved as one big portal and is behaving as expected.

It's odd of course that it wouldn't do this for you two guys. I would have expected than any bsp decisions about this sort of thing would be deterministic.

Speaking of odd...

So, to test this theory, I split the "portal brush" into three smaller brushes, each covering one of the halls. With this one, if I face directly into the wall, I see nothing. (I'll spare you the big pink screenshot). So that's good.

Oddly though, if I look up at the portal, I see both the ceiling and _also_ the next hall over!



Double oddly, when I took the screenshot the tris from the next hall disappeared, and were no longer displayed!

Ah lovable Q4, it appears that you will be just as quirky as Q3.

Hmm, I just noticed that when I split the "portal brush", it put the visportal texture on the split faces rather than nodraw. I hope that perpendicular touching visportals aren't a no-no ... that would make it difficult to work with oddly shaped spaces. Maybe it's just that two visportal faces on the same brush are a no-no. That's an experiment for another time maybe.

So, I retextured the sides of the "portal brushes" to be nodraw. Now the tris display is as expected. However... if I have r_useScissor turned on (which is normal gameplay mode) and look up into the portal, I see black polygons obscuring part of the ceiling, which slide around as I move. Sigh! They don't show up in screenshots.

That map file is here for the curious: http://www.neogeographica.com/temp/vistest4.map

I shall now go drown my confusion in a Jamba Juice.

Johnny Law wrote:Hmm, I just noticed that when I split the "portal brush", it put the visportal texture on the split faces rather than nodraw. I hope that perpendicular touching visportals aren't a no-no ... that would make it difficult to work with oddly shaped spaces. Maybe it's just that two visportal faces on the same brush are a no-no. That's an experiment for another time maybe.

And maybe that time is now. Might as well continue my forum-spamming while I am on a roll (and fully Jamba-powered).

So, it looks like perpendicular touching visportals that are _not_ on the same brush work much better for visibility control, but I do occasionally see some black flickers in the space. So when iddevnet says

You'll get almost no gain from visportals that share edges, and in some cases doing so can even lead to errors where portals close when they aren't supposed to, which can make parts of the scene flicker black.

it must be talking about _any_ visportals that share edges, not just coplanar ones. Which is probably the obvious assumption but I was resisting it. I can live with that. Next thing I'm curious about is whether the edge from one visportal can touch the face of another. If this is still allowed, dealing with awkward spaces (especially a complex, semi-open skyboxed area) still won't be too bad.

So that the point doesn't get lost in my spammage, I will note that none of this explains the black polygons I was seeing in the last version of vistest4, since there are no touching visportals in that one.

Hmmn. I'm just confused, I guess. It seems (?) like I'm getting the same behavior in your sample maps (except for vis4, which I'll get to in a sec) as I am in any other maps. Specifically, that if any portals are in view (green), then all tris will be drawn in the area you're in, plus any area between those portals and any other portals that aren't in view (red).

Basically you have the area you're in, plus a buffer zone of areas, before you get stuff that isn't going to be drawn. And it seems like I'm getting that same behavior in all your vistest maps?

I was trying to remember the q4 equivalent of lockpvs, so I could take some screenies, but I can't seem to...r_locksurfaces seems to be b0rked (or I don't understand it's use/function). I'll ask about this on Monday.

Re: vistest4, yeah...it was hosed, and the way it was set up, while not the way I would have done it, seems like it *should* have worked. Just for fun, I rebuilt it like this:


...basically with the visportal brush volumes contained within the walls, rather than extending up into the shared space. Theoretically, all those nodraw faces are discarded, and visportals shouldn't have inside/outside, so it shouldn't have made any difference, I don't think. Nonetheless, everything seemed to be happy after the change, with green portal overhead, and the other two red:



Go figure.

Oh yeah, and creating visportals that contact other visportals (edge, middle, whatever) is generally A Bad Thing. You might very well be able to get something to work that way via creative jiggery-pokery, experimentation, and sheer optimism, but I certainly wouldn't count on it.

pjw wrote:Oh yeah, and creating visportals that contact other visportals (edge, middle, whatever) is generally A Bad Thing. You might very well be able to get something to work that way via creative jiggery-pokery, experimentation, and sheer optimism, but I certainly wouldn't count on it.

Well, Hrmph I say!

Okay, let's take that test map and create access between the hallways like so (top view):



The interior walls still don't go to the ceiling so the side view is still like this:



Now, for a player standing at ground level there is a lot of visibility blockage in the structure of this map. But how can we place visportals to make that work, if visportals can't touch?

(This was actually one of the first things I tested before embarking on my current map design. I tried one visportal stretched across the tops of the walls, as in vistest2, and then visportals in each "doorway" that reached from the floor up to the horizontal visportal. That all seemed to work. But if all cases of touching visportals are bad, then I may have just gotten lucky.)


If the ceiling area above the tops of the walls is actually skybox, then I guess one approach would be to make skybox-textured extensions of the walls that reach up to the ceiling. As long as the player is clipped from being able to go up high enough to see any weird effects from that. Then you could use some nice simple floor-to-ceiling visportals.

Otherwise though I'm not sure what you would do. (I can think of some icky solutions with extremely angled visportals which sort of work in this simple test map, but aren't at all useful with real structures.)

Hopefully I'm just dealing with a mental block here that I will feel silly about when someone points it out.

I should go re-examine a bunch of the existing Q4 maps...

Heh. I'm not saying that all cases of touching visportals are bad and won't work...only that the results seem to be kind of iffy, and (AFAIK) we all tried to avoid it when possible.

If your test worked, good for you. Yeah, depending on whether the map design would let you get away with it (and if touching portals behaved oddly), I'd probably use the "fake sky wall" solution. In fact, I had to do something similar in "High and Dry" to make it work. If you look carefully, you'll realize that the "central tower" is, in fact two towers that are seen from the front and back outside areas, and that there's no actual shared visible geometry...

Johnny Law wrote:Well, Hrmph I say!

Hrmph!

Well, so far so good... mostly.

I am in fact able to pull one visportal across the "sky area", and then have other visportals reaching up to touch it. Seems to be workin'.

After doing that, and also throwing a bunch of oddly shaped and angled portals around in the open areas of my map w/o any problems, I figured I'd be home free. But actually I'm now being stymied by two portals that are in the simplest part of my map (visblockingly speaking). Just an enclosed tunnel/hall that I need to pull some portals across. In two cases, such a portal is not showing up in-game when I'm running with r_showPortals 1, which I assume means it ain't there.

There are no warnings or errors in the compilation's console output. (Other than some "node without a volume" warnings when processing some of the non-worldspawn entities, which I believe is normal.) I've examined the edges of the portals to make sure that they touch geometry, and have tried both 1) leaving them rectangular and extending them a ways into the geometry, and also 2) clipping them into the smallest possble convex shape.

I haven't yet tried more drastic measures like surgically extracting the portal with the surrounding geometry and compiling it in its own little map. Before I start mucking with that... any suggestions on how to diagnose this? Is there maybe some sort of -even_more_verbose command line option for bsp?

(Got it figured out... some under-the-floor decorative business causing a connection between the volumes on both sides of the portal.)

Excellent. My next step was going to be asking you to link to the map...