Customized SWRP Venator V3 map compiling problem

Hello Everyone, I have been editing the Venator V3 map for a server to use. Now I have looked everywhere for how to fix the compile; I’ve of course used Func_Detail on any walls I need a visleaf split and blocked for optimization, I’ve shrunk the outside Skybox to a more reasonable size. I do know that I shouldn’t incase the map in a box, but have to for the sake of ships having space to fly.

I’m stumped on the fact that I can’t remove anything else and have a count of 10680 numportals. Fast Compile works and lasts only 5 minutes, while I had my pc run a full Compile and waited 72 hours for VVIS to finish on 3/4 cores of a Intel I5 - 6600k overclocked to 4.5 GHz. Would I either have to wait longer, remove parts, or fix an error to resolve the problem?

Thanks for any advice you guys have.

Is this a decompiled map? If so, decompiling breaks a lot of things. Recompiling a decompiled map that was near the limits is very difficult.

Post a compile log

Starting a ‘Fast - HDR’ compile.
Starting compilation of C:\Users\lioni\Documents\HammerMapProjects\rp_venator_cn\Map\rp_venator_cn.vmf
Valve Software - vbsp.exe (Jul 25 2017)
notjunc = true
4 threads
materialPath: C:\Program Files (x86)\Steam\steamapps\common\GarrysMod\garrysmod\materials
Loading C:\Users\lioni\Documents\HammerMapProjects\rp_venator_cn\Map\rp_venator_cn.vmf
ConVarRef mat_reduceparticles doesn’t point to an existing ConVar
Could not locate ‘GameData’ key in c:\program files (x86)\steam\steamapps\common\garrysmod\garrysmod\gameinfo.txt
fixing up env_cubemap materials on brush sides…
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 (0)
Processing areas…done (0)
Building Faces…done (0)
Chop Details…done (0)
Find Visible Detail Sides…
Merged 3664 detail faces…done (1)
Merging details…done (0)
FixTjuncs…
PruneNodes…
WriteBSP…
done (1)
writing C:\Users\lioni\Documents\HammerMapProjects\rp_venator_cn\Map\rp_venator_cn.prt…Building visibility clusters…
done (0)
Creating default LDR cubemaps for env_cubemap using skybox materials:
skybox/starbox_.vmt
! Run buildcubemaps in the engine to get the correct cube maps.
Creating default HDR cubemaps for env_cubemap using skybox materials:
skybox/starbox_
.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 (1) (2698787 bytes)
Placing detail props : 0…1…2…3…4…5…6…7…8…9…10
Compacting texture/material tables…
Reduced 18461 texinfos to 10022
Reduced 1843 texdatas to 1717 (97057 bytes to 92115)
Writing C:\Users\lioni\Documents\HammerMapProjects\rp_venator_cn\Map\rp_venator_cn.bsp
9 seconds elapsed
203.984304 -7.580583 0.000000
208.582118 -9.753600 0.000000
203.984212 -9.753600 0.000000
203.984349 -6.502400 0.000000
make_triangles:calc_triangle_representation: Cannot convert
Valve Software - vvis.exe (Jul 25 2017)
fastvis = true
4 threads
reading c:\users\lioni\documents\hammermapprojects\rp_venator_cn\map\rp_venator_cn.bsp
reading c:\users\lioni\documents\hammermapprojects\rp_venator_cn\map\rp_venator_cn.prt
3582 portalclusters
10329 numportals
BasePortalVis: 0…1…2…3…4…5…6…7…8…9…10 (2)
Optimized: 478365 visible clusters (4.92%)
Total clusters visible: 9724891
Average clusters visible: 2714
Building PAS…
Average clusters audible: 3551
visdatasize:3120468 compressed from 3209472
writing c:\users\lioni\documents\hammermapprojects\rp_venator_cn\map\rp_venator_cn.bsp
3 seconds elapsed
Valve Software - vrad.exe SSE (Jul 25 2017)

  Valve Radiosity Simulator     

4 threads
[Reading texlights from ‘lights.rad’]
[45 texlights parsed from ‘lights.rad’]

Loading c:\users\lioni\documents\hammermapprojects\rp_venator_cn\map\rp_venator_cn.bsp
Setting up ray-trace acceleration structure… Done (2.70 seconds)
32410 faces
23 degenerate faces
31871240 square feet [4589458432.00 square inches]
0 Displacements
0 Square Feet [0.00 Square Inches]
32387 patches before subdivision
32387 patches after subdivision
891 direct lights
BuildFacelights: 0…1…2…3…4…5…6…7…8…9…10 (227)
BuildVisLeafs: 0…1…2…3…4…5…6…7…8…9…10 (24)
transfers 5520200, max 1201
transfer lists: 42.1 megs
GatherLight: 0…1…2…3…4…5…6…7…8…9…10 (0)
Bounce #1 added RGB(24618, 40195, 43163)
GatherLight: 0…1…2…3…4…5…6…7…8…9…10 (0)
Bounce #2 added RGB(4097, 7172, 7875)
Build Patch/Sample Hash Table(s)…Done<0.2374 sec>
FinalLightFace: 0…1…2…3…4…5…6…7…8…9…10 (7)
FinalLightFace Done
182 of 182 (100% of) surface lights went in leaf ambient cubes.
ThreadComputeLeafAmbient: 0…1…2…3…4…5…6…7…8…9…10 (51)
Writing leaf ambient…done
Ready to Finish

Object names Objects/Maxobjs Memory / Maxmem Fullness


models 505/1024 24240/49152 (49.3%)
brushes 6610/8192 79320/98304 (80.7%) VERY FULL!
brushsides 64856/65536 518848/524288 (99.0%) VERY FULL!
planes 51022/65536 1020440/1310720 (77.9%)
vertexes 61574/65536 738888/786432 (94.0%) VERY FULL!
nodes 14454/65536 462528/2097152 (22.1%)
texinfos 10022/12288 721584/884736 (81.6%) VERY FULL!
texdata 1717/2048 54944/65536 (83.8%) VERY FULL!
dispinfos 0/0 0/0 ( 0.0%)
disp_verts 0/0 0/0 ( 0.0%)
disp_tris 0/0 0/0 ( 0.0%)
disp_lmsamples 0/0 0/0 ( 0.0%)
faces 32410/65536 1814960/3670016 (49.5%)
hdr faces 32410/65536 1814960/3670016 (49.5%)
origfaces 21023/65536 1177288/3670016 (32.1%)
leaves 14960/65536 478720/2097152 (22.8%)
leaffaces 43864/65536 87728/131072 (66.9%)
leafbrushes 14080/65536 28160/131072 (21.5%)
areas 2/256 16/2048 ( 0.8%)
surfedges 215878/512000 863512/2048000 (42.2%)
edges 147459/256000 589836/1024000 (57.6%)
LDR worldlights 0/8192 0/720896 ( 0.0%)
HDR worldlights 891/8192 78408/720896 (10.9%)
leafwaterdata 0/32768 0/393216 ( 0.0%)
waterstrips 0/32768 0/327680 ( 0.0%)
waterverts 0/65536 0/786432 ( 0.0%)
waterindices 0/65536 0/131072 ( 0.0%)
cubemapsamples 133/1024 2128/16384 (13.0%)
overlays 8/512 2816/180224 ( 1.6%)
LDR lightdata [variable] 0/0 ( 0.0%)
HDR lightdata [variable] 82261848/0 ( 0.0%)
visdata [variable] 3120468/16777216 (18.6%)
entdata [variable] 621228/393216 (158.0%) VERY FULL!
LDR ambient table 14960/65536 59840/262144 (22.8%)
HDR ambient table 14960/65536 59840/262144 (22.8%)
LDR leaf ambient 14960/65536 418880/1835008 (22.8%)
HDR leaf ambient 21186/65536 593208/1835008 (32.3%)
occluders 0/0 0/0 ( 0.0%)
occluder polygons 0/0 0/0 ( 0.0%)
occluder vert ind 0/0 0/0 ( 0.0%)
detail props [variable] 1/12 ( 8.3%)
static props [variable] 1/5732 ( 0.0%)
pakfile [variable] 11566015/0 ( 0.0%)
physics [variable] 2698787/4194304 (64.3%)
physics terrain [variable] 2/1048576 ( 0.0%)

Level flags = 0

Total triangle count: 65967
Writing c:\users\lioni\documents\hammermapprojects\rp_venator_cn\map\rp_venator_cn.bsp
5 minutes, 11 seconds elapsed
‘Fast - HDR’ compile finished in 00:05:24
2 errors/warnings logged:
(1) - make_triangles:calc_triangle_representation: Cannot convert (Warning)
(2) - fastvis = true (Info)

I’ve been looking into the first error that just showed up after fixing cubemap errors, but have had no luck fixing said error.

http://i.imgur.com/T6RhGtM.png[/t]

via Interloper’s compile log error checker.

What brushes/entities are at these coordinates? Try deleting them and see if a full compile still takes forever. You can type them into Hammer via View -> Goto Coordinates…

[t]http://i.imgur.com/JAWfz8b.png

Nothing is near those locations by at least 1000 each direction, that’s why I’m confused.

Yes, then on the chance that did break the compile, then could I fix it by copy and pasting the map on a fresh made vmf?

that wouldnt fix anything

Decompiling breaks a lot of things, especially stuff related to optimisation.

Try learning about visclusters
There are many tutorials you can use.

I have learned quite a bit, but what would help with this situation? Could you point me in the right direction of tutorials about what I would have to fix/check about visclusters? I’ve learned how to “optimize” correctly, just never learned this problem. Thanks in advance.

Visclusters can be used to shorten compile time on a full vis compile. Cover large empty areas (e.g. portions of space) with a viscluster brush.

Oh I’m sorry for the misunderstanding, ok I’ll look into that asap. That would help visleaf count wise, but would it fix a decompile broken compile error you talked about earlier?

Well, your map compiles fine on vis set to fast. So your only problem appears to be that normal vis is taking too long. Visclusters could fix that

Well after doing some studies into visclusters and placing them I’ve dropped to 7616 Numportals which is a big improvement. Is that number low enough to only have to wait a couple hours for vvis to finish and move onto vrad? I’m still using 3 threads on my I5-6600k at 4.5 GHz for it though.

Honestly, it’s a Venator. So long as your interiors are properly optimized with areaportals, I’d say it’s alright to compile on fast vis.

It worked, I made visclusters for everything on the outside of the ship to the skybox and the vvis took only 3 hours, thanks for the help; it took me 2 weeks to find out something that I could of just asked about.

Areaportals don’t work properly on fast vis