proper func_viscluster application

tyler

aa
Sep 11, 2013
5,102
4,621
Would all you entity wizards, gurus, wise men and general know-it-all smart asses say that using one or two func_visclusters in the large open areas of Desertion is a good or bad idea? It's kinda hard for me to know if Valve thinks they are suitable or not since they disappear after compiling and thus don't appear when you recompile.

In this area is the main application of them currently. 12 minutes into vvis and I think it's saving me time, but...?

Or is this supposed to be just for 3D skybox areas?
 

RaVaGe

aa
Jun 23, 2010
733
1,210
Hello

The viscluster must be placed in an outdoor settings not playable, in fact, when you put a viscluster in your map, VVIS will not cut this part, if you place it in a game zone, your map will be absolutely not optimized.

And for your brush problem which removes after compiling, I have no idea :[
 

jpr

aa
Feb 1, 2009
1,094
1,085
Basically you put them in areas where you can see everything at once, aka where there's nothing that would cut visleaves. You could probably put them in the sky if your skybox's ceiling is high enough but otherwise it might not help much, in fact it might be bad for optimization.
Here's how I used them in crossroads:
crss.png

Outside of the play area, where you can basically see the whole thing if you look at it so there's no point in cutting it into smaller leaves. They were used similarly in badwater too.
 

Jeremy

L11: Posh Member
Oct 24, 2010
829
299
Visclusters, when used properly, will save A LOT OF COMPILE TIME.
 

Boylee

pew pew pew
aa
Apr 29, 2008
1,068
709
They don't actually help optimise your map though, just tell vvis to skip calculating the vvis calculations between the visleaves they encompass.

You will find however, that if you make that ground in the screenshot into displacements and put some nice flat, right-angled nodraw brushes underneath, with as few junctions as possible, that vvis will chew through that area much quicker. If you're not finalised with the layout you could just make the floor func_detail with nodraw underneath to seal it.

How much of that area is func_detail btw?
 

tyler

aa
Sep 11, 2013
5,102
4,621
Alright well I think I am using these wrong from what you guys are saying.

This is what that area looks like currently, and this is what it looks like with func_detail and displacements off.

In fact, near as I can tell, the only thing slowing my compile down lately has been the displacements (which I didn't have in b2), but there's a nodraw skeleton where they used to be so I don't understand the difference. That should mean everything works out fine, but I can't finish compiles except on Fast. Last night I came home after work and saw vvis going on 5 hours in VBCT.

Chat's been pretty unhelpful; basically I'm told over and over to make sure I have a skeleton in place, and I do. Then I am told to check for leaks or something stupid like that.
 

Sgt Frag

L14: Epic Member
May 20, 2008
1,443
710
It would be much easier to tell with a screenshot like #2, but with the visleafs showing so we can see where the cuts are.

But I think you can still optimize more. A screenshot can be hard to tell, not as good as flying around first hand.

Anyway. Those nodraw brushes sticking up could go. All they are doing is cutting up a bunch more leafs. And more leafs is probably worse performance than any culling that might be happening behind them.
I also think the building on the left could be fully func_detailed. The reason is there is only a slim chance that it is blocking view of anything anyway whether inside or out.
And that angled nodraw on the left, I'd just make it flush flat so you don't get weird cuts stemming off of it.

Take Gpit for an example. The entire A, B and C areas are func_detailed. The ONLY optimizing is in the tunnels between those areas. And they run fine on 32 man servers.

Better to have fewer leafs than anything imo.

And as said above, clusters speed compile time, but don't really optimize in game. (though they could make it worse by grouping too many leafs together and making more stuff render around corners and such).

----------
I'm wondering about that round roof and the angled next to it. Do you see those shapes inside? If not put a flat brush up top inside and that'll help seal that area a lot.

At least put an area portal, but with the weird L bend, if the portal is on one plane it might not work properly. So maybe put the angled one down a bit and seperate those rooms with a wall or something (at least a partial wall high up). (maybe there is a wall inside)

--------
I'd be happy to take a look on tues night/wed also if you pm my a vmf link.
 
Last edited:

Terr

Cranky Coder
aa
Jul 31, 2009
1,590
410
As others have noted, the main benefit of proper use of func_viscluster is your VVIS compile time, so if you aren't hurting there (or VRAD is so huge that it's practicallly nothing) then I wouldn't bother.

Conversely, improper usage of VVIS can harm runtime performance. It doesn't change where visleaves are or what their size is, but it changes the lookup table of "Can I see X from Y" so it's functionally equivalent.

The maps I tend to think of as good candidates for it include Highway 17, the exteriors of Nova Prospekt, and this huge mostly-straight Ep2 valley.
 
Last edited:

tyler

aa
Sep 11, 2013
5,102
4,621
My vvis compile time was 5 hours 20 minutes last night when I came home and it was still going, so something deeper is at work here.

I'm just not sure why b2 compiled fine and b3 refuses to when there's functionally no difference between what is cutting vvis.
 

Sgt Frag

L14: Epic Member
May 20, 2008
1,443
710
That's a very long time.

I suspect a bad brush or something. I know you've probably checked for leaks and all but...

Recently I had a bad brush and I spent an hour trying to find it. It was causing a leak to nowhere, through a bunch of brushes straight into the sky. Once I deleted a few brushes and redid them everything was fine. There was no true leak but I was getting a pointfile.

So it sounds like you may have a similar issue.
 

Sgt Frag

L14: Epic Member
May 20, 2008
1,443
710
Was your nodraw skeleton just brushes leaving space between the play area and a box sealing the void?

That would leave extra open areas underneath it.

Or was the nodraw a direct seal to the void? That's how it should be, no extra spaces left to calculate.
-------------

I'd suspect that being more of an issue than displacements, unless you had a bad displacement (maybe nodraw on one done when nodrawing the skeleton), but that would show in the log if you looked through it. (would still go to compile)
 

Terr

Cranky Coder
aa
Jul 31, 2009
1,590
410
Or was the nodraw a direct seal to the void? That's how it should be, no extra spaces left to calculate.
There's a third, valid possibility: A bunch of large brushes seal the map, and a "displacement hill" exists with a large area underneath it. The map is valid, but there's a performance issue because your "displacement hill" doesn't block vis. Adding walls "under the skin" of the displacement tells the map that your displacement blocks view to an important extent.

For reference, IIRC the SDK's copy of ctf_2fort does a full VVIS in about 25-30 minutes on a dual-core 3ghz machine.
 
Last edited:

tyler

aa
Sep 11, 2013
5,102
4,621
I'm recreating things one by one now for the third or fourth time. So far things are alright... we'll see.

Doesnt Func_Detailing a displacement mess stuff up in some way? is that possible?

It isn't this, vbsp just gives up when this happens and screams at you
 

Sgt Frag

L14: Epic Member
May 20, 2008
1,443
710
There's a third, valid possibility: A bunch of large brushes seal the map, and a "displacement hill" exists with a large area underneath it. The map is valid, but there's a performance issue because your "displacement hill" doesn't block vis. Adding walls "under the skin" of the displacement tells the map that your displacement blocks view to an important extent.

For reference, IIRC the SDK's copy of ctf_2fort does a full VVIS in about 25-30 minutes on a dual-core 3ghz machine.

But that doesn't necessarily mean better performance. It will add leafs, but if those leafs can see into each other all you've done is make the problem worse.
Carefully placed hints might help.

In which case it's better just to have open space under the hill and fewer leafs.
 

tyler

aa
Sep 11, 2013
5,102
4,621
Attention, cats and kittens: although I am not sure how, I do believe I fixed all the problems.
 

Mr. Happy

L6: Sharp Member
Jul 16, 2008
320
158
Something to remember about the nodraw skeleton under your dispalcements is that nodraw only blocks vis when ALL faces of that brush are nodraw.

Also I want to reiterate what Sgt. Frag and Terr said about viscluster because they are right while the other posts were wrong.

Also, if your compile is mysteriously taking longer but not giving any errors it might be due to a slightly misaligned areaportal. Like an areaportal that sticks out of its doorway by 1 unit or some such.
 

ardysqrrl

L4: Comfortable Member
Oct 26, 2009
173
159
Something to remember about the nodraw skeleton under your dispalcements is that nodraw only blocks vis when ALL faces of that brush are nodraw.
untrue why would you even think that

ok why is not important but anyway that's not true, the only thing that would stop a nodraw brush from blocking vis is if it had a side which was not opaque
 
Last edited: