Func proprespawnzone

[trackhed]

zuh?

 

[Armadillo of Doom]

Oh awsome. I always wanted one of these in DM

 

[Fyfey]

Ah, looks interesting... how does it work? :S

There was another TF2 specific function that you apply to a brush to turn the area into 1 big visleaf... here it is... http://developer.valvesoftware.com/...etry_Visibility_and_Compile_Times#Visclusters

^Not really related, but I thought I'd see if anyone was interested

Fyfey

 

[Sacrifist]

Ah, looks interesting... how does it work? :S

There was another TF2 specific function that you apply to a brush to turn the area into 1 big visleaf... here it is... http://developer.valvesoftware.com/...etry_Visibility_and_Compile_Times#Visclusters

^Not really related, but I thought I'd see if anyone was interested

Fyfey

reducing compile times and BSP filesize dramatically

im guessing the Valve mappers arent using this in their maps lol.

 

[Snipergen]

what the hell does tis entity even exist??

 

[Shmitz]

Orange Box brush entity func_viscluster merges all visleaves inside it into one large leaf, reducing compile times and BSP filesize dramatically. It's exceptionally useful when your map contains open expanses of water or sky, or large, open areas with long sightlines.

Wow, if func_viscluster will bypass the stupid 1024 rule, I am in love.

On the other hand, the wiki entry on the entity tells a slightly different story:

A VIS optimisation brush entity. It appears to tell VVIS that all leaves within its volume can see each other. This can greatly reduce the time VVIS takes when compiling a map. It is only useful when used on large, open areas, where large areas of a map can be seen at once.

Even though it reduces compiling time, it does not help to optimise your map. You should attempt to optimise your map first, with proper usage of Func_detail, Hint brushes and areaportals.

I'm not exactly sure how those two descriptions are both true. Does it merge them? Or does it just save the compiler calculation time by telling it they can all see each other? There's a significant difference to its usefulness.

 

[trackhed]

its called Func proprrespawnzone <-notice the 2 r?

 

[Shmitz]

I did a little playing around with func_viscluster, and it does seem to actually merge visleafs together. At least, that's how it appears after compiling a map and loading the portal file.

Things to note:

• It *does* merge across the dumb 1024 rule.
• Does quirky things when competing with hint brushes, don't know if/how that affects performance.
• You generally don't actually want a whole bunch of large visleafs, as that will usually cause players to render things that don't need to be rendering.

I can see them being useful for:

• Large expanses of "sky" that have nothing of note to render, and that the player will never spend any time inside.
• Side "eyecandy" rooms that if you can see inside it at all, you're probably seeing the entirety of its contents (also, use areaportals to see into them).
• Places where the compiler decides to take a bsp cut on one side of a wall and extend it far past the other side of the wall, resulting in groups of small pointless visleaves.

In general, I wouldn't mess around with them unless you understand map optimization for performance and how changing visleaf structure will impact that. Visclusters seem to be part of the compilation/filesize area of optimization, which should always come well after visibility and rendering control.

 

[Noggin]

I had emailed Valve for optimization help and got this reply...

Func_viscluster
Func_viscluster is used to merge leaves together. It is usually used in large open areas where multiple leaves are unnecessary, or in areas where's there's too many leaf cuts due to complicated geometry and you want to merge them together. It is not something that should be used a lot, as it is basically bypassing the BSP tree.