ZHLT netvis does it.
Also the idea is ancient, see http://www.celephais.net/board/view_thread.php?id=4&start=16&end=17

I doubt it would be too reasonable to make this. We got multi-threaded VIS just recently.

MH recently posted somewhere about how a well written modern engine can even be faster with unvised data if I recall correctly. 

> ZHLT netvis does it.

link? 

Unvised is something I might test sometime; it's a tradeoff though. The theory is that you can put the entire world into a big static vertex buffer and draw it without having to send any data to the GPU. Use shaders for water and sky and there is absolutely no need to modify vertexes at run time.

The tradeoff of course is that you'll have extra overdraw, but if bandwidth savings can more than compensate for it then you're in business. 

Always vis a map. Or DIE!!!! 

it's not a problem even for large maps, at least on semi-recent hardware. Overdraw is not so much of a problem as bandwidth usually is (for 3D accelerator cards). 

I'm glad I stayed to play more maps than the first one. The first map was pretty annoying in my opinion.
But the second map!!! Wow! This is a big very amazing map, Good stuff everywere, Good brushwork and texture use and a nice layout! Loved it (but not the wizards!)
I can see from the other comments that the good stuff continues!
Looking forward to play the next maps!
Thank you for making this pack folks! 

maybe i should have added an additional note in the OP: 'if you hate the first map, just skip to arc2!' :P 

it's not a problem even for large maps, at least on semi-recent hardware. Overdraw is not so much of a problem as bandwidth usually is (for 3D accelerator cards).

My thoughts exactly. Early Z and a few other things can work wonders for overdraw. It's not an alternative to fullvis, and will still run slower than fullvis (not least because you still need to exercise your vertex shader in order to get early Z), but at the least it should (could!) eliminate a lot of the badness from no vis. All purely theoretical and not to mention hardware dependent, of course. 

What you mean by early Z. But anyway, I have implemented a VBO renderer that can render for example Vondurs AC without ever looking at the BSP (it loads the map file). It's pretty fast and still has a lot of potential for optimization. 

that's pretty wild, loading it directly from the map file.
perhaps some stress testing with these arcanum maps? :P 

but the map files are in WC format. 

I guess I will play this maps for the next month... love then so much... I'm keeping first demos even when I died in 30 monters or so... anyone want then?

full reply after play then all

But must thanks you guys a lot, this is something I will never make... the quality, layout and bushwork is top is the kind of stuff few guys born for it!

I didn't :) 

Early Z means that the GPU can reject polygons based on depth before it gets to the fragment shader stage; hardware that doesn't support early Z can only reject after the fragment shader. No overdraw, the only overhead is in the vertex shader and primitive assembly, all good stuff. I believe that if you've got hardware T&L then you've also got early Z.

Loading from the map file would be great; you get no surface subdivision so there's none of that horrible heavy tesselation that Quake maps have, and that is a huge cause of slowdown. I believe HL2 stores the original map brushes in the BSP for exactly this reason, and it's something I'd be very in favour of if the community ever did get around to discussing proposals for a replacement BSP format.

Another neat trick - you can turn off backface culling for the world and all brush models. Quake backface culls in the engine anyway, so it's a completely unnecessary test for the GPU. Very small performance gain. 

Can someone with access to Hammer convert those arcanum sources to standard map format? Without the extended rotation shiznit? 

i couldn't load them in 1.6, so i guess it's the hl2 hammer? 

Especially when you land on the giant angel statues and they break ;) 

that was a nice touch. i was pretty surprised when it happened cause i was really focused on trying to make the jump from the spiral stairs to the platforms across the room. :P 

> if the community ever did get around to discussing proposals for a replacement BSP format.

It will. 

Read a bit about the 220 map format, and if I understand correctly, you can't really convert it to standard map format without loss of information. The texture axes stored in the map file cannot be reproduced in Quake because Quake uses a combination of two axes of the world coordinate system for the textures (hence the limits to texture rotation lock in standard Quake). Or do the extended compilers that come with the Quake adapter for WC 3.3 do some extra magic here? 

WC can export to .map. Are there differences between the Arcanum .rmf and the .map sources apart from the junk Hammer inserts? Which format corresponds to the bsps? 

"that seems pretty much impossible, I can't imagine how that could happen, fuck. In a month when I'm back I'll find the vised ones if anyone still cares I guess."

ReRelease it for QuakeExpo :D 

arc5: xvyyrq fbzr mbzovrf naq fpentf, "1 zber gb tb" ohg gurer vf abguvat ncneg sebz Fuhool (jub V'ir gevrq gb xvyy). Jung abj? 

If you don't find anything, there may be a spawning issue. 

You make the map in .rmf, then you export it to .map, then you compile the .map using txqbsp or any other compiler which has support for valve 220 texture format. If you want to edit the source you have to edit it in .rmf (because if you load the .map file into an editor many of the textures will become mis-aligned. But if you just want to re-compile then you should be able to just use the .map files included in to source. 

That's cool, so the textures do not get misaligned if you compile the map with a compatible compiler, then play in Quake? In other words, no oddly stretched textures on faces that are not on the coordinate planes anymore?