qvis3.exe - how long is too long?

[[BTF] Reflex]

Working on a map 

  Map ran fine with fast vis when I was tweaking the lighting.
Somewhere in the final structural tweaks vis started giving me "vis data overflow"
Searching on the error someone said make sure you are not running fast vis.

  So I am running it with full vis now that I'm happy with everything.
There is no error,  but I'm not sure if it's actually doing anything.  Processor use is at 100%,
and page file has remained steady.  Fast vis bumped the page file gradually.

It's been at it for 21 hours,  I'm ready to give up and rework the map a bit to try and fix
the error I get in -fast vis,  figuring that will let full vis go better???

Unless someone thinks this is normal
 But I dunno how long my wife will accept the computer running

[peewee_RotA]

I suggest switching to the updated timvis3 application instead.
http://dl.fileplanet.com/dl/dl.asp?quark/buildtools/quake2/buildq2-39.zip

I can't go into details because I just don't know the specifics, but I've seen much less lighting issues when switching to it.


As for a 20+ hour compile time, that is not abnormal. I've had maps that have taken 30 hours. I complained about it on a thread here once when compiling a map for quakechi. If you include a lot of strange angles and advance polys then it drives up the lighting time significantly. If you think aobut it, it would be very hard to cut into sectors a 10 sided cylinder sitting inside of a 8 sided pyramid  that has a 6 sided pyramid inverted and placed on top. I used that prefab and copied it quite a few times for a jungle map of mine. It took more than a day to compile with lighting! In fact it was so bad that qoole99 would crap out after that amount of time so I had to compile it using a commandline. I'm sure quark would have worked just fine. I've done a few 20+ hour compile time maps in quark.

[Whirlingdervish]

It's heavily dependent on map geometry and machine specs, but I've had some go for more than 24 hours, and it will always try to use 100% of the available cpu.

Even a relatively small map can take a long time depending on how intricate it is. (wdrail02.bsp took somewhere in the 20 hours just to do vis and its pretty much one big room with too much terrain for q2 to handle)

Say you have a basic box shaped room that took X seconds to make it through vis. If you add a simple rectangular prism column that touches the ceiling and the floor, you could easily triple your vis time, because during the qbsp stage it cuts your map into many more triangles that vis has to deal with.



little architectural details will make the time go up in an exponential fashion, unless you tell qbsp not to bother with them.

you can do this by taking stuff like columns (that dont rly block visibility anyway) and light fixtures and such, and turning them into func_wall entities. This works for anything but exterior walls, since you'd get a leak to the void trying to do it on one of those. (since your architecture is now an entity its really not there till after the game loads the map)

You can see this in the attached image in the 3rd set. The column is still there in game, but the extra cutting up of the map doesn't take place and your vis goes just as fast as if it was not there.

To do this grab the brushes of the column, or w/e, in your editor and drag them in the tree view into a func_wall group/folder. when the map gets cut into triangles those vertexes are ignored so some of your larger simpler triangles dont get cut into more than they need to.

essentially less total triangles after qbsp.exe = faster qvis.

you can check this using gl_showtris 1 with certain clients and renderers. It will show the actual triangles in-game while you run through the map.

if you find an area that is just horribly complicated, or one thats fairly complicated but can be seen (line of sight + a little bit around corners) from many areas of the map, consider simplifying that architecture or making some of it in func_walls.

using the detail flag on certain non essential brush architecture can be helpful as well.

[ReCycled]

If I remember, back in my map-making days, I always had unpredictable results when using the fastest settings of VIS. So I went somewhere in the middle "speed", with nary a problem. As far as compiling time, I once tried to make a "tree" with a trunk, branches etc. I just made one on a simple meadow like map to see how it would turn out. My intent was to establish some sort of forest. Well that sucker ran for hours before it compiled, because of that one, lousy tree. I guess the lighting program was having fits trying to calculate and render all the proper shadows and lighting for those branches. Needless to say a forest never happened.
 

[peewee_RotA]

That func_wall trick is actually really cool. I never thought of that. Although turning it into an ent, won't that cause potential glitch-ness if it is something that can be stood on? It's probably best to do that to unimportant details that can't or shouldn't be touched. If you do it to all of the columns in a room, and they are the main cover, then it could potentially not draw some of them or cause crap for client side predictions.

I know that usually is a problem for moving objects, and especially rotating objects. So I'm not saying don't do it. It's just something to be aware of and to test for.

[Whirlingdervish]

it definitely works well for stuff that will be behind clip brushes (wall decorations etc) and big complicated set pieces.

You are right tho, that if TS has the antiwallhack process running, it may cause a slight delay before you see something as you come around corners.

[PANTONE 7717C]

Only thing that could cause such times is a wide open area with a complicated set of brushes in it. That, combined with accidentally having mangled some brushes along the way can give crazy Vis-times. Sure you can wait it out, but what if you need to adjust some things, then you can start the process all over.

Definitely turn more brushes into detail brushes. That won't give you higher performance or lower r_speeds but then those brushes will simply be ignored by Vis and made part of the portal they are in.  One wide open area will be regarded as one giant portal, so almost everything inside that area that doesn't block Vis should be made detail.
Think of a structure like "Stone Henge", all those huge boulders should be set as detail, even if they appear to block the player's line-of-sight. That's because the engine will see right through it all even if the player can't. (LOL, when I visited Stone Henge that was the first thing I was thinking ... I know.)
(Real Vis-blockers are bending corridors, walls that seperate two areas from top to bottom, and other structural things that do the same.)

If the map design allows for it, try to use skybrushes on top of high structures to really separate areas. If the player can not look over a high single wall anway, then extent that wall with skybrushes so it touches the top sky layer:

________________________ <-top skylayer
              <-gap
(area1) | <-wall  (area1)


________________________ <-top skylayer
           |<-skybrush
(area1) | <-wall  (area2)


Could you show or describe the style of the map?

[[BTF] Reflex]

Hmmm,  wondered what that was for.


If something is func_wall'ed would it leave a shadow when lighting ran?

This would help,  little things like the glass panel brackets could be skipped.
but the columns they are connected to would need to leave a shadow.

This is also a one room map,  with too much detail/geometry.

--------

Just read Panj's post

I could post what I'm trying to run now, heres the non-lit .bsp

I really need to take another look at how I map, Too much detail



90% of this one could do with being made detail,  but do I quit running the one I am now with 24 hours invested in it?  lol

[Whirlingdervish]

I think there are a couple reasons that map is taking so long. It's not overly complex, but the way some of it is built can cause way more work than needs to be done.

1: transparent water = dangerous when it comes to vis.
opaque water blocks visibility, to some degree, transparent doesn't at all.
On a small pool of water its a negligible effect. on a big one that spans the floor of most of the map, it can have a huge effect.

2: lots of cool broken glass, that's also transparent, but mostly problem causing because it's made of complex shapes.
make the broken glass on the floors into a func_wall since it wont cast much of a shadow anyway, and it will save you a lot of time because it will keep your floor from getting cut up in crazy ways to accomodate the vertexes of the glass.
(when qbsp cuts up your map into tris, every vertex is taken into account and any brush thats directly touching the plane of another brush will have its vertexes taken into account when the other brush is cut up)

3: The water on the floor looks like you may have overlayed a big rectangular water brush over the existing structure, so it's causing some serious extra triangles, everywhere that the water level breaks up the shapes it intersects.

say this is one of the jump pad trims:

     ________________
__/_________________\___
  /                              \

because the water is bisecting it, it's making way more triangles than it should be cut into for such a simple detail.
qbsp will pretty much cut the side face of the little ring right at the level of the water and make extra vertexes there.
from here it will cut each side of the thingy into at least 4 triangles, instead of the 2 it had before.
 
this will make a huge number of visible triangles for qvis to do its visibility math, and as such you'll see exponentially incresing runtimes.

making that floor water opaque won't take much from the looks of the map, but it will make it so all the extra underwater tris are ignored by most of the map during vis, and are really only taken into account when its figuring out the underwater part. since it's a big arena, pretty much everything is visible from everywhere and the more triangles you have showing the longer it takes to figure out what you can see from every part of that big open complicated area.

the spikes on the edge of the perimeter wall can be made into func walls too, because depending on the angle of your lighting, they won't cast much of a shadow that players will see. (if you have a Sun for lighting and its coming in at a steep angle like its sunup or sundown, it would matter more, but if you just light the map by setting a light value on your sky brushes it won't show if they don't cast a substantial shadow.
 

[[BTF] Reflex]

Thanks Derv,

   I'm giving this until tomorrow morning   If not I'll rework the map. Skip the transparent water (good idea), and turn as much as I can into detail.
The spikes on top leave a shadow,  minimal but it's a kewl effect.  Only see it if you get up on the ledge they are attached to.

   Tons of great info guys,  will make more maps in the future alot less of a headache  (although a little headache is part of the fun )

   

[peewee_RotA]

Looks nice. The broken glass looks awesome, but that has got to be like 1000 poly in and of itself. Holy crap!

I got rspeeds of like 4400 in some corners

Dervish touched on a ton of important stuff, start with his suggestions.

Also, one huge fix you could do is extend all of the floors near your outer walls to touch. If you remove the space between outer brushes, even if they are supposed to be outside of the map,  you reduce the chance of leaks. The water itself sticks outside of the regular map geometry. That forced you to create that extra box around the outside. Shrink the water brushes to fit inside the map and remove the outer box so that the outside of the actual map is not being compiled.

[[BTF] Reflex]

Scrapped it now,

did some fixes,  fast vis ran in 2 seconds with no error.  having a better feeling about full vis this time.
Map ran in just a few minutes vs the 10-20 with fast vis from last time.  AWESOME!!

Panj was right too,     Needs some more tweaking I don't want to wait to work with in the future


----------

Peewee,  water was one fix,  but still leaked (probably not as much) to the 'outside' anyway.   

[Whirlingdervish]

some other things to take into account to make vis go quicker:

* use textures to create details instead of extra architecture. if you can give the impression of something with crafty texturing that you would have otherwise been forced to make out of brushes, you'll save lots of time and the final map will work better in q2 network/multiplayer games.

* build almost everything locked to the grid in your editor, and set the grid size to 8 or 16 or 32 etc. (exponent values of 2)

* I've found that if you look at the grid in editor, and build the whole map in the same quadrant of it, you get much less complicated cuts in the final triangles. Any brush crossing the line will probably get cut there, even if it wasn't needed.
(if you were looking at it like a graph, the positive section, upper right from the origin, seems to be the best)

* if you use a terrain editor to make some cool looking ground or rocks, make sure it has the skip/hint brush settings on, so it will force qbsp to cut your terrain to the grid exactly the way you see it in the editor, instead of wherever it feels like it based on the math it's doing at the time.



* as in the map above, don't overuse premade terrain, and if you're going to use it make sure the triangle size is pretty large or you'll get a day long vis at least.

wdrail02 actually has very shitty r_speeds (super high number of visible world polygons from anywhere you look) so it can cause lesser rigs to stutter or get really low FPS while running it, due to me putting way too much shit into one medium sized area with pretty much nothing that blocks out visibility from one point to any other.

* keep it simple stupid. ( the ol' KISS rule covers all bases   )

[R1CH]

Don't use func_wall, use detail brushes for minor architecture. Mark anything that shouldn't touch the vis process as detail and you'll be fine. If vis takes longer than an hour on a modern CPU, your map is broken.

For comparison:
http://r-1.ch/assassin-nodetail.png
http://r-1.ch/assassin-detail.png

nodetail wouldn't even compile.

[Whirlingdervish]

R1CH is correct there.

the func_wall should be used sparingly as it will quickly load up the number of entity polygons that are drawn by the game if you were to do it on too much of the actual architecture on a medium/large map.

It's really meant for making walls that you can switch on and off (entrances to secrets, surprise monsters coming out from behind the wall etc..)

the detail flag will do the same in terms of cutting vis time without the negative side effect of forcing your renderer to work way too hard in-game on the entity drawing pass.