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. 

Prepare for a possibly dumb contribution to the visibility discussion, but FWIW, what I remember from Q3 mapping was along these lines (it would be easier to do this with pictures but oh well):

Let's say you have a big cube of open space. A vertical wall divides the cube into two halves, but the wall is only half as tall as the cube. So you essentially have two rooms sharing an open space overhead.

The visibility here depends on how the compiler chooses to subdivide the space.

If it first cuts horizontally along the top of the divider wall, then the nodes for the space of each "room" will end up being only as tall as the divider wall, and they can't see each other.

However if the compiler first cuts vertically up the side of the divider wall, then there is going to be a tall node on that side of the wall, that goes all the way to the ceiling of the cube. In this case the nodes on each side of the wall can see each other.

The solution in Q3 was to have a horizontal hint brush face dividing the cube at the level of the top of the divider wall. So even if the compiler chose to chop vertically along the wall face first, the cut and therefore the room node would stop at the hint face.

If I'm misremembering/misunderstanding, or if the Q1 visibility issues are different, please clue me in... 

That's a really clear explanation. 

In that example, the compiler is going to prefer cutting up the side of the divider, without being given a hint. Every plane in the map is ordered based on preference for splitting. Vertical planes are higher priority than horizontal ones, and axial planes are higher priority than slanty ones. The map is assumed to be architectural in nature, so this assumption makes the compiler more likely to catch doorways or subdivide large spaces in a way that respects the layout. I think that's what we're really talking about.


This is why outdoor bits with lots of rocks tend to go kaleidoscopic, the compiler doesn't have a lot of vertical axial faces to go on so it digs deeper and starts using the sides of your wacky boulders to slice the space up. 

qbsp will usually clobber any fancy brush mitering you've done anyway.

i remember the doom3 compiler being really amazing about mitering things. i don't remember ever seeing it cut a wall up in anything but the best way.

quake bsp compilers aren't that good and rarely make the right cuts. to be fair, they are working under more stringent limitations (such as max face size) than doom3.