Vvis very slow, vrad crashes

YM_Industries

Banned
Jan 5, 2012
14
0
Hi,
When I compile my map with -fast on vvis it crashes the game.
When I compile my map with anything else vvis takes 2 hours to run and vrad crashes.
I only have 3000 numportals, so I don't think it is that.
Is it possible that it is because a lot of my visleafs can see each other? If so, how can I stop this, my map is very open.
Code:
1337 portalclusters
3186 numportals
BasePortalVis:       0...1...2...3...4...5...6...7...8...9...10 (0)
PortalFlow:          0...1...2...3...4...5...6...7...8...9...10 (5016)
Code:
16440 faces
14323488 square feet [2062582272.00 square inches]
0 Displacements
0 Square Feet [0.00 Square Inches]
16440 patches before subdivision
1003722 patches after subdivision
0 direct lights
BuildFacelights:     0...1...2...3...4...5...6...7...8...9...10 (5)
BuildVisLeafs:       0...1...2...3...4...5...6...7...8.


Full compile log:
Code:
C:\Users\Yoshie\Desktop>"c:\program files (x86)\steam\steamapps\yjoosshhiuea101\sourcesdk\bin\orangebox\bin\vbsp.exe" -game "C:\program files (x86)\steam\steamapps\yjoosshhiuea101\team fortress 2\tf" "c:\program files (x86)\steam\steamapps\yjoosshhiuea101\sourcesdk_content\tf\mapsrc\pl_minecraft"
Valve Software - vbsp.exe (Oct 25 2011)
4 threads
materialPath: C:\program files (x86)\steam\steamapps\yjoosshhiuea101\team fortress 2\tf\materials
Loading c:\program files (x86)\steam\steamapps\yjoosshhiuea101\sourcesdk_content\tf\mapsrc\pl_minecraft.vmf
material "tools/toolsskybox" not found.
Material not found!: TOOLS/TOOLSSKYBOX
ConVarRef mat_reduceparticles doesn't point to an existing ConVar
material "tools/toolsblack" not found.
Material not found!: TOOLS/TOOLSBLACK
Can't find surfaceprop rock for material MINECRAFT_TEXTURES/MCNETHERRACK, using default
Can't find surfaceprop Glass for material MINECRAFT_TEXTURES/MCGLASS, using default
Can't find surfaceprop wood for material MINECRAFT_TEXTURES/MCLIBRARY, using default
Can't find surfaceprop wood for material MINECRAFT_TEXTURES/MCWOOD, using default
Can't find surfaceprop grass for material MINECRAFT_TEXTURES/MCGRASS, using default
Can't find surfaceprop dirt for material MINECRAFT_TEXTURES/MCDIRT, using default
material "tools/toolsinvisible" not found.
Material not found!: TOOLS/TOOLSINVISIBLE
Can't find surfaceprop sand for material MINECRAFT_TEXTURES/MCSAND, using default
Can't find surfaceprop carpet for material MINECRAFT_TEXTURES/MCWOOL, using default
material "tools/toolstrigger" not found.
Material not found!: TOOLS/TOOLSTRIGGER
Can't find surfaceprop mudslipperyslime for material MINECRAFT_TEXTURES/MCLAVAMOVING, using default
Can't find surfaceprop wood for material MINECRAFT_TEXTURES/MCWOODENDOOR, using default
Can't find surfaceprop wood for material MINECRAFT_TEXTURES/MCTREETRUNK, using default
material "overlays/no_entry" not found.
Material not found!: OVERLAYS/NO_ENTRY
material "tools/toolsnodraw" not found.
Material not found!: TOOLS/TOOLSNODRAW
Can't find surfaceprop water for material MINECRAFT_TEXTURES/MCWATER, using default
Can't find surfaceprop glass for material MINECRAFT_TEXTURES/MCGLOWSTONE, using default
Can't find surfaceprop gravel for material MINECRAFT_TEXTURES/MCGRAVEL, using default
Can't find surfaceprop wood for material MINECRAFT_TEXTURES/MCTRACK, using default
Can't find surfaceprop wood for material MINECRAFT_TEXTURES/MCTRACKTURN, using default
Can't find surfaceprop mudslipperyslime for material MINECRAFT_TEXTURES/MCLAVA, using default
fixing up env_cubemap materials on brush sides...
Material minecraft_textures/MClava is depending on itself through materialvar $bottommaterial! Ignoring...
Material MINECRAFT_TEXTURES/MCWATER is depending on itself through materialvar $bottommaterial! Ignoring...
Material MINECRAFT_TEXTURES/MCLAVA is depending on itself through materialvar $bottommaterial! Ignoring...
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 (0)
Chop Details...done (0)
Find Visible Detail Sides...
Merged 738 detail faces...done (0)
Merging details...done (0)
FixTjuncs...
PruneNodes...
WriteBSP...
done (0)
writing c:\program files (x86)\steam\steamapps\yjoosshhiuea101\sourcesdk_content\tf\mapsrc\pl_minecraft.prt...Building visibility clusters...
done (0)
Can't find surfaceprop mudslipperyslime for material maps/pl_minecraft/minecraft_textures/mclavamoving_depth_656, using default
Can't find surfaceprop mudslipperyslime for material maps/pl_minecraft/minecraft_textures/mclavamoving_depth_512, using default
error: material TOOLS/TOOLSINVISIBLE doesn't have a $bottommaterial
error: material TOOLS/TOOLSINVISIBLE doesn't have a $bottommaterial
error: material TOOLS/TOOLSINVISIBLE doesn't have a $bottommaterial
error: material TOOLS/TOOLSINVISIBLE doesn't have a $bottommaterial
error: material TOOLS/TOOLSINVISIBLE doesn't have a $bottommaterial
error: material TOOLS/TOOLSINVISIBLE doesn't have a $bottommaterial
error: material TOOLS/TOOLSINVISIBLE doesn't have a $bottommaterial
error: material TOOLS/TOOLSINVISIBLE doesn't have a $bottommaterial
error: material TOOLS/TOOLSINVISIBLE doesn't have a $bottommaterial
error: material TOOLS/TOOLSINVISIBLE doesn't have a $bottommaterial
error: material TOOLS/TOOLSINVISIBLE doesn't have a $bottommaterial
error: material TOOLS/TOOLSINVISIBLE doesn't have a $bottommaterial
Can't find surfaceprop water for material maps/pl_minecraft/minecraft_textures/mcwater_depth_491, using default
Can't find surfaceprop water for material maps/pl_minecraft/minecraft_textures/mcwater_depth_0, using default
material "skybox/sky_dustbowl_01rt" not found.
Can't load skybox file skybox/sky_dustbowl_01 to build the default cubemap!
Can't load skybox file skybox/sky_dustbowl_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...

C:\Users\Yoshie\Desktop>"c:\program files (x86)\steam\steamapps\yjoosshhiuea101\sourcesdk\bin\orangebox\bin\vvis.exe" -game "C:\program files (x86)\steam\steamapps\yjoosshhiuea101\team fortress 2\tf" "c:\program files (x86)\steam\steamapps\yjoosshhiuea101\sourcesdk_content\tf\mapsrc\pl_minecraft"
Valve Software - vvis.exe (Oct 25 2011)
4 threads
reading c:\program files (x86)\steam\steamapps\yjoosshhiuea101\sourcesdk_content\tf\mapsrc\pl_minecraft.bsp
reading c:\program files (x86)\steam\steamapps\yjoosshhiuea101\sourcesdk_content\tf\mapsrc\pl_minecraft.prt
1337 portalclusters
3186 numportals
BasePortalVis:       0...1...2...3...4...5...6...7...8...9...10 (0)
PortalFlow:          0...1...2...3...4...5...6...7...8...9...10 (5016)
Optimized: 2344 visible clusters (0.00%)
Total clusters visible: 591301
Average clusters visible: 442
Building PAS...
Average clusters audible: 1221
visdatasize:444041  compressed from 449232
writing c:\program files (x86)\steam\steamapps\yjoosshhiuea101\sourcesdk_content\tf\mapsrc\pl_minecraft.bsp
1 hour, 23 minutes, 37 seconds elapsed

C:\Users\Yoshie\Desktop>"c:\program files (x86)\steam\steamapps\yjoosshhiuea101\sourcesdk\bin\orangebox\bin\vrad.exe" -both -final -game "C:\program files (x86)\steam\steamapps\yjoosshhiuea101\team fortress 2\tf" "c:\program files (x86)\steam\steamapps\yjoosshhiuea101\sourcesdk_content\tf\mapsrc\pl_minecraft"
Valve Software - vrad.exe SSE (Oct 25 2011)

      Valve Radiosity Simulator
4 threads
Could not find lights.rad in lights.rad.
Trying VRAD BIN directory instead...
Warning: Couldn't open texlight file c:\program files (x86)\steam\steamapps\yjoosshhiuea101\sourcesdk\bin\orangebox\bin\lights.rad.
Loading c:\program files (x86)\steam\steamapps\yjoosshhiuea101\sourcesdk_content\tf\mapsrc\pl_minecraft.bsp
Setting up ray-trace acceleration structure... Done (0.29 seconds)
16440 faces
14323488 square feet [2062582272.00 square inches]
0 Displacements
0 Square Feet [0.00 Square Inches]
16440 patches before subdivision
1003722 patches after subdivision
0 direct lights
BuildFacelights:     0...1...2...3...4...5...6...7...8...9...10 (5)
BuildVisLeafs:       0...1...2...3...4...5...6...7...8.
 

grazr

Old Man Mutant Ninja Turtle
aa
Mar 4, 2008
5,441
3,814
You should have taken my advice from the previous thread. Try compiling your map without water because your custom water material is throwing out all sorts of smoke screen errors.

"vrad wasn't included in this compile"

It sounds like you had a leak and as a result your compile wasn't completed. That or you quit Hammer before the compile could complete. It sounds like you have a leak. This is the number 1 issue with all maps ;iwh vruio;qvtbrawehyfi that don't compile.

Load your pointfile, find the hole, seal it, compile again.

If this is not the case, as judging by your quote that you do not allow Hammer to finish A) BE PATIENT. B) use func_detail to cut down geometry. the more detail geometry you have the more complex visleaf formations and the longer a compile will take (vvis.exe to be specific). func_detail will cause vvis to ignore the selected geometry and speed up compile times by allowing the compiler to create simpler visleaf formations.

READ AS MUCH AS YOU CAN ABOUT SOURCE BEFORE AMWEGFWGWEG MAKING MAPS FOR IT. YOU WILL NOT BE ASKING THESE COMMON/BASIC QUESTIONS AFWGMGMSEVWKGSE AND SHOULD BE ABLE TO TROUBLESHOOT THIS STUFF ON YOUR OWN.
 
Last edited:

YM_Industries

Banned
Jan 5, 2012
14
0
You should have taken my advice from the previous thread. Try compiling your map without water because your custom water material is throwing out all sorts of smoke screen errors.
Sorry, I forgot about the water, I had successful compiles after I added it though so I don't think it is the main problem.
"vrad wasn't included in this compile"

It sounds like you had a leak and as a result your compile wasn't completed. That or you quit Hammer before the compile could complete. It sounds like you have a leak. This is the number 1 issue with all maps ;iwh vruio;qvtbrawehyfi that don't compile.

Load your pointfile, find the hole, seal it, compile again.
There are no leaks, leaks look a lot different to this anyway. Leaks fail much earlier than vrad and don't slow down vvis, they cause errors.
If this is not the case, as judging by your quote that you do not allow Hammer to finish A) BE PATIENT.
Sorry, I should have explained this, the Hammer compile process freezes immediately and eventually crashes silently, without giving me the opportunity to copy the log. So that I can capture the log (and see it in real-time without it freezing) I use the following batch script for my compiles instead:
Code:
"c:\program files (x86)\steam\steamapps\yjoosshhiuea101\sourcesdk\bin\orangebox\bin\vbsp.exe" -game "C:\program files (x86)\steam\steamapps\yjoosshhiuea101\team fortress 2\tf" "c:\program files (x86)\steam\steamapps\yjoosshhiuea101\sourcesdk_content\tf\mapsrc\pl_minecraft"
"c:\program files (x86)\steam\steamapps\yjoosshhiuea101\sourcesdk\bin\orangebox\bin\vvis.exe" -game "C:\program files (x86)\steam\steamapps\yjoosshhiuea101\team fortress 2\tf" "c:\program files (x86)\steam\steamapps\yjoosshhiuea101\sourcesdk_content\tf\mapsrc\pl_minecraft"
"c:\program files (x86)\steam\steamapps\yjoosshhiuea101\sourcesdk\bin\orangebox\bin\vrad.exe" -both -final -game "C:\program files (x86)\steam\steamapps\yjoosshhiuea101\team fortress 2\tf" "c:\program files (x86)\steam\steamapps\yjoosshhiuea101\sourcesdk_content\tf\mapsrc\pl_minecraft"
copy "c:\program files (x86)\steam\steamapps\yjoosshhiuea101\sourcesdk_content\tf\mapsrc\pl_minecraft".bsp "c:\program files (x86)\steam\steamapps\yjoosshhiuea101\team fortress 2\tf\maps\pl_minecraft.bsp"
Either way I still get an unsuccessful compile, but this at least lets me see the problem better. Where you see the compile stop, I get a message saying "vrad.exe has stopped working, would you like to Debug or Close."
I am a programmer and know my different error messages, this isn't just not responding, it's an actual failure.
B) use func_detail to cut down geometry. the more detail geometry you have the more complex visleaf formations and the longer a compile will take (vvis.exe to be specific). func_detail will cause vvis to ignore the selected geometry and speed up compile times by allowing the compiler to create simpler visleaf formations.
Yeah, but as I said, I only have 3000 numportals, well within acceptable boundaries (HL reference much?)

READ AS MUCH AS YOU CAN ABOUT SOURCE BEFORE AMWEGFWGWEG MAKING MAPS FOR IT. YOU WILL NOT BE ASKING THESE COMMON/BASIC QUESTIONS AFWGMGMSEVWKGSE AND SHOULD BE ABLE TO TROUBLESHOOT THIS STUFF ON YOUR OWN.
I understand the source engine very well, well enough to know that my vvis shouldn't be taking this long with so few numportals and that vrad is baking the lighting and doesn't have anything to do with visleafs.

You immediately assume that I'm an idiot, going on about visleafs and leaks, but if you had read the question properly you would see that:
A) From the compile logs I have no leaks
B) From the excerpt I pointed out in the first place there aren't too many visleafs in my map

Also, while I may not have had an account on this site for long, I have been developing maps for Portal 1 & 2 for a while. I have helped many people with issues over at the ThinkingWithPortals forums.

Finally, I check all these logs on interlopers before posting and it would let me know if it was something obvious.

Thankyou for the help though, I'll go fix those water textures (which aren't mine anyway, I got them in a pack)
 

grazr

Old Man Mutant Ninja Turtle
aa
Mar 4, 2008
5,441
3,814
What you need to understand is that i don't hold anything against you personally, simply that we get queries like this all the time; and with each new contest comes a fresh batch of noobs with the same questions about the same novice mistakes because they bit off more than they could chew. Compile crashes are after all user error 99% of the time.

With enough knowledge of the source engine this kind of thing can be troubleshooted with a little trial and error on your part, if you're as experienced as you say you are then you'll understand the process of troubleshooting: narrowing down the problem by compiling your level multiple times using different variations by using the cordon tool and/or the visgroup function.

You don't need to be a programmer to understand what went wrong or how to read the log. Being a programmer has nothing to do with it, in fact, as long as you have a base knowledge of how Source physically works that is more than sufficient to translate any error.

There are no leaks, leaks look a lot different to this anyway. Leaks fail much earlier than vrad and don't slow down vvis, they cause errors.

vrad happens after vvis and frequently the result of a leak is for vvis to fail and vrad not to run at all. Thus vrad not running is a sign and common symptom that there was potentially a leak.

There are many ways for leaks to be recorded in a log, usually it's a set of undesignated visleafs exposed to the void and then skipped by Hammer when it recognises what is happening, but there are more subtle causes that don't show conventionally in a log, such as doing something you're not supposed to as opposed to just having a hole.

Sorry, I should have explained this, the Hammer compile process freezes immediately and eventually crashes silently, without giving me the opportunity to copy the log.

Logs are created automatically, even if the compile fails to complete. They are saved in a text file you can access in either in the vmf or bsp directory. I forget. It's been a while since i've had to access one. Though i should warn you that after multiple failed compiles the fact that all logs of a single map version are copied to the same file caused them to be a mess to read at times. Finding the start of one log and the end of an interrupted one amongst many other broken logs can be troublesome. Compiling with a new map name to create a fresh log often saves you some hassle.

Yeah, but as I said, I only have 3000 numportals, well within acceptable boundaries (HL reference much?)

Numbers aren't important, if you can optimise your map more then i advise that you do so. Just because you have a limit doesn't mean you should allow yourself to hit it, especially if it can be easily avoided.

What is frustrating for me or anyone else trying to help you is that we don't have your map and this is 99% chance a user error on your part that can only be narrowed down by you. You came here to use our time to give you an answer rather than doing a little leg work yourself. We can only suggest what went wrong with the limited information you give us. Unless you give us the vmf you'll need to spend some time turning stuff on and off in order to try and get a successful compile and locate the source of your trouble. Or at least show us some pictures of your map so that we might spot the issue visually. Too many times have people said "oh no, it's not this, i've covered that" only for it to turn out to be just that is beyond number. People give themselves too much credit and it makes this process difficult for everyone.

So is all i can say right now is clean up your compile log of unnecassery errors to make your job easier and try multiple compiles while turning off displacements/water/nodraw etc and eventually something will happen.

P.S compile times are relative to system specs. Saying a compile shouldn't take 2 hours doesn't mean anything to us. For some people that is unfortunately normal.

Show us a pic of your portalfile open in hammer because it sounds to me that you're just not giving the compile enough time to finish, it's perfectly natural for vvis.exe to seize up for 5 or 10 minutes around the 8-10 period when complicated geometry is involved. It sounds like your experience of being a programmer is getting in the way of letting vvis doing its job and you're smashing your desk with your fists screaming "i should understand why this is happening, i am better than this, i am a programmer".

Here is some side information that might be of use in the mean time. Use func_visclusters to consolidate large portions of visleafs into a conglomerate, but be aware, this causes the conglomeratation of visleafs to act as a single giant visleaf, so it can be bad if used over zealously within the play boundaries.

Secondly massive areaportals are bad.

P.P.S

I did not assume you were an idiot, i just assumed that you were inexperienced and lazy.
 
Last edited:

YM_Industries

Banned
Jan 5, 2012
14
0
What you need to understand is that i don't hold anything against you personally, simply that we get queries like this all the time; and with each new contest comes a fresh batch of noobs with the same questions about the same novice mistakes because they bit off more than they could chew. Compile crashes are after all user error 99% of the time.

With enough knowledge of the source engine this kind of thing can be troubleshooted with a little trial and error on your part, if you're as experienced as you say you are then you'll understand the process of troubleshooting: narrowing down the problem by compiling your level multiple times using different variations by using the cordon tool and/or the visgroup function.

You don't need to be a programmer to understand what went wrong or how to read the log. Being a programmer has nothing to do with it, in fact, as long as you have a base knowledge of how Source physically works that is more than sufficient to translate any error.



vrad happens after vvis and frequently the result of a leak is for vvis to fail and vrad not to run at all. Thus vrad not running is a sign and common symptom that there was potentially a leak.

There are many ways for leaks to be recorded in a log, usually it's a set of undesignated visleafs exposed to the void and then skipped by Hammer when it recognises what is happening, but there are more subtle causes that don't show conventionally in a log, such as doing something you're not supposed to as opposed to just having a hole.



Logs are created automatically, even if the compile fails to complete. They are saved in a text file you can access in either in the vmf or bsp directory. I forget. It's been a while since i've had to access one. Though i should warn you that after multiple failed compiles the fact that all logs of a single map version are copied to the same file caused them to be a mess to read at times. Finding the start of one log and the end of an interrupted one amongst many other broken logs can be troublesome. Compiling with a new map name to create a fresh log often saves you some hassle.



Numbers aren't important, if you can optimise your map more then i advise that you do so. Just because you have a limit doesn't mean you should allow yourself to hit it, especially if it can be easily avoided.

What is frustrating for me or anyone else trying to help you is that we don't have your map and this is 99% chance a user error on your part that can only be narrowed down by you. You came here to use our time to give you an answer rather than doing a little leg work yourself. We can only suggest what went wrong with the limited information you give us. Unless you give us the vmf you'll need to spend some time turning stuff on and off in order to try and get a successful compile and locate the source of your trouble. Or at least show us some pictures of your map so that we might spot the issue visually. Too many times have people said "oh no, it's not this, i've covered that" only for it to turn out to be just that is beyond number. People give themselves too much credit and it makes this process difficult for everyone.

So is all i can say right now is clean up your compile log of unnecassery errors to make your job easier and try multiple compiles while turning off displacements/water/nodraw etc and eventually something will happen.

P.S compile times are relative to system specs. Saying a compile shouldn't take 2 hours doesn't mean anything to us. For some people that is unfortunately normal.

Show us a pic of your portalfile open in hammer because it sounds to me that you're just not giving the compile enough time to finish, it's perfectly natural for vvis.exe to seize up for 5 or 10 minutes around the 8-10 period when complicated geometry is involved. It sounds like your experience of being a programmer is getting in the way of letting vvis doing its job and you're smashing your desk with your fists screaming "i should understand why this is happening, i am better than this, i am a programmer".

Here is some side information that might be of use in the mean time. Use func_visclusters to consolidate large portions of visleafs into a conglomerate, but be aware, this causes the conglomeratation of visleafs to act as a single giant visleaf, so it can be bad if used over zealously within the play boundaries.

Secondly massive areaportals are bad.

P.P.S

I did not assume you were an idiot, i just assumed that you were inexperienced and lazy.

I understand that you get questions like this all the time, I just don't appreciate it being an automatic assumption. For what it's worth, this is a long term project that has suddenly failed, not at all related to the contest.
As for being a programmer helping/not helping with the logs, I wasn't talking about the logs. I was talking about how I know the difference between "This program has stopped responding" and "This program has stopped working" because if it was a not responding message I would have just waited, as it is it wasn't going to resolve itself. It terminated the process automatically.
VVIS is completing successfully, no errors, all files generated, VRAD is just crashing, full stop. Not being slow, it actually dies. This is why I said I was a programmer, I wanted to let you know that I can tell the difference.
Down to the practical side of things, large visleafs being bad is EXACTLY what I was afraid of. I have func_detailed a lot of stuff that SHOULD be func_detailed (because they are details, like stairs and stuff) but they also formed the walls. (I started the map a while ago and carved a lot of stuff (I know! I'm sorry!)) I think I'll have to make almost everything a func_detail and then put some nodraw walls inbetween to divide the visleafs.
Thankyou for your help!
 

grazr

Old Man Mutant Ninja Turtle
aa
Mar 4, 2008
5,441
3,814
I said areaportals being big are bad, not visleafs. visleafs actually have a maximum size IIRC. I've never heard of a visleaf being too big.

Carving generates so many ambiguous compile problems i'm not surprised you're having issues.

I wouldn't recommend func_detailing geometry and then creating a twin brush of nodraw. It wont do anything other than increase file size and maybe cause some brush count limit issues.

I thought your problem was vvis related because you highlighted parts of the log out of context rather than just letting us look at the log and seeing for ourselves. Partly my fault for not paying attention but it was unnecassery of you to point stuff out for us, especially if you've come here for help.

There are some weird dynamics between cubemaps and vrad, sometimes vrad has crashed because i had too many cubemaps close to each other. Other than that, vrad crashing is something that's really rare, do you have a lot of lights/dynamic lights/coloured lights/tex lights?

Other than that, it seems that your rad file is incomplete/missing, at least interlopers throws that out.
 
Last edited:

YM_Industries

Banned
Jan 5, 2012
14
0
I said areaportals being big are bad, not visleafs. visleafs actually have a maximum size IIRC. I've never heard of a visleaf being too big.

Carving generates so many ambiguous compile problems i'm not surprised you're having issues.

I wouldn't recommend func_detailing geometry and then creating a twin brush of nodraw. It wont do anything other than increase file size and maybe cause some brush count limit issues.

I thought your problem was vvis related because you highlighted parts of the log out of context rather than just letting us look at the log and seeing for ourselves. Partly my fault for not paying attention but it was unnecassery of you to point stuff out for us, especially if you've come here for help.

There are some weird dynamics between cubemaps and vrad, sometimes vrad has crashed because i had too many cubemaps close to each other. Other than that, vrad crashing is something that's really rare, do you have a lot of lights/dynamic lights/coloured lights/tex lights?

Other than that, it seems that your rad file is incomplete/missing, at least interlopers throws that out.

I haven't yet added lights or cubemaps, I'm making the basics first. Also, my plan with func_detailing and nodraws was that the nodraws would be simple walls, while the func_details would be the complex bumpy walls I have at the moment. Because I made the bumpy walls func_detail without doing nodraw walls and I think this has caused massive areaportals.
As for the rad file, I spotted that, does TF2 have one that comes with it or should I just make a blank one? Not sure how I managed to lose mine, must have been very careless. Anyway, I was going to do that later because Interlopers says that it's a minor error.

Thanks for the help, we seem to be getting closer to the problem now that we can leave out noob mistakes.

EDIT: How big is too big in terms of portals?
 
Last edited:

grazr

Old Man Mutant Ninja Turtle
aa
Mar 4, 2008
5,441
3,814
Well try compiling in normal mode without any additional parameters, as opposed to advanced mode. See where that gets you. There is a default rad file, at least there should be, but your advanced mode is pointing to a custom file that either is missing, incomplete or corrupt.

Also areaportals are an entity, it's not something that is "caused". It's an entity you can use to optimise a map.

If you have bumpy walls you should be using displacements, and if that's the case, having a nodraw brush underneath/beneath/inside the displacement would not be a bad idea if the size warrants it.
 

IXIArblargIXI

L1: Registered
Jan 7, 2012
1
0
Hi,
I only have 3000 numportals, so I don't think it is that.
Is it possible that it is because a lot of my visleafs can see each other? If so, how can I stop this, my map is very open.
Code:
[B][SIZE="3"]1337 portalclusters
3186 numportals[/SIZE][/B]
BasePortalVis:       0...1...2...3...4...5...6...7...8...9...10 (0)
PortalFlow:          0...1...2...3...4...5...6...7...8...9...10 (5016)
I love you, you're a funny guy. ONLY 3000...
even 1000 is pushing it, you shouldn't exceed that much. Cutting down on compile time is easy with func_visclusters surrounding your entire open area, but visual (FPS) optimization will require func_details and wise use of optimization brushes (hint, skip, areaportals, etc)

If VVIS is taking longer than 5 minutes, you need to go back to geometry optimization. Keep that as your goal time, if you exceed it, go back and optimize.
 

YM_Industries

Banned
Jan 5, 2012
14
0
I love you, you're a funny guy. ONLY 3000...
even 1000 is pushing it, you shouldn't exceed that much. Cutting down on compile time is easy with func_visclusters surrounding your entire open area, but visual (FPS) optimization will require func_details and wise use of optimization brushes (hint, skip, areaportals, etc)

If VVIS is taking longer than 5 minutes, you need to go back to geometry optimization. Keep that as your goal time, if you exceed it, go back and optimize.

Thanks, I wasn't really sure how many was too many until I say a post on Interlopers saying something about anything under 5000 should be fine, just went by that. I'll work on getting that down a bit.