vvis getting stuck on compile?

N

Neo Mara

Guest
I went to compile my map and the compiler would get stuck on PortalFlow. I tried reversing the changes I had made and I got nothing. I reinstalled the SDK and it still happed. When the compiler gets stuck vvis.exe is using almost 100% of the processor and if I end the process it seems to continue the compile with no side effects. This is also happening to a buddy of mine. Does anyone know how to fix this?
 
I have the same problem. I could run vvis fine before the update, now...

well...

I left hammer on over night, and when i came home from my doctors app. the next day it was still going.

13 hours later. The map in question is 3.5 MB.

wtf : /
 
Just before the portal flow message, how many numportals are there?

It should show something like:

Code:
 372 portalclusters
1335 numportals
BasePortalVis:       0...1...2...3...4...5...6...7...8...9...10 (2)
PortalFlow:          0...1...2...3...4...5...6...7...8...9...10 (220)

The higher the number, the longer it takes. I found out that last night when compiling was taking hours, maybe even days if I had left it, it turns out that all my detail brushes had gone and my numportals was around 3006, just reapplying them to everything I wanted lowered them to 1335 and a 4min compile.

See if Hammer has removed your detail brushes, but it is quite common for it to take a while.
 
Neo Mara said:
I went to compile my map and the compiler would get stuck on PortalFlow. I tried reversing the changes I had made and I got nothing. I reinstalled the SDK and it still happed. When the compiler gets stuck vvis.exe is using almost 100% of the processor and if I end the process it seems to continue the compile with no side effects. This is also happening to a buddy of mine. Does anyone know how to fix this?
It wont have got stuck, just takes a long time. Creative use of hint brushes should really speed vis up.
 
yeah the same exact thing is happening to me. everything worked fine until i made a skybox around my level...then it stuck right where yours does.
 
Tied pretty much everything i could to func_detail brushes just now and reduced my numportals from 14474 to 6478...hopefully that speeds it up a bit

EDIT: Now it says a load of my prop_statics are 'outside the map' on compile...they're not attached to func_details though which i thought would be the problem....anyone else come across this?
 
Sorry bout double post, i just realised it was because i made a big block for wind and didnt tie it to an entity :p
 
MrMan said:
Sorry bout double post, i just realised it was because i made a big block for wind and didnt tie it to an entity :p
You should make smaller blocks for wind, since then you can set each one up to have more or less wind speed. Good for corners around buildings or being blocked by things or just those wind tunnel effects between larger objects. Also easier to deal with.
 
Ok dokey :)

Having a wierd problem...if i compile my map with my Hint/Skip visgroup enabled, my 'numareaportals' are around 10,500, though if i turn them off the numareaportals decrease to 4500....does this mean that ive set up my hint and skip brushes incorrectly..or that its best for hammer to build its own?
 
Here is a great but old page on using hint brushes: http://fps.brainerd.net/hintbrushes.htm

Its actually an old quake tutorial, but the basic idea is the same.

The only difference is, Valve/Hammer decided to give us glview to browse through our portals. Problem with that is...good luck getting glview to run. I haven't been able to get it to run since valve dicided to yet again make the directory structure even more confusing. Its not worth the hassle to do it right unfortunatly.

Best thing I could suggest is any complex brush you have, like arches, circles... make them all detail. But try not to comprimise the "structure" of the map, detail brush will cause leaks if they are on the boundry. So you will have to enclose the outsides in nodraw. Simply put, detail brush are basically ignored by the vis process.
 
Probably just should have edited my last post.

OK, to use glview create a easy to get to directory like g:\maps and copy your vmf to it.

Now go to the windows run, and type in cmd and navigate to the sourcesdk/bin folder.

You need to run a vbsp, for me it was vbsp.exe -glview g:\maps\mymap

That will compile your map to the map folder.

Then type in: glview.exe -portals g:\maps\mymap.gl

That will open up the map in glview and you will be able to see the wireframes. You will be able to see where the portals are and if your hint brushes are working.
 
The problem is, I went from about a 6 second compile time to getting "stuck." I changed nothing of importance, just deleted a prop and added some lights.

edit: 807 num portals
 
I have the same problem :( Compiling in 10 secs and then adding 5 brushes and now it takes 45 min! And I try to delete those brushes that I add, but still 45 minutes! Why? :s
 
i just run vis on fast instead of normal, goes from 14hrs+ to 18 mins.. dont know how much of a difference fast versus normal is though
 
hmm, I just turn the vis off, but the map is the same??? Why use vis for hours when it really does nothing?
 
Because it doesn't do nothing. What vis is doing is calculating which parts of your map can see which other parts. If you don't run vis, the engine has to draw all of your map all of the time(*), which is slow. It might look fine for a small map, but once you put in enough detail you'll see bad framerates.


* except for frustum culling - only drawing objects that are in your field of view - which is done even without vis info.
 
I see.. So I really need to use VIS after the beta testing is over :D

Cool ;)
 
I dont know what you boys are worried about, check this out!

writing c:\program files\valve\steam\steamapps\abc\half-life 2\hl2\maps\City13.bsp
179 hours, 43 minutes, 32 seconds elapsed

I really should learn how to use hint brushes. :(
 
yes im intrested in speeding the compiler up.... i have like 45+ prop_detail windows on a small dust map... and like the outher ppl its SLOW on vis portal thingy :bonce:
 
Back
Top