visleaf help

i'm not expert at optimization as i've yet to even touch this process of mapping myself but from what little i DO know, i see a couple brushes in that area that seems to like not line up quite right creating faces that really don't belong, or certainly DO NOT belong. Um, the 2 examples i found without very close inspection.

1) that ramp has a very tiny face on the top of the ramp before it switches to the next very large brush for the floor. You can combine the vertexes and eliminate that useless face. It's very small and won't do any good leaving it there.

2) Looking at the ramp, go through the metal door on the left where your resupply sign is. Go down the hall until it starts to ramp up ever so slightly. You have 2 long brushes connected with a very small brush. Problem is, the tiny little connecting brush doesn't line up. Creating a little tiny ridge in the brushes. Those brushes down this hallway could be causing a sort of cascading visleaf thing that is going through that room. That's maybe why you have those random boxes out infront of the ramp, because it's connecting the faces of the ramp and that geometry with the visleafs created by that weird ramp thing you got going on through that resupply door.

Keep in mind i've never optimized a map before so i could be blowing chunks of nonsense that isn't remotely right. BUT, from my inexperienced eye they may be some things to consider looking into to see if it knocks out even a couple of those lines.

In short, check your brush work to find small useless faces, and vertex's that don't line up. As every single one of those tiny useless faces will get counted when calculating visleafs.

I hope this points you in the right direction even if it doesn't directly help your problem...best i can offer

You should make that small ramp a func_detail, there's no way that's going to block anyone's view of anything.

Another thing is that there's still a lot of nodraw textures on walls and different places of the map...not sure if that's a problem for vvis. Also, I THINK you're using area portals wrong? I'm not 100% sure though.

Also, on this version, I don't actually see any hints anywhere.

Looking at the map there's an enormous amount of stuff that should be func_detail... sloped building roofs, curved walls outside your intel room, etc. There's a huge open space in the middle with sloped brushes all over the place. You should be able to func_detail all this stuff and make the map compile very quickly without any area portals.

The plain world geometry brushes in your map should be as simple and few as possible... you can run around in Valve maps and start turning things off in order to see for yourself. Open a Valve map and do r_drawfuncdetail 0, r_drawbrushmodels 0, r_drawdisp 0, and r_drawstaticprops 0.

louiekidd might not be an expert but he is right. any little faces that don't line up are gonna cause splits.

Top of the ramp is a prime example. But even if you func_detail that the cube behind it doesn't line up to the wall next to it, so there's another split.

All this basic geometry should be done on a fairly large scale. At least grid 8 if not 16.
16 is nice beacuse it'll give a good wall thickness to block shadows and fit doorways. And the walls will snap nice and easy because they take up a full cube on the grid (if you use grid 8 they'll take 2 units of the grid -easier to mess up and make them one or 3 units, also easier to get off the main grid lines).

Another thing I notice in that pic.
In front of the ramp there is a vis-leaf that splits all the way across the room. No doubt that's on a red grid line which automatically splits vis. If you can put walls on those lines, but don't go too far out of the way to do so. In that case I'd leave it as is. That would be a pretty large change to the area to move those walls that far.

The far back door has the same issue. The wall the door is in is a few units behind the wall above it, so another small sliver you can kill there.

And all the way in the back past the ramp there are little slivers of walls that stick out. Flush that all up.

anytime, good luck

I dunno whats the policy here bump vs new topic so here goes. I have same issue. My map is very open and it adds extremely quickly. It appears that theres extra leaf on every floor outside even if walls are flat. Please help it can be only worse :/ Vmf and ss in attachment.

Well, it would deffinately help if you hid everything except terrain brushes (func_details, objects, etc...) when you take that screeny. All that stuff makes it hard to see the base geometry and that's what you're asking for help with.

One issue you are going to have though is simply the fact you have such a large open area there. Players can see alot and a long ways and add 10+ players fighting with high poly counts and particles and it's gonna kill framerate.

Is that a quick compile? Or a full compile. Full compiles will be cleaner so you really need to do that to get an idea of what issues you REALLY have.
Just turn off lighting and it won't take long.

For everyone with maps that have huge open areas:

If the problem is the speed VVIS itself, and not the speed while actually playing, then I think what you want is the brush entity func_viscluster.

n30n: Given your map, make special note the above/below water prohibition on the page.

note: visclusters effectively merge visleaves. you will find statements out there to the contrary, and while technically, yes, you cannot merge visleaves, a func_viscluster effectively does. visclusters can only make in-game performance worse, not better. they are only for cutting down vvis time.

for maps with lots of open sky, if used right, they are fantastic. generally you want to stick them in big areas of sky or unplayable space. valve uses them in places like the unplayable space in the background of badwater, where its beyond fences, and there are vis leaf cuts just because of the back sides of buildings, and the 1024 split.

Hrm. I'll see if I can verify that on a test map later.

I used them(func_visclusters) in my latest build of Orient.

I didn't notice ANY noticeable framerate changes at all. And if they improved speed of vis compile it was negligible.

But they do clean up the view when viewing the portal file.

They could have a negative impact if used wrong for sure.

As far as I can tell func_viscluster does pretty much what it says on the tin: For the visleafs the entity encloses, VVIS takes a shortcut in processing and simply notes in it's data structure that any one of them can see all the rest.

mat_leafvis will show no change, because the leaves themselves are unchanged, only their set of relationships is. Hammer seems to have some of the same smarts VVIS has (or else gets confused by the portal file) and will use the viscluster information inside the portal file to avoid drawing you visleafs which do exist but were clustered together. Use Hammer/Portal-file to debug clustering attempts, rather than mat_leafvis.

At any rate, the only way func_viscluster can hurt you is if you do not follow the instructions... if you use it to connect areas which most of the time wouldn't always be able to see one another. Used correctly it will speed of VVIS, presuming VVIS is having problems with lots of open-air leaves anyway. It won't speed up your actual running of the game, because your computer still needs to deal with a huge list of "leaf X can see leaves 1-99999999", the only thing that is faster is generating those precomputed "leaf-X-can-see-leaves-Y/Z" bits.