Talk:Func viscluster

Use of func_viscluster

Would it be good to use these about as much as hints, or more sparingly?--Karrus 15:17, 10 Jan 2008 (PST)

If it actually prevents leafs it will work better than HINT's for many things. --wisemx 06:02, 11 Jan 2008 (PST)

Can someone get a screenshot of this entity in use? I'm still having a hard time imagining how to place this in the editor. --Campaignjunkie ^(talk) 15:41, 25 Jan 2008 (PST)

I tested my chernobyl map by making one viscluster brush much like I would a hint/skip brush, worked out quite well: --Karrus 01:34, 26 Jan 2008 (PST)

So technically this is the same as HINT? I cant seem to see any major benefits, or really how to use this. Lol.--Gear 03:45, 26 Jan 2008 (PST)

This entity is exactly what Empires mod needed. Thank you VALVe :D! Solokiller 03:49, 26 Jan 2008 (PST)

Wouldn't you do better modifying VVIS to output a single map-spanning leaf? --TomEdwards 01:26, 5 Feb 2008 (PST)

When I tested it, it merged a bunch of leafs into a single cluster, not into a single leaf. --Mrhappy 11:21, 3 Feb 2008 (PST)

Yeah same for me, oddly it acts weirder, and has really no benefit from what I can see.--Gear 13:11, 3 Feb 2008 (PST)

In a very large level that I was working on, a river with a long bridge across it and a transmission tower on an island in the middle, enclosing the entire level space in a func_viscluster caused a very noticeable improvement in rendering time without damaging the appearance or playability. --Sagesource 17:02, 30 Jul 2008 (PDT)

An improvement in rendering time? Are you sure you don't mean compile time? --TomEdwards 03:44, 31 Jul 2008 (PDT)

<blush>me</blush> Yes. --Sagesource 15:06, 31 Jul 2008 (PDT)

Tooltexture

Karras has used toolstrigger above. Is this definitely the correct tool texture? --TomEdwards 01:23, 5 Feb 2008 (PST)

"It should be textured with tools\toolstrigger." -func_viscluster Mattshu 02:15, 14 January 2011 (UTC)

Feb 5 edit

Is it not a brush entity? Is it not an entity at all? If it is, we should keep the page formatting like the other entity pages. --Etset 02:49, 5 Feb 2008 (PST)

It's under the brush entities, not point entities. But really isn't it a volume affecting everything inside it? --Sagesource 20:07, 29 Jul 2008 (PDT)

This is a solid (brush) entity in Hammer, but is discarded after vbsp compiles the map. It is not an entity in the game. --JeffLane 22:01, 29 Jul 2008 (PDT)

Does not affect the map ingame ?

You say : This entity only reduces compiling time, and does not affect the map when it is running. I do believe this formulation is a bit tricky, because in fact, it definitely affects the map when it's running... By removing certain vis-leaves, it changes the way the PVS is handled and thus, the visible geometry. I think it could be made a little bit clearer, but I'll let native english speakers handle that. --NykO18 03:33, 31 Aug 2008 (PDT)

It doesn't change the location or the number of leaves. --TomEdwards 07:07, 31 Aug 2008 (PDT)

Yes, sorry, my fault. It doesn't change their location or number, but it does affect visibility. In fact, I'm just trying to say that does not affect the map when it is running seems to mean does nothing. --NykO18 07:41, 31 Aug 2008 (PDT)

I agree.--Gear 08:19, 31 Aug 2008 (PDT)

It does do nothing. The only effect is the reduction of compile times, as is noted. --TomEdwards 14:40, 31 Aug 2008 (PDT)

Dammit! So I really don't understand it's purpose... VVIS compile times are always a matter of a few minutes, why the hell would we need such an entity ? --NykO18 16:19, 31 Aug 2008 (PDT)

In very large, open maps (like those in Ep2) VIS compile can take a lot longer than five minutes. ;-) Try compiling the sample coastline VMF. --TomEdwards 00:09, 1 Sep 2008 (PDT)

Ah yes. Didn't thought about this case. Ok, so I suppose it is primarily used for large areas, where you're sure that VIS is totally useless. That's noted, thanks for your help. --NykO18 01:32, 1 Sep 2008 (PDT)

?Can func_viscluster be used on CS:S maps?

It says "for orangebox" on the viscluster home page.

My portalflow compile time is terrible due to a very large area in my map. Thx in advance for any help you can provide.—Unsigned comment added by Hannibalektr (talk • contribs) Always sign your posts with four tildes (~~~~)

Func_viscluster only works in games that have been updated to the Orange box engine, thus CS: S doesn't have it, and won't work. Solokiller 17:23, 29 March 2010 (UTC)

I read that newell said all source games were going to be updated to use func_viscluster dated in a forum 2008 (don't know if that was a trustworthy quote). I tried using func_viscluster while compiling a CS:S map with HUGE open areas, the portalflow went much faster than other compiles, like from a 36 hours to a day (shaving off 2/3rds of the portalflow compile time), but my CS:S map spammed the following error ingame: "attempted to create unknown entity type" "can't init func_viscluster". So, the compile tools seem to be able to use func_viscluster to compile CS:S maps, but the game doesn't know wtf these huge entities are. Framerate seemed be affected by this error as they were lower than without these errors spamming console.

The func_viscluster entity is not supported by games not using the orange box engine, the older compile tools probably don't even recognize the entity. The difference might be caused by something else. Solokiller 18:47, 6 April 2010 (UTC)

I dont mean to be arguementative but I would like verification that the compile tools are not the same for CS:S as for EP2 or Orange box games. I think they are as another map that would not compile at all without, would with vis_cluster for CS:S. Thx —Unsigned comment added by Hannibalektr (talk • contribs) Always sign your posts with four tildes (~~~~)

If they're the same compile tools, then there wouldn't be seperate versions to use, there would be just one. Func_viscluster was added because they needed it for the open areas in episode 2, it didn't exist in episode 1 and earlier engine versions, and if they did add it, then they would've probably updated CS:S with orange box engine features at the same time. Solokiller 15:27, 9 April 2010 (UTC)

I just tested this on another CSS map with several large open areas and func_viscluster did in fact cut my portalflow compile time down by 2/3's. I suggest you try this on a map with a huge open area, you will then see the results I am talking about, they speak for themselves. The game engines are different but the compile tools are either the same (maybe with a different name), or if there are different compile tool versions for ep1 source games as opposed to ep2 then ep1 compile tools can still recognize and use func_viscluster. —Unsigned comment added by Hannibalektr (talk • contribs) Always sign your posts with four tildes (~~~~)

Then the best way to find out whether this is true or not is to check the source code of the episode 1 compile tools, which should come along with the episode 1 mod source code. And please, sign your name when you add comments. Solokiller 12:27, 19 April 2010 (UTC)

It is a very bad thing when people chime into these discussions with input when they don't really know with certainty what they are talking about. It's even worse when they lead people down the wrong path with erroneous statements. Please try not to post sueto facts if you aren't sure of what you are talking about. Thank you. —Unsigned comment added by Hannibalektr (talk • contribs) Always sign your posts with four tildes (~~~~)

I just made a large hollow cube with a player start and a light entity in it, under the episode 1 configuration. I compiled it with and without a func_viscluster covering the entire cube, with bsp and vis only. It actually took 3 seconds less when the viscluster wasn't in the map, probably caused by uncontrollable variables, so there is either no support for func_viscluster, or the compiler automatically optimizes visibility calculations for large open areas, which is exactly what func_viscluster is meant to do, so i doubt the episode 1 compiler supports the entity. Also, please sign your comments, i'm not going to keep on doing it for you. Solokiller 18:12, 23 April 2010 (UTC)

Ott: facts

• A viscluster will make in-game performance worse.

This is kind of ridiculous to say. There's a difference between using an entity wisely and just putting something in your map without thinking. In some cases, it can actually save you performance because the engine isn't changing the PVS so frequently. Even when that isn't the case, it's 2018. The damage is minimal I'd say. Pinsplash (talk) 09:31, 6 July 2018 (UTC)

I suppose I should have clarified that if you keep your leaves under control and use func_detail properly, the rendering costs will outweigh the PVS switching. As for it being {CURRENT_YEAR}, games like Garry's Mod need incredibly well-optimized maps if you're going to have tons and tons of props everywhere. --Ott (talk) 17:09, 6 July 2018 (UTC)

Func_viscluster can slightly help performance in large open areas, especially as vvis automatically splits visleaves every 1024 units or so; but even so, it's mostly helpful in reducing vvis compile time than boosting in-game performance. However, it's unfair to say that it will always make in-game performance worse. --Stract (talk) 17:28, 6 July 2018 (UTC)

• It is actually useful

The map decides to cut itself every 1024 units or so, much like HINT does. That's why in some places, like duct vents, hallways, large open areas, and spaces where there are lots of "cuts" made by world brushes (the ones that can't be func_detailed), its generally good to place one, as it will most likely wont help with in-game performance, however it will (theoretically) fasten the compile time. I have tested it in CSS and the results are good. --NvC DmN CH (talk) 00:10, 18 July 2018 (UTC)