Discussion in 'Mapping Questions & Discussion' started by trackhed, Feb 18, 2008.
Oh awsome. I always wanted one of these in DM
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
im guessing the Valve mappers arent using this in their maps lol.
what the hell does tis entity even exist??
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:
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.
its called Func proprrespawnzone <-notice the 2 r?
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.
I had emailed Valve for optimization help and got this reply...
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.
Separate names with a comma.