-vis help, Obsidian needed I think

(ACROBAT) #1

Ok, we were runnig a small experiment using _blocksize 0 in the worldspawn. My goal was to make a complex leaf node that kind of stretched outside of the map but you could still see it through the sky. I tested this idea with something far simpler outside loop and it worked fine but when i tried something complex it seemed not to. Because _blocksize is 0 and I have no portal lines being drawn whatsoever other than by structural brushes, there SHOULD be only one leaf node in this entire map. Because there is only one leaf node, players when standing in that leaf node should have a PVS set of one leaf node, and should be able to see the entire map. There are areas that extend out of view but they are covered in sky so they should be viewable.

Keep in mind there are no portal lines in this map other than the structural brushes themselves, and the entire map is connected as one piece, just a 50 sided room or so.

Here is an overview of the setup in radiant . If you look at the upper right picture there is small passageway connecting the main middle area to the outside halo.

Here is a another pic of the small passage way. It was enlarged a bit in this pic because i tried the compile over again but it did the same thing.

To my dismay, after compiling, there were portal lines??? why are they there? Here they are on the 2d grid

Here are the portal lines on the 3d grid

Here I am standing out in the outside halo with detail brushes filtered so you can see there shouldn’t be any portal lines being placed in those hallways.

Here is one last picture. This one is me standing in game looking at the little passageway to the outer halo that should be connecting the entire thing as one solid leaf node. Instead you only see a small section of the halo, and it stops in accordance to the random portal lines that the compiler inserted with telling the compiler to insert (as seen above.)

So we have no hints, no subtle hints, no blocksize automatic lines being drawn, no area portals or anything, but we’re still getting portal lines drawn in by the compiler.

Why is that and is there anyway to stop the compiler from doing that?

(kamikazee) #2

Leaf nodes cannot contain structural brushes. When Q3Map splits the void into nodes, it encounters the structural brushes in the middle and generates a portal to make new nodes which are now in between the structural brushes. (As seen in picture 3)

The same applies in the vertical direction.

If it really should be just one leaf node, put the whole thing inside a box and make everything detail. Mostly I would advise against this “box-technique”, but you actually seem to intend to do it like this.

(ACROBAT) #3

“Leaf nodes cannot contain structural brushes. When Q3Map splits the void into nodes, it encounters the structural brushes in the middle and generates a portal to make new nodes which are now in between the structural brushes. (As seen in picture 3)”

If it had compiled it as one leaf node with about 60 sides, it wouldn’t have contained a structural brush. It would have been an oddly shaped leaf node of about 60 sides or so, which is what I intended to make. However, it’s putting its own portal lines in for a reason I can’t understand. Look at the narrow corridor that connects that two rooms. It’s essentially one giant large room because of the corridor.

(kamikazee) #4

Sorry, I also forget to tell you that the leaf nodes need to be convex volumes. (Brushes, for example, are bounded by infinite planes. So they need to be convex if you don’t want to see the “infinite brush” effect.)

A 60-sided leaf node like the one in your case cannot be convex unless those 60 sides are all outer walls with no structural brushes inside. (For example, a 60-sides brushes created with Radiant, or manually by clipping away corners.) So again, either make the interior detail and round the outer hull, or put it in a box completely if you want to pursue your idea.

Alternatively, if your map consists of nothing more than this area, you could also ignore the -vis compile altogether so all areas are visible at all times.

(obsidian) #5

I don’t see exactly what you are trying to achieve with this. Let me get this straight, you want to create a map with a single complicated leaf node for the sake of faster compiles? Why don’t you just not compile vis in the first place?

Sure, you’ll end up with faster compiles, but in game performance will be horrendous. By the way, you might want to look into portal skies.

(SCDS_reyalP) #6

You might want to check out the following:
http://web.archive.org/web/20051212023108/http://www.planetquake.com/spog/stuff/technical.html
http://graphics.stanford.edu/~kekoa/q3/

(ACROBAT) #7

Sorry, I also forget to tell you that the leaf nodes need to be convex volumes. (Brushes, for example, are bounded by infinite planes. So they need to be convex if you don’t want to see the “infinite brush” effect.)

A 60-sided leaf node like the one in your case cannot be convex unless those 60 sides are all outer walls with no structural brushes inside. (For example, a 60-sides brushes created with Radiant, or manually by clipping away corners.) So again, either make the interior detail and round the outer hull, or put it in a box completely if you want to pursue your idea.

I don’t exactly understand what you mean by convex and concave since Leaf nodes seems square to me and I’ve never managed to see how they can be either concave or convex. I can tell you that the outer halo has a design inside it but that it is a detail brush. The outer halo is connected by a hollow corridor to the main area, which is also hollow. It should be one giant oddly shaped room at least that seems right to me.

I don’t see exactly what you are trying to achieve with this. Let me get this straight, you want to create a map with a single complicated leaf node for the sake of faster compiles? Why don’t you just not compile vis in the first place?

Sure, you’ll end up with faster compiles, but in game performance will be horrendous. By the way, you might want to look into portal skies.

Bascially yes, although I was hoping it would still perform well enough that performance wouldn’t be an issue. This little area I was experimenting with would be added to a larger ffa map. When I started with this experiement\idea, I actually was designing it like with the thought of a spuedo-sky portal for a large ffa map. Making something that resembled a sky portal was my goal, but it’s not working. Having that halo out in its own box actually saves a lot of volume because it’s a pretty very large halo. We were going to make eventually turn it into a rotating entity later on, and in the past we’ve found that even if an entity moves outside of the box, players can still see it so long as it started in the box. So the entity can even start in the box but rotate out in the void, and they see it- in my map there are portal lines that I can’t understand though.

I’ve used sky portal in the past but they apply globally. This map will have at least 4-5 skies so that won’t work.

Anyways if someone could explain why it’s splitting and adding portal lines that would be nice. People seem to be hinting that it has something to do with convex shaped…?

(SCDS_reyalP) #8
(ACROBAT) #9

Thanks SCDS_reyalP

I made a picture to convince myself where I drew two rooms connected by a corridor. Once you do this it automatically becomes a concave angle it appears that using the design I had earlier posted won’t work I think.

Look over what I drew please.

This thread helped me a lot to understand the -vis better anyway.

Is there anyway to make a sky portal that is local and not globally applied to all skyboxes?