Map Visual Glitches

I’ve got weird visual glitches with my map, the glitching only happens around buildings that are areaportaled off, the map does have visclustering but the problem persists when vvis is run on fast with and without the visclusters enabled and it also persists when vvis is run in full with visclusters enabled. originally i though it was all of the complex areas that were sealed off as seen in the third picture, the green arched stuctures, because originally those were all world, i tried detailing them and removed their areaportaling but the problem still persists. Anyone got any ideas on what im doing wrong?


[T]http://i.imgur.com/2ud7Ar7.jpg[/T]
[T]http://i.imgur.com/BpJTzSe.jpg[/T]
[T]http://i.imgur.com/0KFkQIG.jpg[/T]
[T]http://i.imgur.com/hEvYtd8.jpg[/T]
[T]http://i.imgur.com/LHgpxfw.jpg

the pictures are of the map with fast vis, visclusters and no rad compiled with 03C0’s vbsp and Garry’s Mods stock vvis compilers

Add a screenshot of your area portal settings and the windows / doors they’re using too.


[T]http://i.imgur.com/9DFNEcc.png[/T]
[T]http://i.imgur.com/6KyM1fY.png

Looks to be alright, just remember that func_area portal window will make your targeted window brush fade and appear, but that shouldnt be the issue here. My only other thought is an area portal leak. Try to load up the maps poinot file in the edit menu, see if it brings up anything.

Otherwise I’m free for an hour if you’d want to trust your vmf to me.

I didnt get any leak errors on compile

heres the compile log, i can send you the vmf too i guess…


materialPath: D:\Steam\steamapps\common\Source SDK Base 2013 Multiplayer\sourcetest\materials
Loading d:\development\mapping\rp_bracket\rp_bracket_v85.vmf
ConVarRef mat_reduceparticles doesn't point to an existing ConVar
Could not locate 'GameData' key in d:\steam\steamapps\common\source sdk base 2013 multiplayer\sourcetest\gameinfo.txt
Patching WVT material: maps/rp_bracket_v85/havok/blendrock1grass1_d_wvt_patch
Patching WVT material: maps/rp_bracket_v85/havok/blendrock1grass1_wvt_patch
Patching WVT material: maps/rp_bracket_v85/havok/blendsand2sand3_wvt_patch
Patching WVT material: maps/rp_bracket_v85/havok/blendsand2grass1_d_wvt_patch
Patching WVT material: maps/rp_bracket_v85/havok/blendsand2sand3_skybox_wvt_patch
Patching WVT material: maps/rp_bracket_v85/havok/blendbud005grass1_skybox_wvt_patch
Patching WVT material: maps/rp_bracket_v85/havok/blendbud005grass1_d_wvt_patch
fixing up env_cubemap materials on brush sides...
0...1...2...3...4...5...6...7...8...9...100...1...2...3...4...5...6...7...8...9...10Processing areas...done (0)
Building Faces...done (0)
Chop Details...done (0)
Find Visible Detail Sides...
Merged 2940 detail faces...done (1)
Merging details...done (0)
FixTjuncs...
PruneNodes...
WriteBSP...
done (3)
writing d:\development\mapping\rp_bracket\rp_bracket_v85.prt...Building visibility clusters...
done (0)
Finding displacement neighbors...
Finding lightmap sample positions...
Displacement Alpha : 0...1...2...3...4...5...6...7...8...9...10
Building Physics collision data...

qhull precision error: Only 4 facets remain.  Can not merge another
pair.  The convexity constraints may be too strong.  Reduce the
magnitude of 'Cn' or increase the magnitude of 'An'.  For example,
try 'C-0.001' instead of 'C-0.1' or 'A-0.999' instead of 'A-0.9'.

qhull precision error: Only 4 facets remain.  Can not merge another
pair.  The convexity constraints may be too strong.  Reduce the
magnitude of 'Cn' or increase the magnitude of 'An'.  For example,
try 'C-0.001' instead of 'C-0.1' or 'A-0.999' instead of 'A-0.9'.
done (6) (2509037 bytes)
Placing detail props : 0...1...2...3...4...5...6...7...8...9...10
Compacting texture/material tables...
Reduced 5305 texinfos to 3833
Reduced 404 texdatas to 326 (16889 bytes to 13580)
Writing d:\development\mapping\rp_bracket\rp_bracket_v85.bsp
18 seconds elapsed



8 threads
reading d:\development\mapping\rp_bracket\rp_bracket_v85.bsp
reading d:\development\mapping\rp_bracket\rp_bracket_v85.prt
2071 portalclusters
5772 numportals
0...1...2...3...4...5...6...7...8...9...10Optimized: 375737 visible clusters (11.93%)
Total clusters visible: 3149849
Average clusters visible: 1520
Building PAS...
Average clusters audible: 2048
visdatasize:995599  compressed from 1093488
writing d:\development\mapping\rp_bracket\rp_bracket_v85.bsp
7 seconds elapsed

Alright, so here’s what I’ve “found”, but I wasn’t able to have the time to compile your map and run it on my end. I can do that later if this remains unsolved.

The good:

  • I like the map, interesting set up.
  • Area portals are sealing everything off, you didn’t leave a wrap-around anywhere (where it comes around and touches itself because it wasn’t sealed)
  • Door area portals are set to “closed”, which is great (it defaults to open for some dumb reason).

The “bad”:

  • Your area portals are sketchy. You have one areaportalwindow brush covering 5-6 windows at a time.
  • Your windows are not named, but your func_areaportalwindow brushes are targeting a window (that doesn’t exist)

I couldn’t figure out why your problem is being caused, so I did what I always do: If I can’t solve it, I will make an example map for you to model from.

http://puu.sh/spW5n/be7e52ef7b.vmf

What I do for areaportals:
Windows:

  • Tie a solid color like black, to func_brush and name it. Target that brush with your portal, and leave the actual window texture alone. What happens when you tie an areaportalwindow to a brush is that it makes that brush fade in and out. To make sure my window is always visible, I just create a black brush to tie the window to. Create a nice darkening effect for when the portal seals off.
  • My fade distances were set to be close so you can test out what it does inside the map
  • Make the areaportal brush 1 unit thick, and use the CTRL+M tool to move it 0.5 units on the X or Y, whichever way makes it center itself inside your window. That way your areaportal is in the middle and you don’t have any see-through texture issues like you seem to be having.

Doors:

  • Place the door within a 2-4 unit thick “frame”, this is to make sure the door closes. I’ve had problems of doors not closing because I didn’t build a frame. Tie it to func_detail.
  • Make an areaportal the side of the door AND the frame, make it 1 unit thick. Move it as close to the center of the door as you can, and do the same CTRL+M, 0.5 movement to make it sit in the center.

Spend some time fixing up your windows and see what happens.

Also, side note, not sure if areaportalwindow works with func_breakable_surf - Could be wrong though. Haven’t tested it.

[Edit]

I have no idea what this is, or what it means, but I’d try looking into that as well. I’ve never seen this error before and do not have time to google it… Again, can do it later if nobody else responds.

the qhull precision error is just a displacement being retarded somewhere, the error can be ignored for the most part, the areaportal windows are set up how they are to reduce the total number of areaportals in the map.
since its open world and there are alot of buildings that are going to be alittle heavier on detail inside that need to be sealed off, earlier in testing i had all the windows areaportals separate and my game was crashing because there were too many areaportals visible at once.

im pretty sure the areaportal windows don’t need to be nammed, ive never named my areaportals and never had a problem like this before, but they are supposed to be referring to func_illusionary brushes for the rendered window.

EDIT
everything in this map was working fine until i added all the buildings in [DEL]quad 1[/DEL] quad 4 of the map.

i will try redoing all my areaportaling and see if that fixes anything

I think you’re right, they don’t need to be named, I’ve just always named them with a black brush to cause a realistic fade to it instead of seeing through the world.

Until someone else replies or I get time to crack it open again, focus on that quad where you put the buildings in. Try using hide/unhide on a couple rooms at a time until it works again, and then you’ll have a better area to focus on.

Well fuck, i just compiled the map without areaportals and the problem still persists therefore i am ruling out areaportals as being the problem… i have no idea whats causing this.

(original post snipped)

You have a skybox surrounding your map that uses the entire hammer grid size… smacks hand - NO! Bad mapper.

Only make your skybox the exact size of what is necessary to have to surround the accessible area of your map. I also noticed you have a 3d skybox, but it’s within the encompassing skybox around the hammer grid. I have a strong feeling if you fix this, your problem will be resolved.

Get back to me on that ^

I did a bunch of test compiles cordoning off the map into 2 quads and everything is fine but if the map is compiled as a whole there are visual indices.

i have also compiled the map with the skybox disabled with the same problem.
i mean the problem started when i added all the geom into quad 4, everything else was there before.

i just noticed i said quad 1 above. i meant quad 4 not 1

EDIT

Ive made a bunch of maps using around the same max gridsize ±64 units than this one with no problems, like i said, this is a recently occurring problem. i think if i was going to be getting visual indices with the map i would see them from the beginning not now.

Hard to tell without seeing the VMF, but would you be able to move your whole map so none of it intersects the origin? I think vvis splits vis leafs along the X Y of the origin. It’s caused some weird issues for me in the past.

Although, prob won’t help at all, might be worth a try.

Compiling bsp with -notjunc fixes the problem. im pretty sure the modded compiler im using screws up something with detail brush optimizations or something.