Using some of the external editors for minecraft to whip out amazing structures like this is probably fun, but I imagine as soon as I started I'd ask the question "why am I using this engine?" 

one of us just wins the lottery, so that we can ALL have the "3 months" or whatever that it took that guy.

Loved the link btw. Sucks that as time goes by there's less time for mapping. At least for me. And others perhaps. Ahem. Necros.


If one of us wins the lottery, we should all just make "What Quake was supposed to be" as a game. You travel to different realms, upgrade the hammer, it has RPG elements, etc. Lol. 

I would start up a game studio as one of my first things to do... and hire a bunch of people from func. 

I'm through vising, there's no point.

Full:97.71 Elapsed 116h13m Left 17h13m Total 133h27m 87%

happy newyear. 

Using all the tricks in the book I am sure too. I tried a lot of Sock's tricks from Zendar with Func_Detail and Skip Render brushes that would contain those elements. TON of work sheesh but does make it worth in the end. 

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! :)