"buildvisleafs" Takes Years! - Developers

hello there im making a map and the part [B]"buildvisleafs[/B]" takes to long time , how do i fix that? :damn: [B]THE COMPILE LOGS[/B] [CODE] ** Executing... ** Command: "c:\program files\steam\steamapps\grandevik\sourcesdk\bin\ep1\bin\vbsp.exe" ** Parameters: -game "c:\program files\steam\steamapps\grandevik\counter-strike source\cstrike" "C:\Program Files\Steam\steamapps\grandevik\sourcesdk_content\cstrike\mapsrc\rp_jersey_v1d" Valve Software - vbsp.exe (Dec 11 2006) 2 threads materialPath: c:\program files\steam\steamapps\grandevik\counter-strike source\cstrike\materials Loading C:\Program Files\Steam\steamapps\grandevik\sourcesdk_content\cstrike\mapsrc\rp_jersey_v1d.vmf Can't find surfaceprop stone for material STONE/INFFLRA, using default fixing up env_cubemap materials on brush sides... Material glass/glasswindowbreak070b is depending on itself through materialvar $crackmaterial! Ignoring... Material glass/glasswindowbreak070b is depending on itself through materialvar $crackmaterial! Ignoring... Material glass/glasswindowbreak070b is depending on itself through materialvar $crackmaterial! Ignoring... Material glass/glasswindowbreak070b is depending on itself through materialvar $crackmaterial! Ignoring... Material glass/glasswindowbreak070b is depending on itself through materialvar $crackmaterial! Ignoring... Material glass/glasswindowbreak070b is depending on itself through materialvar $crackmaterial! Ignoring... Material glass/glasswindowbreak070b is depending on itself through materialvar $crackmaterial! Ignoring... Material glass/glasswindowbreak070b is depending on itself through materialvar $crackmaterial! Ignoring... Material glass/glasswindowbreak070b is depending on itself through materialvar $crackmaterial! Ignoring... Material glass/glasswindowbreak070b is depending on itself through materialvar $crackmaterial! Ignoring... Material glass/glasswindowbreak070b is depending on itself through materialvar $crackmaterial! Ignoring... Material glass/glasswindowbreak070b is depending on itself through materialvar $crackmaterial! Ignoring... Material glass/glasswindowbreak070b is depending on itself through materialvar $crackmaterial! Ignoring... Material glass/glasswindowbreak070b is depending on itself through materialvar $crackmaterial! Ignoring... Material glass/glasswindowbreak070b is depending on itself through materialvar $crackmaterial! Ignoring... Material glass/glasswindowbreak070b is depending on itself through materialvar $crackmaterial! Ignoring... Material glass/glasswindowbreak070b is depending on itself through materialvar $crackmaterial! Ignoring... Material glass/glasswindowbreak070b is depending on itself through materialvar $crackmaterial! Ignoring... Material glass/glasswindowbreak070b is depending on itself through materialvar $crackmaterial! Ignoring... Material glass/glasswindowbreak070b is depending on itself through materialvar $crackmaterial! Ignoring... Material glass/glasswindowbreak070b is depending on itself through materialvar $crackmaterial! Ignoring... Material glass/glasswindowbreak070b is depending on itself through materialvar $crackmaterial! Ignoring... Material glass/glasswindowbreak070b is depending on itself through materialvar $crackmaterial! Ignoring... Material glass/glasswindowbreak070b is depending on itself through materialvar $crackmaterial! Ignoring... ProcessBlock_Thread: 0...1...2...3...4...5...6...7...8...9...10 (1) ProcessBlock_Thread: 0...1...2...3...4...5...6...7...8...9...10 (1) FindPortalSide: Couldn't find a good match for which brush to assign to a portal near (-2023.6, -813.5, 426.5) Leaf 0 contents: Leaf 1 contents: CONTENTS_SOLID viscontents (node 0 contents ^ node 1 contents): CONTENTS_SOLID This means that none of the brushes in leaf 0 or 1 that touches the portal has CONTENTS_SOLID Check for a huge brush enclosing the coordinates above that has contents CONTENTS_SOLID Candidate brush IDs: Brush 56081: Processing areas...done (0) Building Faces...done (0) Chop Details...done (0) Find Visible Detail Sides... Merged 2344 detail faces...done (0) Merging details...done (1) FixTjuncs... PruneNodes... WriteBSP... done (5) writing C:\Program Files\Steam\steamapps\grandevik\sourcesdk_content\cstrike\mapsrc\rp_jersey_v1d.prt...done (1) Creating default cubemaps for env_cubemap using skybox materials: skybox/militia_hdr*.vmt Run buildcubemaps in the engine to get the correct cube maps. Creating default HDR cubemaps for env_cubemap using skybox materials: skybox/militia_hdr*.vmt Run buildcubemaps in the engine to get the correct cube maps. Finding displacement neighbors... Finding lightmap sample positions... Displacement Alpha : 0...1...2...3...4...5...6...7...8...9...10 Building Physics collision data... done (2) (1654280 bytes) Error! prop_static using model "models/props_c17/lamp_standard_off01.mdl", which must be used on a dynamic entity (i.e. prop_physics). Deleted. Error loading studio model "models/props_c17/lamp_standard_off01.mdl"! Error! prop_static using model "models/props_interiors/furniture_couch01a.mdl", which must be used on a dynamic entity (i.e. prop_physics). Deleted. Error loading studio model "models/props_interiors/furniture_couch01a.mdl"! Error! prop_static using model "models/props_wasteland/controlroom_chair001a.mdl", which must be used on a dynamic entity (i.e. prop_physics). Deleted. Error loading studio model "models/props_wasteland/controlroom_chair001a.mdl"! Error! prop_static using model "models/props_wasteland/prison_shelf002a.mdl", which must be used on a dynamic entity (i.e. prop_physics). Deleted. Error loading studio model "models/props_wasteland/prison_shelf002a.mdl"! Error! prop_static using model "models/props_c17/furnitureradiator001a.mdl", which must be used on a dynamic entity (i.e. prop_physics). Deleted. Error loading studio model "models/props_c17/furnitureradiator001a.mdl"! Error! prop_static using model "models/props_c17/clock01.mdl", which must be used on a dynamic entity (i.e. prop_physics). Deleted. Error loading studio model "models/props_c17/clock01.mdl"! Error! prop_static using model "models/props_vehicles/carparts_axel01a.mdl", which must be used on a dynamic entity (i.e. prop_physics). Deleted. Error loading studio model "models/props_vehicles/carparts_axel01a.mdl"! Error! prop_static using model "models/props_vehicles/carparts_wheel01a.mdl", which must be used on a dynamic entity (i.e. prop_physics). Deleted. Error loading studio model "models/props_vehicles/carparts_wheel01a.mdl"! Error! prop_static using model "models/props_c17/furniturefridge001a.mdl", which must be used on a dynamic entity (i.e. prop_physics). Deleted. Error loading studio model "models/props_c17/furniturefridge001a.mdl"! Placing detail props : 0...1...2...3...4...5...6...7...8...9...10 Water found with no water_lod_control entity, creating a default one. Compacting texture/material tables... Reduced 12440 texinfos to 7832 Reduced 647 texdatas to 531 (28031 bytes to 23433) Writing C:\Program Files\Steam\steamapps\grandevik\sourcesdk_content\cstrike\mapsrc\rp_jersey_v1d.bsp 28 seconds elapsed ** Executing... ** Command: "c:\program files\steam\steamapps\grandevik\sourcesdk\bin\ep1\bin\vvis.exe" ** Parameters: -game "c:\program files\steam\steamapps\grandevik\counter-strike source\cstrike" -fast "C:\Program Files\Steam\steamapps\grandevik\sourcesdk_content\cstrike\mapsrc\rp_jersey_v1d" Valve Software - vvis.exe (Nov 8 2007) fastvis = true 2 threads reading c:\program files\steam\steamapps\grandevik\sourcesdk_content\cstrike\mapsrc\rp_jersey_v1d.bsp reading c:\program files\steam\steamapps\grandevik\sourcesdk_content\cstrike\mapsrc\rp_jersey_v1d.prt 3544 portalclusters 12361 numportals BasePortalVis: 0...1...2...3...4...5...6...7...8...9...10 (41) WARNING: Cluster portals saw into cluster WARNING: Cluster portals saw into cluster WARNING: Cluster portals saw into cluster WARNING: Cluster portals saw into cluster WARNING: Cluster portals saw into cluster WARNING: Cluster portals saw into cluster WARNING: Cluster portals saw into cluster WARNING: Cluster portals saw into cluster WARNING: Cluster portals saw into cluster WARNING: Cluster portals saw into cluster WARNING: Cluster portals saw into cluster WARNING: Cluster portals saw into cluster WARNING: Cluster portals saw into cluster Optimized: 463296 visible clusters (0.00%) Total clusters visible: 10943209 Average clusters visible: 3087 Building PAS... Average clusters audible: 3509 visdatasize:3079216 compressed from 3175424 writing c:\program files\steam\steamapps\grandevik\sourcesdk_content\cstrike\mapsrc\rp_jersey_v1d.bsp 49 seconds elapsed ** Executing... ** Command: "c:\program files\steam\steamapps\grandevik\sourcesdk\bin\ep1\bin\vrad.exe" ** Parameters: -game "c:\program files\steam\steamapps\grandevik\counter-strike source\cstrike" -noextra "C:\Program Files\Steam\steamapps\grandevik\sourcesdk_content\cstrike\mapsrc\rp_jersey_v1d" Valve Software - vrad.exe SSE (Nov 8 2007) ----- Radiosity Simulator ---- 2 threads [Reading texlights from 'lights.rad'] [1 texlights parsed from 'lights.rad'] Loading c:\program files\steam\steamapps\grandevik\sourcesdk_content\cstrike\mapsrc\rp_jersey_v1d.bsp 19151 faces 22 degenerate faces 3220344 square feet [463729536.00 square inches] 1 displacements 21312 square feet [3069031.25 square inches] 19129 patches before subdivision zero area child patch zero area child patch 67947 patches after subdivision 129 direct lights BuildFacelights: 0...1...2...3...4...5...6...7...8...9...10 (32) BuildVisLeafs: 0...1...2...3...4...5...6...7...8.. ** Executing... ** Command: Copy File ** Parameters: "C:\Program Files\Steam\steamapps\grandevik\sourcesdk_content\cstrike\mapsrc\rp_jersey_v1d.bsp" "c:\program files\steam\steamapps\grandevik\counter-strike source\cstrike\maps\rp_jersey_v1d.bsp" [/CODE] Thx if u reply :3 /Gustav :sweden:

It's normal. the buildvisleafs take more time than the other, depending of the size of the map, this can get hours, or days... so. you can low the time using nodraw textures on "non-seeable" brush faces.. using func_detail in brushes and more things.. so, hope this helpz

[QUOTE=nicolasx21;19675147]It's normal. the buildvisleafs take more time than the other, depending of the size of the map, this can get hours, or days... so. you can low the time using nodraw textures on "non-seeable" brush faces.. using func_detail in brushes and more things.. so, hope this helpz[/QUOTE] i have done that :/

Your map is horribly unoptimized. Try doing this: 1) read the optimization guide at [url]http://rvanhoorn.ruhosting.nl/optimization.php[/url] 2) apply changes to your map 3) recompile 4) ??? 5) profit [editline]07:14PM[/editline] if your map is a large, open space with a few hundred visleafs which are able to see each other no matter what, drag a large brush with the tools/toolstrigger texture over it and tie it to a func_viscluster. Don't overuse func_viscluster, it can fuck with your in-game framerates if used improperly. [highlight](User was banned for this post ("Meme Response" - Terrenteller))[/highlight]

Anyone know if you can use func_viscluster for CS:S maps? It doesn't look like its for anything other than EP2 or portal. Any help is appreciated. I have a large open area and it's choking on portalflow big time, we are talking a week (7 days) and still on 8.1 of 10. Yes I have func_detailed, read all the manual's on how to optimize. Everything is hinted, no draw, portal'd as is taught in every vid, written tut I could find. Open area's just grind man. Last thing for me to do to get over this portal flow crap is to try find a way to optimize this large opening with a high skybox (a few train props as it is a train yard). :(

[QUOTE=hannibalektr;21031238]Anyone know if you can use func_viscluster for CS:S maps? It doesn't look like its for anything other than EP2 or portal. Any help is appreciated. I have a large open area and it's choking on portalflow big time, we are talking a week (7 days) and still on 8.1 of 10. Yes I have func_detailed, read all the manual's on how to optimize. Everything is hinted, no draw, portal'd as is taught in every vid, written tut I could find. Open area's just grind man. Last thing for me to do to get over this portal flow crap is to try find a way to optimize this large opening with a high skybox (a few train props as it is a train yard). :([/QUOTE] func_viscluster first came in ob-source. CSS uses ep1-source, so it's doesnt have it. :/

Why did you bump this.

[QUOTE=Legend286;21032682]Why did you bump this.[/QUOTE] I answered to question. You do know, what question is?

[QUOTE=killer89;21032699]I answered to question. You do know, what question is?[/QUOTE] Your grammar is horrible, but atleast it's better that you answered it instead of just saying something totally unrelated.

Still seems pretty pointless to bump it when for all we know he could've found the answer ages ago. [highlight](User was banned for this post ("Bump to complain about bump" - Terrenteller))[/highlight]

Even though this was bumped I wanna call all of you stupid since none of you saw he had a fucking leak.

[QUOTE=Sgt.Sgt;21058422]Even though this was bumped I wanna call all of you stupid since none of you saw he had a fucking leak.[/QUOTE] Feel free to call them stupid for that, but there's no actual leak... Use your eyes :P There's no ***leaked*** in the console, no reference to an entity leaking, and vvis is running. There's a portal error yes, but that's only an indicator of a leak, not a sure sign of one.

Interlopers error-chekcer gives this: [code] [b]findportalside: couldn't find a good match for which brush to assign to a portal near (-2023.6, -813.5, 426.5)[/b] Description: This error is usually followed by something like this: Leaf 0 contents:(may vary) Leaf 1 contents: CONTENTS_SOLID (may vary, e.g. CONTENTS_WATER) viscontents (node 0 contents ^ node 1 contents): CONTENTS_SOLID (ditto) This means that none of the brushes in leaf 0 or 1 that touches the portal has CONTENTS_SOLID Check for a huge brush enclosing the coordinates above that has contents CONTENTS_SOLID Candidate brush IDs: [none or more brushnumbers] Usually, this error is caused by a leak, so fix it if it is. If it isn't, there is a (group of) brush(es) that is/are giving vbsp.exe a hard time to figure out your level. Apparently it cannot determine the boundaries of a certain portal. Maybe there is a large brush covering the area, maybe the area is just to complicated for poor vbsp to figure out. I don't know the details but usually turning entities to world brushes or vice-versa helps to fight the problem. Hell, just cutting a brush in two once helped me fight this problem. Solution: Find the given coordinates (or if a brush number is given search for the brush number) and see what you can do to to simplify the area (like turning brushes to func_detail). You should also check to see if the brushes are overlapping at any point.[/code] And that error is usually caused by leak.

[QUOTE=Jukka K;21060224]Interlopers error-chekcer gives this: [code] [b]findportalside: couldn't find a good match for which brush to assign to a portal near (-2023.6, -813.5, 426.5)[/b] Description: This error is usually followed by something like this: Leaf 0 contents:(may vary) Leaf 1 contents: CONTENTS_SOLID (may vary, e.g. CONTENTS_WATER) viscontents (node 0 contents ^ node 1 contents): CONTENTS_SOLID (ditto) This means that none of the brushes in leaf 0 or 1 that touches the portal has CONTENTS_SOLID Check for a huge brush enclosing the coordinates above that has contents CONTENTS_SOLID Candidate brush IDs: [none or more brushnumbers] Usually, this error is caused by a leak, so fix it if it is. If it isn't, there is a (group of) brush(es) that is/are giving vbsp.exe a hard time to figure out your level. Apparently it cannot determine the boundaries of a certain portal. Maybe there is a large brush covering the area, maybe the area is just to complicated for poor vbsp to figure out. I don't know the details but usually turning entities to world brushes or vice-versa helps to fight the problem. Hell, just cutting a brush in two once helped me fight this problem. Solution: Find the given coordinates (or if a brush number is given search for the brush number) and see what you can do to to simplify the area (like turning brushes to func_detail). You should also check to see if the brushes are overlapping at any point.[/code] And that error is usually caused by leak.[/QUOTE] Usually, but not always, as in this case, god damn, learn to read. Interlopers compile checker is fine, but it still misses things and mis-flags other things, having the experience to read and fix your own compile errors is far better in the long run.

[QUOTE=nicolasx21;19675147] so. you can low the time using nodraw textures on "non-seeable" brush faces.[/QUOTE] using nodraw on un-seeable brush faces has nothing to do with VVIS. also i should point out that putting nodraw on brush faces that touch "the void" (aka they aren't visible from inside the map) doesn't affect anything, it's a waste of time.

[QUOTE=Rambo_9;21066211]using nodraw on un-seeable brush faces has nothing to do with VVIS. also i should point out that putting nodraw on brush faces that touch "the void" (aka they aren't visible from inside the map) doesn't affect anything, it's a waste of time.[/QUOTE] The same is true of any face completely covered by another.

yes, that too. pretty much any brush face that cannot be seen by a normal player inside the map will be removed so texturing it nodraw is in fact a waste of time. this is the one thing that people need to learn when they first begin working with hammer.

I can compile large maps very fast. I7 core processor. Nvidia 295 GTX 12 GB Ram. lol

[QUOTE=Redcow;21067608]I can compile large maps very fast. I7 core processor. Nvidia 295 GTX 12 GB Ram. lol[/QUOTE] Just as with VMPI, superior hardware shouldn't be a crutch for poor optimisation work.