Helps a lot! 

Alternatively, the func_togglewall you're probably using for the physical part of the forcefield can be made to damage players that touch it with the "dmg" key. Saves an entity or two and a bit easier to set up - it's also the best way to do it if the forcefield can ever turn back on, as killtarget will remove the damage irreversibly.

http://tomeofpreach.wordpress.com/quoth/tutorial/func_togglewall/ 

I can't seem to get togglewall working to be honest. The brush doesnt appear in the game. 

thats intended. Spawnflag 1 + once triggered makes it appear. You can trigger it near the playerstart, when its out of sight, to make it appear. Everything iirc. 

I stumbled across a tutorial using the source engine and Hammer, the topic was optimization. He kept talking about visleafs and func_detail... which started to make me paranoid.

Some time ago I released a small part of a map in its early stages on QuakeOne. Of the complaints, the one that really disturbed me concerned high r_speeds.

I've been going through the map, merging wherever possible, mitering convex corners, making new textures in places where I had originally used several brushes to do the same job, using func_walls where appropriate, etc, etc.

However, my ignorance of the way quake works is allowing my mind to wonder and assume the worst.

When running around with wireframe I see some (sometimes rather large) areas being drawn even though there is absolutely no way it could be visible.

In some ports (DirectQ) some doors/illusionary disappear at certain angles. I'm not sure if this is because I'm doing something wrong, or if it's just quake/DQ. I don't get any errors when compiling.

Here is the lates bsp log (TxQBSP), does anything look odd? Like some number being too big or small in relation to another? This is my only map so I have no point of reference.

http://www.killpixel.com/kpcn/bsplog.jpg

Now that I think about it, a vis log probably would have been helpful...

Any insight would be appreciated, I just want to correct anything I'm doing poorly/completely wrong. 

Logs aren't very helpful in this respect. The best data you've got is r_showtris 1 in engine.

First off, are you doing fullvis? Thats a requirement for properly vis blocking your level. The -fast option should only be used for testing, and to be honest if you're using hint brushes properly then you won't even need the -fast option any more.

I've seen some great tutorials on this down the years, but can't seem to find many good quake specific ones now due to the various websites closing.

Here's a short one which gives you the overview:

http://www.quake-1.com/wc16a-tutorial/speed.html

But from what you've posted it might be the exact same one.

This is a programmer's guide to the format;

ftp://ftp.sgi.com/other/bspfaq/faq/bspfaq.html

And here's a non-quake visual discussion;

http://jheriko-rtw.blogspot.com/2010/04/visibility-testing-and-bsp-trees.html

Basically, there's tricks used playing off certain factors of the Quake engine and BSP format.

- vis does not respect vertical height (if its open at any point vertically it's considered completely open)
- switchbacks help, multi-tiered arenas hurt
- Doughnut corridors (a pillar in a corridor that is wider than the entrance / exit of the corridor
- ALL decorative stuff can and should be hint brushes, the bare bones structure being solid brushwork (this includes pillars, free standing or part of the walls)

There's a lot to add to this of course. 

"- vis does not respect vertical height (if its open at any point vertically it's considered completely open)"

Isn't this just a more confusing way of saying "it's using portals"? Meaning, if you can see the portal, then you can see everything that portal can see. 

Yes, fullvis.

Thanks for the literature.

Quake1 uses hint brushes?

https://developer.valvesoftware.com/wiki/Hint_brush

IIRC r_speeds on my system are fine.

Makes me wonder how many people are still using a 386 to play these maps...

I should probably use func_wall more often, 99% of the decorative stuff is made of normal brushes. 

"ALL decorative stuff can and should be hint brushes"

No. Hint brushes are meant for manually influencing the vis portal generation. Their implementation in Quake is experimental at best and there hasn't been conclusive testing, yet.

If you meant detail brushes, then no again. These are mainly for speeding up the VIS process, but do not have optimizing effects on the polycount.

If you meant decorative stuff should be func_wall or the like - this isn't a general solution, either. It's situational and may as well increase the polycount or have other negative side effects. 

That cleared several things up for me.

I don't use func_detail as I'm not sure how it's different than func_wall. AFAIK func_detail is only supported by specific compilers?

Also, I've restrained from making all the decor func_wall because of the polycount. So far, I've used this very sparingly. 

Instead of func_wall, func_detail creates so called tjunctions in your bsp, which prevent the flickering edges. Iirc. 

Willem, you're assuming someone who's asking for the basics will already know what a portal is.

Sorry, yeah I meant func_detail, and that's why I was talking about the -fast option earlier.

They just allow you to reduce portal creation, but that's no help to poly count.

func_detail has the advantage over func_wall in that it can cast shadows. Additionally, most engines still have the flickering entity bug - if a func_wall crosses two vis leafs or more it will go invisible when viewed from a leaf the engine considers it shouldn't be visible from.

Basically, it assumes that brush models will always be of a comparable size to a point entity.

Additionally, func_walls are not made static, so will consume resources during runtime, while func_detail is not treated as an entity by the engine at all. 

The difference is func_wall is a (dynamic) brush entity while func_detail is only relevant to the compiler which will disregard these 'detail brushes' when generating VIS information and subsequently convert them back to world geometry. This is only supported by a few compilers; those without support will treat func_details as normal brush entities which will then make them disappear in game since they're an unknown type (QC).

Mind you, turning stuff into brush entities (e.g. func_wall) CAN help with optimization, but it depends on the areas/situation and some random factors, so it's not automatically the ultimate solution to everything. It requires careful testing and evaluation. 

I wasn't aware it cast shadows and isn't counted as an entity. That's pretty nice.

My understanding of portals is pretty shoddy, an article for them has yet to be written on quakewiki.

I'm not able to see if TxQBSP supports func_detail in any documentation, I guess I'll run some tests after work. 

Article I linked explains portals relatively concisely.

I'm using Tyrann's compilers for the detail support since they've also got a load of nice little features like per brush entity minlight and coloured lighting as well as all the light controls you'd expect coming from Tx.

http://www.disenchant.net/ 

 

vis does not respect vertical height (if its open at any point vertically it's considered completely open)

I don't think this is true, is there an authoritative source for this? 

yeah, I read that and declared aloud "are you fucking kidding me?" 

Surely this would be testable ny making a vertical map 

Nope. It's something I got from early Q2 mapping and assumed was the same for all.

Maybe I should do a test map before each post. 

It almost reads like mapping lore they gets passed along and nobody ever really understands or questions it.

Like, I have friends who make Quake maps who clip and miter every brush so that nothing ever overlaps. Ever. Totally clean construction. I've tried to explain they are wasting their time and QBSP takes cares of all that but they will hear none of it! "It makes for cleaner and better performing maps", they say. I say it makes for a lot of wasted time that could be spent more productively... 

Mitering convex corners is optimal. 

In what sense? I mean, if you're slamming up against engine limitations, sure, go for it but otherwise ... What's the point? 

It still comes out a more efficient map to run, however negligible the gains might be.

A few weeks ago I went through my map to try to get some vertexes back, as I'm nearing the limits of bsp29. I mitered most convex corners and got about 2k verts back from that alone.

I also fixed a lot of my early brushwork, it was really shoddy. brushes in brushes in brushes in bushes, all sorts of random shit of all sizes, off the grid even, all in one big mass of noob mapping.

After going through and optimizing the map, I had about 6k back and shaved 30 minutes off the compile time.

I can't explain it, those were my results. 

You better miter those brushes damnit!!

I'm partway through making a vert map right now with a door in every ceiling (it's a 768 map), I just tested this theory using r_showtris 1 and it doesn't appear to be true, it's definitely not drawing every single floor.