133 hours is long, but it's not exactly LONG.
WVIS would help. 

beautiful. 

Seriously, multithread that shit. :) 

Too late for wvis now, it was just a shot in the dark,
looking if my efforts would have faith, and have a test vis.

I heared the stories of vis time for months,
but I didn't see this one coming.
I expected three days, my limith for vistime.
If it's more my interest become mapping smarter.
I had to take more care for the "sawn into leafs" warnings
and block everything out in func_wall.

Full:98.98% Elapsed:134h59m Left 10h36m Total: 145h35m 92% 

I predict three more days:) 

I don't know what sort of abuses you guys are throwing at VIS but damn ... I haven't seen a VIS longer than 10 minutes in years. 

Seriously. func_detail everything that isn't the shell of the level, and I would guess your compile time will drop like a stone to <1 hour with tyrann's latest vis tool.

Of course, don't that as gospel, I haven't seen your level :) 

Seriously. func_detail everything that isn't the shell of the level

Out of interest, how many bmodels can you throw into your levels these days, what with increased limits and whatnot?

Is the answer "all of them"?

Also, I'm guessing Tyrann's new lighting wizardry makes bmodels visually seamless with world geo?

#OutOfTheLoop 

func_detail isn't bmodel

Actually - my question still stands :) 

bmodels actually draw quite slowly. I had an great idea of making a huge, unreachable terrain as an external bsp bmodel.
I got less than 15fps. 

although that should be fixed now in QS 0.90.0, large bmodels should render as fast as the world.

With tyrutils you can set "_shadow" "1" on a func_wall to make it cast shadows. for more info: http://disenchant.net/files/utils/docs-release/light.txt . haven't tried that feature myself though. 

although that should be fixed now in QS 0.90.0, large bmodels should render as fast as the world.

Sweet. What was the reason the rendering sucked before? 

I think it was just lack of batching OpenGL calls (not sorting the bmodel faces by texture), so for each face of the bmodel, there were a bunch of gl calls to set up the gl state (bind textures, etc.), then draw the single face, then reset the gl state. This is fine for ammo boxes, but as the bmodel gets complex, all of those state changes start to take most of the drawing time. 

although that should be fixed now in QS 0.90.0, large bmodels should render as fast as the world.

Oh cool, I might try that again then! 

I was wondering about these... what is the process for making them that is different from normal mapping? I would love to do some custom pickups myself... 

there is almost nothing different.

you put some brushes into a .map file, add some lights, compile it.
next, you load it in the same way you would any other model file and it display in the engine.

if you make them solid, you can walk on them and collide with them just like any other.

you *can* rotate them, but it is weird and there are some technical limitations on that.

problems:
dynamic lights will not work on them (except in some engines)
if you rotate a solid bmodel, the collision is broken.

also, you don't need to make ammo pickups bmodels. they could be normal models, like in sock's mod. 

Since those work in Vanilla quake those are BSP I thought. I did not spot MDL's I must be missing something... 

While I'm not sure that sock exploits this, stock quake engines don't actually use the file extension to decide which file format to load. So you can take an .mdl format model, rename it b_shell1.bsp, and the engine will still load it. Or you can rename it hello.jpg and that's fine too, you can still write a mod with that as a custom resource. 

I think it was just lack of batching OpenGL calls (not sorting the bmodel faces by texture), so for each face of the bmodel, there were a bunch of gl calls to set up the gl state (bind textures, etc.), then draw the single face, then reset the gl state.

Ouch. 

I will have to give that a try indeed! :) 

It seems like the kind of thing that modern but cautious custom engines (like fitzquake derivatives) should display a "extension does not match model contents" warning, and exotic custom engines that support lots of other model formats may have broken support for inadvertently. Also, bear in mind if you replace a bsp with a mdl, the game will crash if that entity is given SOLID_BSP status - you need a genuine bsp for that to work. 

Everytime I read this I'm stunned... that Darkplaces & co. are still seen as "exotic" in some corners of the Quake community. Lord Havoc is among the people who put the most time and energy into this community, into QC extensions and so forth. He basically wrote the book. Yet, no one uses his engine except for custom textures. It's really weird.

Back when Nehahra was made, engine extensions were apparently cool.

Don't take this as a mortal insult, I'm just completely stunned by this.

I'd think a mapping theme of "use at least 1 Darkplaces extension and Q3BSP" would be pretty interesting to see. But well, that's just me.

Again, no flame. Just marvelling.

I'll go back into hiding now. 

The trouble is, for me, I really don't like the DarkPlaces look. So if the default look turns people off (I can't be alone) then engine extensions are going to be of minimal value.

Added to the fact that you'll then be locked into DP for your map and ... bleh. 

I would be interested to hear why people don't like DP (ooh-err!) around here.

To be fair, last time I tried DP (oh behave), was a few years ago, but it felt sluggish compared to fitz, had loads of annoying eyecandy crap on by default and I couldn't be arsed to trawl through a ton of stuff on the internet to figure out how to make it look more like quake - and the physics felt just slightly different.

I am aware that it has loads of awesome potential for modders and mappers (q3bsp spoooge)- but because no-one here plays in it, there isn't really an audience for DP-specific maps. 

Darkplaces is a good engine, too XD

The only thing I disliked about it was the mouse smoothing/acceleration or whatever it is. But I'm sure I can probably adjust it, if I only knew how....