please help area portal traouble!

[Rabbit]

I have a problem where I seal off a boulding in my map with area portals. The building is seperating two large areas and windows are a pain in the ass for optimasition. Now whenever i enter the buildings the parts where the windows are texture lag like when you fall out in the void and can kinda paint the sky with the lagging texture of your gun. This is only in the windows and only when I am inside of the building. It also only ocures when I get close to the windows.
The game is Tf2 and i will post the compile log but i checked it and there were only these problems non of wich i can link to the wird area portal bug im having:
can't load skybox file skybox/sky_night_01 to build the default cubemap!
make_triangles:calc_triangle_representation: cannot convert
fastvis = true
zero area child patch

Please help and thanks for reading :)

[Rabbit]

** Executing...
** Command: "C:\Program Files (x86)\Steam\SteamApps\common\Team Fortress 2\bin\vbsp.exe"
** Parameters: -game "C:\Program Files (x86)\Steam\SteamApps\common\Team Fortress 2\tf" "E:\mapping\Team Fortress 2\cp_change\cp_change_alpha_2.vmf"

Valve Software - vbsp.exe (Mar 4 2014)
4 threads
materialPath: C:\Program Files (x86)\Steam\SteamApps\common\Team Fortress 2\tf\materials
Loading E:\mapping\Team Fortress 2\cp_change\cp_change_alpha_2.vmf
ConVarRef mat_reduceparticles doesn't point to an existing ConVar
Patching WVT material: maps/cp_change_alpha_2/dev/dev_blendmeasure_wvt_patch
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 (1)
Chop Details...done (0)
Find Visible Detail Sides...
Merged 82 detail faces...done (0)
Merging details...done (0)
FixTjuncs...
PruneNodes...
WriteBSP...
done (3)
writing E:\mapping\Team Fortress 2\cp_change\cp_change_alpha_2.prt...Building visibility clusters...
done (0)
*** Error: Skybox vtf files for skybox/sky_night_01 weren't compiled with the same size texture and/or same flags!
Can't load skybox file skybox/sky_night_01 to build the default cubemap!
*** Error: Skybox vtf files for skybox/sky_night_01 weren't compiled with the same size texture and/or same flags!
Can't load skybox file skybox/sky_night_01 to build the default cubemap!
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 (0) (2214348 bytes)
Placing detail props : 0...1...2...3...4...5...6...7...8...9...10
Compacting texture/material tables...
Reduced 5992 texinfos to 3137
Reduced 20 texdatas to 17 (505 bytes to 415)
Writing E:\mapping\Team Fortress 2\cp_change\cp_change_alpha_2.bsp
9 seconds elapsed
-0.812800 -2.641600 0.000000
-0.812800 -2.438400 0.000000
-0.812800 2.438400 0.000000
-2.438400 -2.438400 0.000000
make_triangles:calc_triangle_representation: Cannot convert
-0.812800 -2.438400 0.000000
-2.438400 2.641600 0.000000
-0.812800 2.641600 0.000000
-0.812800 -2.641600 0.000000
make_triangles:calc_triangle_representation: Cannot convert
-0.812800 -2.438400 0.000000
-2.438400 2.641600 0.000000
-0.812800 2.641600 0.000000
-0.812800 -2.641600 0.000000
make_triangles:calc_triangle_representation: Cannot convert

** Executing...
** Command: "C:\Program Files (x86)\Steam\SteamApps\common\Team Fortress 2\bin\vvis.exe"
** Parameters: -game "C:\Program Files (x86)\Steam\SteamApps\common\Team Fortress 2\tf" -fast "E:\mapping\Team Fortress 2\cp_change\cp_change_alpha_2"

Valve Software - vvis.exe (Mar 4 2014)
fastvis = true
4 threads
reading e:\mapping\team fortress 2\cp_change\cp_change_alpha_2.bsp
reading e:\mapping\team fortress 2\cp_change\cp_change_alpha_2.prt
7333 portalclusters
22836 numportals
BasePortalVis: 0...1...2...3...4...5...6...7...8...9...10 (18)
Optimized: 1769344 visible clusters (3.87%)
Total clusters visible: 45669663
Average clusters visible: 6227
Building PAS...
Average clusters audible: 7313
visdatasize:13106786 compressed from 13492720
writing e:\mapping\team fortress 2\cp_change\cp_change_alpha_2.bsp
27 seconds elapsed

** Executing...
** Command: "C:\Program Files (x86)\Steam\SteamApps\common\Team Fortress 2\bin\vrad.exe"
** Parameters: -game "C:\Program Files (x86)\Steam\SteamApps\common\Team Fortress 2\tf" -noextra "E:\mapping\Team Fortress 2\cp_change\cp_change_alpha_2"

Valve Software - vrad.exe SSE (Mar 4 2014)

Valve Radiosity Simulator
4 threads
[Reading texlights from 'lights.rad']
[34 texlights parsed from 'lights.rad']

Loading e:\mapping\team fortress 2\cp_change\cp_change_alpha_2.bsp
Setting up ray-trace acceleration structure... Done (3.65 seconds)
30841 faces
2936265 square feet [422822240.00 square inches]
80 Displacements
199 Square Feet [28765.75 Square Inches]
30841 patches before subdivision
zero area child patch
zero area child patch
zero area child patch
zero area child patch
418619 patches after subdivision
sun extent from map=0.087156
3340 direct lights
BuildFacelights: 0...1...2...3...4...5...6...7...8...9...10 (296)
BuildVisLeafs: 0...1...2...3...4...5...6...7...8...9...10 (367)
transfers 86008656, max 5015
transfer lists: 656.2 megs
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (1)
Bounce #1 added RGB(2582069, 1461280, 1343258)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
Bounce #2 added RGB(450677, 126795, 112115)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
Bounce #3 added RGB(122256, 13947, 12502)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
Bounce #4 added RGB(39154, 1596, 1430)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
Bounce #5 added RGB(14224, 197, 178)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (1)
Bounce #6 added RGB(5521, 25, 23)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
Bounce #7 added RGB(2243, 3, 3)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
Bounce #8 added RGB(940, 0, 0)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
Bounce #9 added RGB(404, 0, 0)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
Bounce #10 added RGB(177, 0, 0)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
Bounce #11 added RGB(79, 0, 0)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (1)
Bounce #12 added RGB(36, 0, 0)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
Bounce #13 added RGB(16, 0, 0)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
Bounce #14 added RGB(7, 0, 0)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
Bounce #15 added RGB(3, 0, 0)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
Bounce #16 added RGB(2, 0, 0)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
Bounce #17 added RGB(1, 0, 0)
Build Patch/Sample Hash Table(s).....Done<0.0967 sec>
FinalLightFace: 0...1...2...3...4...5...6...7...8...9...10 (19)
FinalLightFace Done
127 of 734 (17% of) surface lights went in leaf ambient cubes.
ThreadComputeLeafAmbient: 0...1...2...3...4...5...6...7...8...9...10 (32)
Writing leaf ambient...done
Ready to Finish

Object names Objects/Maxobjs Memory / Maxmem Fullness
------------ --------------- --------------- --------
models 86/1024 4128/49152 ( 8.4%)
brushes 6227/8192 74724/98304 (76.0%)
brushsides 42104/65536 336832/524288 (64.2%)
planes 11912/65536 238240/1310720 (18.2%)
vertexes 45167/65536 542004/786432 (68.9%)
nodes 15622/65536 499904/2097152 (23.8%)
texinfos 3137/12288 225864/884736 (25.5%)
texdata 17/2048 544/65536 ( 0.8%)
dispinfos 80/0 14080/0 ( 0.0%)
disp_verts 2000/0 40000/0 ( 0.0%)
disp_tris 2560/0 5120/0 ( 0.0%)
disp_lmsamples 5120/0 5120/0 ( 0.0%)
faces 30841/65536 1727096/3670016 (47.1%)
hdr faces 0/65536 0/3670016 ( 0.0%)
origfaces 17968/65536 1006208/3670016 (27.4%)
leaves 15709/65536 502688/2097152 (24.0%)
leaffaces 35950/65536 71900/131072 (54.9%)
leafbrushes 13928/65536 27856/131072 (21.3%)
areas 6/256 48/2048 ( 2.3%)
surfedges 219440/512000 877760/2048000 (42.9%)
edges 127850/256000 511400/1024000 (49.9%)
LDR worldlights 3340/8192 293920/720896 (40.8%)
HDR worldlights 0/8192 0/720896 ( 0.0%)
leafwaterdata 0/32768 0/393216 ( 0.0%)
waterstrips 2970/32768 29700/327680 ( 9.1%)
waterverts 0/65536 0/786432 ( 0.0%)
waterindices 53130/65536 106260/131072 (81.1%) VERY FULL!
cubemapsamples 0/1024 0/16384 ( 0.0%)
overlays 5/512 1760/180224 ( 1.0%)
LDR lightdata [variable] 9313968/0 ( 0.0%)
HDR lightdata [variable] 0/0 ( 0.0%)
visdata [variable] 13106786/16777216 (78.1%)
entdata [variable] 1049320/393216 (266.9%) VERY FULL!
LDR ambient table 15709/65536 62836/262144 (24.0%)
HDR ambient table 15709/65536 62836/262144 (24.0%)
LDR leaf ambient 52490/65536 1469720/1835008 (80.1%) VERY FULL!
HDR leaf ambient 15709/65536 439852/1835008 (24.0%)
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/65182 ( 0.0%)
pakfile [variable] 741/0 ( 0.0%)
physics [variable] 2214348/4194304 (52.8%)
physics terrain [variable] 23128/1048576 ( 2.2%)

Level flags = 0

Total triangle count: 85608
Writing e:\mapping\team fortress 2\cp_change\cp_change_alpha_2.bsp
12 minutes, 2 seconds elapsed

** Executing...
** Command: Copy File
** Parameters: "E:\mapping\Team Fortress 2\cp_change\cp_change_alpha_2.bsp" "C:\Program Files (x86)\Steam\SteamApps\common\Team Fortress 2\tf\maps\cp_change_alpha_2.bsp"


** Executing...
** Command: "C:\Program Files (x86)\Steam\SteamApps\common\Team Fortress 2\hl2.exe"
** Parameters: -game "C:\Program Files (x86)\Steam\SteamApps\common\Team Fortress 2\tf" +map "cp_change_alpha_2" -steam

[Rectus]

I'm not really sure what causes your issue, but some of the compile errors and/or performance issues could contribute to it.

Originally posted by Rabbit - thecookiefactory.org:

can't load skybox file skybox/sky_night_01 to build the default cubemap!
make_triangles:calc_triangle_representation: cannot convert

These probably don't have anything to do with the issue. The make_triangles error seems to be related to the collision models of props.

fastvis = true

Try running VVIS in normal mode. If you can't get it to finish, you'll likely need to optimize the compile-time visibility between visleaves, which, by your description would involve some drastic changes in your large areas.

zero area child patch

This is caused by invalid brushes with zero-area faces. Make sure to merge overlapping vertices when using the vertex tool.

Also, which entites are you using for the areaportals, func_areaportal or func_areaportalwindow?

[Rabbit]

i am currently trying to optimise the areas ,the thing is that there are a ♥♥♥♥ load of windows in the map i thaught that by addibg area portals i could get araund making the whole map smaller. I have tried areaportal window first but this problem came up then i reverted back to plain old area portals but the bug persisted. I cant render in normal because last time i tried i gave up at the 4 th day of rendering, i thaught that by using area portals i yould make the map render in normal mode in a reasonable time. do you think i should try rendering it in normal mode with the bug still in? And do you think that by adding area portals i could get araunde changeing the whole map?

Thanks for the reply

[Rectus]

Try using the cordon tool to only compile the part of the level with the building, to see if nomal mode helps.

Unfortunately area portals only work after the compilation is done, in-game. And unless you close them (hard to get working in multiplayer), all they do they check for which visleaves the player can currently see through them. Area portals can actually make performance worse if you have a lot of visleaves potentially visible through them and/or lots of areaportals visible at the same time.

And since fast VVIS doesn't test visibility between all the visleavs properly, it will give the area portal calculations a bigger set of visleaves to test, and put even more pressure on them.

To get most use of your area portals, you'd need to to a normal compile of your entrie map, and go around looking at it with mat_wireframe 1 to see if there are any places where a lot of out-of-sight areas render, and use that to determine where to place the portals.

I don't think there is any real way of getting around changing the whole map, but it's hard to tell for certain without seeing it.

[Rabbit]

thanks for the help i see how area portals dont really woork as I thaught tey would. I have some ideas now , the cordon tool could help me check the area i am interested in.
thanks again :)

[[B.n.B] AlcyToronto]

Are you sure you put the areaportals properly? The log does not talk about leaks, and the "void" that you see (endless mirrors) is the close areaportal. if you put it on doors and windows that open you have to set it close and connected to the door (of course the areaportal must be done with a brush thinner than the door itself, I usually use 1 unit brush). If you put it in always open window you must set it "open". The void is only visible when you can see a closed areaportal, and this must not happen!

[Rabbit]

I made literaly all the mistakes you listed here thank you a lot.I feel like a litle idiot for making them now :)

[[B.n.B] AlcyToronto]

No problem mate, mapping requires e real endless learning, and sharing the informations is the best way to improve, in my opinion... Moreover the areaportals are not so "user friendly"... :)
Pay attention to eventual func_details (doors and window's frames, in example) when you use areaportals, remember that func_details don't close anything. Better to hide them in the "auto vis group" when you are plannig and building the areaportals, otherwise you'll have areaportal leaks!

[Rabbit]

The thing with my doors are that they open upward's (like genereic tf2 spawn doors you get the idea) and I always leave a gap for the door to scroll in to so that its not hitting the brush. like this the there are 3 directions in wich my door is exposed (up front back). If I make the area portal thinner than the door there would be a leak. So should I joust let the door pirce the brush and not leave a gap or should I make the area portal the same size as my door if that would woork too?

[[B.n.B] AlcyToronto]

You have to put the areaportal exactly corresponding to the doorway, and there must be no space between the door and the doorway, otherwise, through that space, you would see the closed areaportal. If the door is thick 3 or more units, creates the brush areaportal of 1 unit , and enter fully into the thickness of the door. As soon as you open the door even the areaportal will open , and you will not see the endless mirrors, nor leaks.
I usually , for convenience and to avoid wrong sizing, do in this way:

- select the door ( selecting solids )
- copy
- paste special ( leaving all values ​​to 0 )
- assign the areaportal texture to the new created brush
- move selected to entity ( choosing func_areaportal )
- set the areaportal "close" and link it to the door name
- decrease the areaportal thickness to 1 unit.

Remember to close ALL the openings of the building with areaportals, or you'll have a leak.
For only open windows, set the areaportal "open". In this way it will not close completely the building , but the graphics engine will draw only the visible brushes through the window ... better than nothing , right?