Oh well, sure, if you want a completely different style of map I agree. But that's true of textures as well. :P 

makes the point, or rather thats what I see to be the problem. In lots of screenies for newer engine games, rather basic architecture seems to be made up for by inserting lots of meshes when I think (purely from a non-mapper view) that meshes should augment the architecture rather than replace it. 

Meshes ARE the architecture these days. I understand that as Quake fans we are brush fiends but that doesn't fly for current gen games. Meshes are what allow you to add the necessary detail to a scene. 

http://necros.quaddicted.com/temp/cath2_1.jpg
after turning about 25% of the map into func_walls, and cutting off about 250 hours from estimated vis time, this map will still take about 700 hours. :(

looks like i will be forced to split this map up again (it was already split into 3 before this) to separate the outdoor area from the indoor one.
such a shame because it's really cool being able to see tall landmarks while you're exploring the cliffs and such, but the map is pretty much unplayable without proper vising, so fast vis only isn't an option. :S 

The sky cut off - the brush touching the tops of the geometry?

Even if the towers in the background are higher maybe use an angled brush to close everything in.

Only seems dumb when firing rockets or grenades into it (or bumping your head from a RJump) but concessions always have to be made . . . 

Um ... that looks ... how do I put this? FUCKING AMAZING! Holy crap, man!

I assume you've tightened up the sky as much as is possible to reduce the amount of open air? 

Or, what ijed said. :P 

i've been trying all sorts of stuff and yeah, sky brushes are as tight as they can be, unfortunately, i think it really just comes down to the nature of the map itself.

in some places, you can literally see about 16000+ units far. (the default fitzquake gl_farclip of 16384 was creating gray flash).

i think i've pretty much isolated the main problem though. behind the camera in that shot is a very tall and wide tower, which has a complex interior. unfortunately, fastvis doesn't discard that interior when you're outside the tower. after my previous post, i started to realized that it's pretty much impossible to split this map up without redoing the entire thing so i'm going to try a few more things to try to block out the interior area...

in order for me to do this map, i need to have my vis time to about at the maximum 100 hours. some previous maps i've done had vis times in multiple weeks and i refuse to work like that anymore. what happens is the vis process takes so retardedly long that you just don't have the guts to make any changes and fixes even when you notice some serious problems because you know it will be another 3/4 month before you can take another look. 

Make the tower door a teleport?

If it's already a doughnut corridor or c-bend then it shouldn't be causing so much trouble, but vis has mysterious ways.

If it's not using such a layout I'm guessing it'll be a headache to change because of the limited space. Taller with a spiral staircase maybe, although a ramp / stairs will still kick you in the vis sack.

And yeah, looks very nice. 

could some "floating 1px away from surroundings" tricks help? I never used that as it seems a bitch with lighting but maybe if the seams are in hardly visible places it might help. 

 

looks like i will be forced to split this map up again (it was already split into 3 before this) to separate the outdoor area from the indoor one. such a shame because it's really cool being able to see tall landmarks while you're exploring the cliffs and such

After you split it, you could re-create the distant landmarks in less detail for the indoor map, then when you arrive at those same structures in the outdoor map, you will recognize them. 

this may sound confused, I know nothing about the technicalities of mapping, but thats what I was kind of saying, meshes should be used to add detail. Which means the architecture its supporting would still effect the end result (ie a detailed box vs a detailed non-box). 

"this may sound confused, I know nothing about the technicalities of mapping, but thats what I was kind of saying, meshes should be used to add detail. Which means the architecture its supporting would still effect the end result (ie a detailed box vs a detailed non-box)."

It's obviously all up to the way a mapper prefers to build his things, but in a lot of games/maps, 99% of the architecture you see is actually meshes, there are several large UT3 maps sporting a grand total of 20-30 BSP brushes. In cases like this, meshes are used to add detail to the underlying architecture... which is made entirely of meshes as well. 

are you referring to toilet4 - saniflush the quake multiplayer map?

i LOVE THAT MAP :D 

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.