vvis.exe acting crazy...

  • If you're asking a question make sure to set the thread type to be a question!

PoisonHeadcrab

L1: Registered
Jun 27, 2010
14
0
Not a long time ago I started working on a TF2 map again after I've not been doing any mapping for about a half a year. But now that I tried to compile my map, I encountered the following problem that I've never encountered on earlier compiles I made a while ago:

A few moments after launching the compile process, the program either loops or completely freezes. Additionally the whole system is acting extremely slow, even the mouse icon is moving hardly and very laggy, so I'm having a hard time just opening the task manager and terminating the process, most of the time I had to restart my computer.


At first I thought it was just some simple optimization mistake I made but now that I've looked more into the problem it appears that it's the VVIS process that is having these problems on most of the maps. While VVIS is running, my CPU usage goes up to 100% and it seems to take just too much time to compile than it actually should (I've never actually finished any compiles so I can't really tell if it really would compile or not. But what I know for sure is I had a FAR more complex map compiled in less time half a year ago than I left my alpha-staged map compiling without any apparent progress). The only way I made the map I'm currently working on compile, is removing the big skybox and outdoor areas I drew around the main building and sealing it, because I don't seem to have this problem at all on all-inside maps without skies, that make the system lag aswell but atleast compile in a reasonable amount of time.



What has changed to make the vvis.exe process act like this and how could I possibly circumvent the problem of that extremely slow compiling and unusable system? Has anyone else ever experienced this problem before?


Here my system specs:

Intel Core 2 Quad Q8200 @ 2.33 GHz
4 GB DDR2 RAM
NVIDIA GeForce 250 GTS



Any help would be greatly appreciated!
 

PL-7764

L6: Sharp Member
Aug 4, 2009
376
84
Everything you described is actually normal for VVIS. It might look like it's crashed, but it actually hasn't. It will push your CPU to 100%, and it will cause your machine to lag if you keep trying to use it. Just wait it out and it will finish eventually. ;)

If it's still sitting there after a really long time (like an hour), chances are either you carved something while making the map, which causes VVIS to go insane, or it really has crashed.
 
Last edited:

Huckle

L3: Member
May 31, 2010
149
101
At first I thought it was just some simple optimization mistake I made but now that I've looked more into the problem it appears that it's the VVIS process that is having these problems on most of the maps. ... The only way I made the map I'm currently working on compile, is removing the big skybox and outdoor areas I drew around the main building and sealing it, because I don't seem to have this problem at all on all-inside maps without skies, that make the system lag aswell but atleast compile in a reasonable amount of time.

Your first part here is likely correct, generally outdoor areas are the parts that require vis optimization, which is why removing the big skybox helps. If you can see over buildings or have any other open spaces between the solids and the skybox you will have massively increased vvis times.

In fact, my first map took something like 6½ hours to compile and on my artpass entry I went from around 90 minutes on vvis to 16 or so in less than a days work. Once you've made your skybox as small as it can be and made everything you can into func_details, look into hints and visclusters.

Being unable to use your computer while compiling and having the compilation process crash if you start browsing is nothing out of the ordinary. :)
 
Last edited:

PoisonHeadcrab

L1: Registered
Jun 27, 2010
14
0
Your first part here is likely correct, generally outdoor areas are the parts that require vis optimization, which is why removing the big skybox helps. If you can see over buildings or have any other open spaces between the solids and the skybox you will have massively increased vvis times.

In fact, my first map took something like 6½ hours to compile and on my artpass entry I went from around 90 minutes on vvis to 16 or so in less than a days work. Once you've made your skybox as small as it can be and made everything you can into func_details, look into hints and visclusters.

Being unable to use your computer while compiling and having the compilation process crash if you start browsing is nothing out of the ordinary. :)

While I have already thought about that it may not be a problem at all, I still wonder how a half a year ago I was able to compile a HUGE map in an advanced stage with a building in the middle in just about 15 minutes while being very well able to use the computer otherwise without any major complications.

What could have possibly changed?
 
Sep 1, 2009
573
323
There is a reason why smart people compile on fast for testing and compile the proper version on normal or something else overnight
 

Huckle

L3: Member
May 31, 2010
149
101
While I have already thought about that it may not be a problem at all, I still wonder how a half a year ago I was able to compile a HUGE map in an advanced stage with a building in the middle in just about 15 minutes while being very well able to use the computer otherwise without any major complications.

What could have possibly changed?

Well, the easiest thing that could have changed would be going between fast and normal compiles or having a leak which stops vvis entirely. If the exact same map takes longer though, that's when it gets interesting.

Complicated geometry is generally not what causes longer vvis times (as long as you keep it reasonable and use 90 degree angles). The worst part is having extreme sight lines which makes all the separate visleaves take eachother into account, even if they're on opposite sides of the map.
 

PoisonHeadcrab

L1: Registered
Jun 27, 2010
14
0
I've actually never used the "fast" feature, since pretty much everything I compiled on normal was of manageable time, so I didn't really need it. What would be the differences between the two compiles you would notice ingame anyways?


Also I'll try to compile that one map I was talking about now again and see if it actually takes alot more than 20-30 minutes.

Maybe what was causing my current map to compile so slow were the overlapping gable roofs (world brushes) on the big middle building, which needed quite alot of compicated diagonal clips to fit perfectly into eachother, now that I think of it. I may try that again with the roofs func_detailed or something like that.
 

Sgt Frag

L14: Epic Member
May 20, 2008
1,443
710
Most likely you are now compiling lighting on normal, or HDR.

A map will compile in seconds without lighting. With full lighting and HDR it can take hours. It's the lighting, not the compiling that takes a long time.

I always test compile with fast or no lighting and 'Don't go ingame' checked. Make sure there are no leaks. Then compile lighting depending on your needs. Really no reason to even use HDR until you have detailed quite a bit and really want to get to the nitty gritty lighting details.

(I only use fast vis if I just need to check a quick change real fast and am not worried about optimization at all - if you know regular vis is fine no need to compile it every time you test).
 

lana

Currently On: ?????
aa
Sep 28, 2009
3,075
2,778
I've actually never used the "fast" feature, since pretty much everything I compiled on normal was of manageable time, so I didn't really need it. What would be the differences between the two compiles you would notice ingame anyways?

I recommend not using fast options for any setting. The results are strange and very because VVIS and VRAD do not run their complete operations. Fast VVIS generally produces maps that are more poorly optimized or that have critical issues involving visibility (such as certain visleaves not showing.) Fast VRAD will produce abnormal lighting caused by lack of bounces. It reduces compile time a lot but produces shit results.
 

Sgt Frag

L14: Epic Member
May 20, 2008
1,443
710
But if you just want to go in game, run around, see the changes you made...nothing is wrong with fast compile. Don't need good shadows or leafs to get the feel of an area (aka, how jumps are for scout/soly, etc...)

That's what fast is for, not wasting time on leafs and shadows when it's not needed.

Or for making sure you have no leaks before you wait 10 minutes for compile and the game to start up.
 

Huckle

L3: Member
May 31, 2010
149
101
But if you just want to go in game, run around, see the changes you made...nothing is wrong with fast compile. Don't need good shadows or leafs to get the feel of an area (aka, how jumps are for scout/soly, etc...)

That's what fast is for, not wasting time on leafs and shadows when it's not needed.

Or for making sure you have no leaks before you wait 10 minutes for compile and the game to start up.

No. That's what cordon bounds are for. :)

Like Nerdboy, I'm in the "never use fast compiles" camp. I can't really think of a single case where I'd prefer it over just going straight for cordon bounds around the exact thing I want to look at. You will be able to spawn even if you don't have any spawns within the bounds.

Also a tip: doing normal bsb, no vis, no rad and "don't launch" will generally let you find leaks on normal compile in less than 10 seconds and get an accurate pointfile.