VIS always runs in fast mode?

[psihomir]

I'll just copy the thread from Steampowered

Okay, this is killing me. I've tried everything I know of, and it won't work.

Basically, BSP compiles without any (critical) errors, and then VIS always does a fast compile and gives me a map with only 1 visblock.

I tried skyboxing it, cordoning a tiny bit of it still, with geometry inside it that would otherwise divide into visblocks. I'm using the new SDK beta, but all of my other maps compile fine, so it can't be vis itself. I deleted all the old compile files and left the VMT to compile freshly.

Nothing

Here's my compile log (up to VIS, I didn't do RAD at all)

materialPath: d:\soft\steam\steamapps\zavist\team fortress 2\tf\materials
Loading D:\dev\vmf\cp_white_valley_a9.vmf
Patching WVT material: maps/cp_white_valley_a9/snowvalley/snowrockblend002_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 466 detail faces...done (1)
Merging details...done (0)
FixTjuncs...
PruneNodes...
WriteBSP...
done (1)
writing D:\dev\vmf\cp_white_valley_a9.prt...Building visibility clusters...
done (1)
Creating default LDR cubemaps for env_cubemap using skybox materials:
   skybox/sky_day01_01*.vmt
 ! Run buildcubemaps in the engine to get the correct cube maps.
Creating default HDR cubemaps for env_cubemap using skybox materials:
   skybox/sky_day01_01*.vmt
 ! Run buildcubemaps in the engine to get the correct cube maps.
Finding displacement neighbors...
Found a displacement edge abutting multiple other edges.
Finding lightmap sample positions...
Displacement Alpha : 0...1...2...3...4...5...6...7...8...9...10
Building Physics collision data...
done (2) (915250 bytes)
Error! prop_static using model "models/props_gameplay/orange_cone001.mdl", which must be used on a dynamic entity (i.e. prop_physics). Deleted.
Error loading studio model "models/props_gameplay/orange_cone001.mdl"!
Error! To use model "models/player/heavy.mdl"
      with prop_static, it must be compiled with $staticprop!
Error loading studio model "models/player/heavy.mdl"!
Error! To use model "models/buildables/sentry3.mdl"
      with prop_static, it must be compiled with $staticprop!
Error loading studio model "models/buildables/sentry3.mdl"!
Placing detail props : 0...1...2...3...4...5...6...7...8...9...Material SNOWVALLEY/SNOWGRASSBLEND001 uses unknown detail object type tf_forest_grass!
Material SNOWVALLEY/SNOWGRASSBLEND001 uses unknown detail object type tf_forest_grass!
10
Water found with no water_lod_control entity, creating a default one.
Compacting texture/material tables...
Reduced 4981 texinfos to 3295
Reduced 98 texdatas to 95 (2054 bytes to 1889)
Writing D:\dev\vmf\cp_white_valley_a9.bsp
24 seconds elapsed



2 threads
reading d:\dev\vmf\cp_white_valley_a9.bsp
reading d:\dev\vmf\cp_white_valley_a9.prt
   1 portalclusters
   0 numportals
0...1...2...3...4...5...6...7...8...9...10
0...1...2...3...4...5...6...7...8...9...10
Optimized: 0 visible clusters (0.00%)
Total clusters visible: 1
Average clusters visible: 1
Building PAS...
Average clusters audible: 1
visdatasize:14  compressed from 16
writing d:\dev\vmf\cp_white_valley_a9.bsp
0 seconds elapsed

 

[Loc_n_lol]

Hmmm... Have you tried opening the portal file in hammer to see if it looks right ?

 

[A Boojum Snark]

VVIS has the 0-10 progress twice, which means it isn't actually running on fast (fast only performs one of the two steps), and running on fast doesn't mean it's all one cluster either.

However the log doesn't really say anything to indicate what is wrong. Very unusual. :/

 

[kwagner]

Isn't there a problem with using the skybox texture 'sky_day01_01'? Maybe use one of the following instead and see if things complete:
sky_dustbowl_01
sky_granary_01
sky_gravel_01
sky_well_01
sky_tf2_04
sky_hydro_01


You've got errors on using the orange cone, Heavy and sentry gun as prop_statics. But I think that just causes them to be deleted, not vvis failures.

There is an error 'Found a displacement edge abutting multiple other edges.' (Just under the skybox section) Would that cause vvis to halt? (I dunno)

 

[psihomir]

Thanks, I'll try changing the skybox.

Like I said, the problems reported by BSP are not critical, since they were there before this started happening. And when I cordon off a tiny area of the map, it still doesn't compile properly, even though BSP doesn't encounter any problems at all.

Snark, I understand it's still not the true fast mode, I just didn't know what to call it

I'll try the skybox thing for now, let's hope it works - although I'm sure I've compiled TF2 maps with the default one before...

 

[psihomir]

Nope, no juice with a TF2 skybox.

This is really starting to puzzle me. I've never encountered anything remotely similar, and I can't understand what's causing it. It's apparently not a corrupted file, because I copied the contents of the entire map into a new VMF and it still refused to compile properly.

 

[kwagner]

I'm still new at this. Out of ideas here.

 

[Gadget]

How big is your map? The log says you have 0 visible clusters and only 1 visleaf:

Optimized: 0 visible clusters (0.00%)
...
Average clusters visible: 1
...
Average clusters audible: 1

That's totally unusual unless you only have one small room.? I think you might need to post or send you vmf file for a closer look.

 

[psihomir]

It's quite big, actually. I'm not really comfortable with posting the VMF on a public forum, but I can send it to you if you'd like.

 

[Loc_n_lol]

If all else fails : edit -> select all, copy, file -> new, edit -> paste special ?

 

[psihomir]

If all else fails : edit -> select all, copy, file -> new, edit -> paste special ?

Sadly, no:

It's apparently not a corrupted file, because I copied the contents of the entire map into a new VMF and it still refused to compile properly.

 

[Loc_n_lol]

Ok... then at least you know there has to be a logical explanation...
Tried to open the portal file as I said ? 24 seconds sounds quite long for vbsp... (though it depends what your computer is, I suppose, and you said the map is large)
No invalid brushes or other stuff like that ?

 

[psihomir]

The portal file is only 12 bytes and its entire contents are:

PRT1
1
0

No invalid brushes - at least none reported by Hammer.

 

[Loc_n_lol]

The portal file is only 12 bytes and its entire contents are:

PRT1
1
0

Then you have a serious problem with the early part of vbsp though I fail to see what... it's almost as if there was a leak. :blink:

 

[psihomir]

Exactly, it's very weird and it shouldn't happen by any logic. I think the only solution at this point would be to start cutting pieces from the map into new maps and compiling them on their own, until I get to the problem. Ah, the forgotten old method of finding leaks, before those fancy pointfiles came to be

 

[psihomir]

Aaaaand the fun just doesn't stop!

I found the problem. It was the sky_camera entity. Removing it makes the map compile normally. Now, if I could only find out WHY?

It's correctly placed at 0,0,0 and the 3d sky worked fine a few compiles ago.

Wtf.

 

[psihomir]

Solved. I had two sky_camera's

Bloody hell, why doesn't the compiler warn about that?

Thanks to everyone who helped.

 

[kwagner]

Glad you found the problem!