for parallel vis? 

probably. if you get to a point where you need some ridiculous vis testing, let me know. :P 

Those that frequents the Q3W boards have seen this before I guess. I'm not sure I've posted it here before, I was to have a beta out before the end of this month, but things rocked the schedule, so I don't think that will be possible.
http://zfight.com/misc/images/maps/m8/m8_8.jpg
http://zfight.com/misc/images/maps/m8/m8_9.jpg
http://zfight.com/misc/images/maps/m8/m8_10.jpg 

 

So I'm guessing that you've experimented and found that putting architecture outside quake's usual +/- 4096 bounds poses no problem as long as the player can't actually get there? I find that quite interesting as I'm not aware it's ever been done on a released map before.

Also, did you know aguire's vis has a -visdist # option? That might help cut down on those extremely long traces. You would get HOM past the set number, which a light fog could hide, though I guess it would hide the skybox too which would be a shame because it's a really nice one.

Regardless, the map looks crazy cool and I want to play it. 

@necros: I think the 700+ hours of vis run is not the problem, it is rather about your patience... The shot of your map look really amazing... So I would really like to play it one day ;) So what would be the problem to deliver the map in fastvis version only, as I did for "Fort Driant" ? If you don't want to wait "endlessly" for vis process, it mayight be a solution as well. Else, as suggested by inertia, parallel vis will be your friend here: you just need at least a quad core to really speed up the runtime... though... and you are not 100% sure to be freed from any HOM problem... Anyway: good luck :)

@Hipshot: nice shots, 3rd shot is indeed "badass", keep it up ! 

could some "floating 1px away from surroundings" tricks help?
what's that? o.0

anyway, i've walled off a large portion as well as removed a bunch of windows. it makes the map less open and kind of boring at times, but the changes seems to have made a huge difference so far (64h @ 28%). i just hit a string of difficult portal calculations though, so the next estimate update may be much larger...

i didn't specify, but the 700h estimate was only at 25%. it's reasonable to assume that that number would at the very least double before it hit 90%.

as for a fast vis, the problem is average 15000 wpoly + >25000 epoly in all the outdoor areas and with flickering lights, it means hundreds of lightmaps being uploaded every few frames which brings even modern machines to a crawl.
there's a lot of combat that takes place in outdoor areas too, so it sucks trying to deal with monsters when you're getting 10-20 fps with dips down to 2-5 fps whenever lightmaps change.

with fort driant, i don't really remember any really bad areas. i remember, i think it was ricky's sickbase which ran pretty bad with 12k wpoly average in the outdoor areas along the edges and that's about as slow as i think would be acceptable.

in anycase, i really don't want to can this map, so i'll keep closing off areas until it can vis with a reasonable amount of time, so you'll play it eventually, you just won't get as many cool viewpoints. :S 

So parallel vis will definitely help you to reduce vis process runtime, definitely and drastically...
Unless if you want to beat the CDA's "Worst Fullvis Runtime Ever" and get your name in the Guinees record book ;) 

The 1-unit trick involves moving detail geometry one unit away from adjacent faces to avoid or reduce their splits/polys. An non-bmodel alternative to func_walling stuff. It's not universally recommended, sometimes the end result can have just as many or even slightly more polys than without the trick.
This doesn't help with VIS, just an attempt at lowering the wpoly count. 

How come? I always thought less splits = less polys = easier VIS. 

won't the 1 unit gaps will just make more portals? portals are what's killing me atm. 

Spirit: No. VIS uses portals to determine what can be seen from where. Polys are the splits on surfaces, portals are portions of space and thus not directly related.

necros: Yes, but usually they can't be seen my many other portals unless, of course, it's a wide open and flat area. 

fair enough, didnt realise that. 

necros

Is that 700h estimate with the multithreaded vis? If so, yikes. :) 

...AGAIN *rolls eyes* 

willem: yes, and thank god for it too.

shambler: on the bright side, you get about 4 or 5 maps instead of one! 

that makes Vis take so goddamn long? I never really grasped that. 

Quake is meant for small to medium sized enclosed levels made of rooms and hallways and the technology was optimized for that. It's not a general purpose rendering engine, really.

So, deviate from that spec too much and you get pain. 

I understand that (from painful experience). I'm seeking technical reasons beyond "it was designed to do x not y" :) 

i also think that when qbsp is creating portals, it can't seem to deal with angled floors so it creates a bunch of small portals to approximate the shape.
when you consider terrain where you have pretty much an infinite amount of different slopes and what-have-you, you can imagine how bad it can get.

had a brief chat with aguirRe and what i understood is that you should be aiming to do all your major vis-blocking with a fast vis.
fast vis discards massive amounts of calculations that won't have to be done when you're doing a full vis.

unfortunately, a canyon, for example (or a high cliff wall that isn't flush with the ceiling) isn't enough for fast vis to work with, so it then delegates all that calculation to the full vis process which then has to iterate through everything bit by bit. 

"I understand that (from painful experience). I'm seeking technical reasons beyond "it was designed to do x not y" :)"

Well, the two seem sort of hand in hand. The technology was designed around a certain level design style (highly occluded environments with simple geometry) so it would stand to reason that any inefficiencies that didn't conflict with that goal would be left unoptimized as it doesn't stop them from shipping.

I don't know specifics but the overall gist seems fairly clear. :) 

take for example a simple square 128x128 hallway.

from what little i understand, the interior of this completely square hall is 1 leaf.

if the hallway had a 16 unit deep and 64 unit wide trough running down the center of the hall, that would be either 2 or 3 leafs.
if 2: 1 leaf for the 16x64 trough space + the hallway leaf.
if 3: 1 leaf for each side of the trough and 1 leaf for the trough from floor to ceiling.

each time there's a leaf, vis has to figure out if it's visible from another leaf.

the more complex the geometry, the more leafs there will be, hence the more calculations required.

in the case of some funky canyon with all kinds of angles everywhere, there might be say 50 leafs for a small cross-section of it. (totally guessing with arbitrary numbers here, but you get the point).

now, say you had your 128x128 hallway with a 90 degree bend in it. calculating what's visible around the corner is simple as there's only 1 leaf for each part of the hallway split by the corner.

if you had a same 90 degree corner on your canyon, vis will have to take into account the 50 leafs on one side and test each leaf against the other 50 on the other side of the corner. that's 50x50 = 2500 checks.

i don't think i'm entirely correct here, but this is the gist of it, afaik. 

there must be an engine port out there that will display leafs in-game? i know hl2 can do that which helps when optimizing with details. 

I understand very little, but it gives me some idea of what you guys have to wrestle with. 

darkplaces can display portals, which is similar (you can infer the shapes of the leafs based on the portals)