func_viscluster

anyone have tried it ??

I have used it sparingly, it can be useful at times.

I don’t think you should make a thread about an entity, though. (That is, unless it’s a seriously in-depth tutorial or whatever on how to use it)

I use it in all my maps. most importantly when I have a very high map ceiling where there is lots of just empty “air”.

Portals are created on the X/Y plane and are infinitely high, unless obstructed by world geometry. If you create a 1024x1024x1024 room exactly on portal boundaries, it will only have one portal for the room. If you extend the ceiling to make the room 1024x1024x16384, it will still only have one portal.

i have to correct you, func_viscluster has nothing to do with areaportals…it is simply a way of telling VVIS that the visleaves inside its volume can all see each other. it doesn’t chop up leaves.

it is only used to speed up the compile process (which it does VERY well lol), it doesn’t affect actual in-game processing.

So, it makes vvis compile big opened spaces rather fast?
If so, it would be useful as hell for me!

It’s a handy entity, but must be used right or it can really cause some nasty issues such as rendering too much (Causing performance issues) or actually screwing up light bounces (due to inaccurate visibility calculations). Use it ONLY whereby you can see a large area and where said large area would be fully (Or pretty much mostly) rendered regardless of visibility calculations.

Otherwise, just leave VVis to do its stuff and don’t get tempted into using it and covering your whole map with it because it would reduce your VVis time - Optimise properly instead!

Forgot to add, it doesn’t reduce your Visleafs remember, it merely tells VVis that all Visleafs inside it’s brush can see each other, so don’t bother with the calculations.

What does light bouncing have to do with visibility?

I’ve known this since the entity was added to the compile tools. You alluded to having extremely high skyboxes = huge compile times, which is not the case; Unless you also have a huge outdoor area with no optimization.

[editline]1st July 2011[/editline]

If the big open space has, for example 512 leaves that can all “see” eachother, surrounding them in a func_viscluster will essentially treat them as one huge leaf so vvis doesn’t have to waste massive amounts of time on pointless calculations. However, if you use it incorrectly, it can result in portions of the map that aren’t supposed to be rendered, being rendered in large parts of the level and impact performance drastically.

I think it has something to do with telling the radiosity algorithm where it’s allowed to bounce, because without it, you just get a direct ray of light that lights up a specified luxel on a surface.

Vis only tells Source what to render when the player is in any given visleaf. Rad would do that instead.

Derp I’m wrong :downs:

rad uses vis to bounce lighting in vis leafs.

Yep! Also hence you get no light bounces if there is a leak. BSP Spits out no .prt file, so VVis doesn’t do its funky stuff and as a result Vrad has no visibility calculations upon which to base the light bounces off.

I’ve been mapping for 6 years and don’t understand half the shit you guys are discussing.

I really should have read the VDC more often.