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

you can FORCE qbsp to honour your face divisions by offsetting textures by 1 unit (because then the compiler must consider them as a separate face) but you're just giving the compiler less leeway to work with and it'll probably perform even worse.
i find it's better to keep your brushwork clean enough so you can work well but to not fuss overmuch with what the compiler is doing. 

Isn't Q1BSP more of a software era thing? Cutting things into small triangles to minimize overdraw. Iirc the software renderer only uses z-buffer reads for models and the world bsp is rasterized front to back? D3 doesn't have those limitations and does a fair bit of culling at runtime afaik. 

IIRC the old QBSP used to or at least had a tendency to produce weird results on overlapping brushes or multi-face walls even if they were all on the same plane with the same texture and offset. This is why "clean" brushwork was propagated. Another well-known example apart from mitered corners is that technique where the brushes on arches are turned into triangles that meet in the upper corners.

Newer compilers take better care of such cases, although their results can still be arbritary at times. I found that occasionally "sloppy" constructions caused better splitting than "clean" brushwork for whatever reason. 

Newer compilers can combine faces, while older ones only split them. Doom3 doesn't need you to do any mitering because any extra cuts in a continuous surface that are introduced by the brushwork are optimized away again.


Doom3 also doesn't do any previs calculations, instead relying entirely on designer-placed portal surfaces that it tests for overlap in screen space in real time. (you can turn on r_showportals or something and see them turn red and green as you run around.) This is much simpler, and completely avoids any wacky how-is-qbsp-hacking-my-rooms-apart trouble, but also means you can't build any kind of large or interesting space that can't have its visibility constrained by little doorways. Yada yada yada and you get Doom3's level design.

This room was a bitch:

http://matthewbreit.com/images/q4dm11/1.jpg

That big solid platform in the middle blocks the view of doorways on either side of it from each other, but because those portals overlap in screen space they were always considered open. The proper solution is to have some kind of occluder or antiportal inside the platform, which doom3/quake4 didn't have, so we had to - surprise - cut the room apart in wacky ways with huge portals instead.