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.... 

Out of sheer curiosity and insanity, I just installed DP to check how close to Quake can I make it look.

Model interpolation is essentially required, since you can't turn off movement interpolation.

Particles are shit and blurry even at the highest quality, and apparently there's no option to make them square. They don't behave correctly, either, because way too many of them spawn, and also smoke particles seem to fade to solid black before disappearing. This is very noticeable when using the GL.

Underwater warp exists, but the actual water surface doesn't get warped. All it does is a Q3-like rotation.

No way to disable colored dynamic light, by the looks of it.

The game font is scaled at some weird size that makes it blurry with linear filtering and MSPaint-quality jaggy with nearest filtering. 

OK, but if someone is able to use QC extensions (or, hm, if someone is able to create game levels, even) I would expect them to be able to take DP's particlefont image and just paint themselves some nice new particles, even blocky ones if they want.

If too many particles spawn, well, the particles are customizable so someone could write a vanilla set with square blocks instead of dots.

Waterwarp is gonna have to be a shader. You can probably do it with a Q3 shader, but I think MH wrote some pretty cool waterwarp GLSL some time back that could be ripped. Perhaps there's even a cvar for Quake-style waterwarp.

I'm just saying these issues are not insurmountable for people who routinely create game content. IMHO getting to use the QC extensions is worth a little investment polishing the particles and whatnot.

Just as an example, hipnotic and I believe Chapters (and who knows, maybe Quoth) uses copyentity implemented in QC. It's in hordespawn I believe. That is absolutely horrible for various reasons. DP has a nice simple builtin that does that. Same for many other things. It's just an improvement to have such things provided as engine builtins any way you look at it.

I agree that it should have a "vanilla preset" like FTE does though.

Regarding DP-only, well, a lot of maps are Fitz/QS-only in practice, which is the same thing. DP is easy to install and free.

On the other hand, extensions could be added to Fitzquake etc, but that's gonna be significantly more work and you need engine coders to do it, whereas most of the other stuff can be done by content authors.

Just my 2 cents. 

Cheers. One of the absolute most basic requirements of a custom quake engine should be that it's possible to make it look like vanilla Quake.

Otherwise, well there's your reason no-one uses it here I guess.