Hint Brushes

(ACROBAT) #1

Does anyone know why it’s perfectly ok to make a hint brush that has a diagonal yet it’s always said to be bad to make a structural brush that has a diagonal. Since, hint brushes are treated as structural brushes, they act just like structural brushes.

I also think leaf nodes are always squares or triangles so when you have a digaonal portal line created by a hint brush or a structural brush, the game will have to use many square leaf nodes approximate a diagonal line.

Is there something I’m missing here?

(SCDS_reyalP) #2

Non-axis-aligned structure is less efficient, but that isn’t the same as “always bad”. Almost everything in level design is a trade off.

Since, hint brushes are treated as structural brushes, they act just like structural brushes.

Most structural brushes aren’t trans, so they aren’t exactly the same.

I also think leaf nodes are always squares or triangles so when you have a digaonal portal line created by a hint brush or a structural brush, the game will have to use many square leaf nodes approximate a diagonal line.

Is there something I’m missing here?

Diagonal structure isn’t approximated with a bunch of squares.

(ACROBAT) #3

I’ve used hint brushes a lot by creating diagonal portal lines, but it never really makes sense as to why I would do something like that other than tutorials that I read. It always seems like a hallway like this would be much more effective so that there are no diagonal portal lines and splitting of leaf nodes.

Diagonal structure isn’t approximated with a bunch of
squares.

By saying this, you are claiming leaf nodes are not square, which is contrary to what I have read. Even in radiant the diagonal is not an actual diagonal line. It’s just a staircase that approximates a diagonal line. To actually have a true diagonal line the squares would have to become infinitly small like in limits in calculus so the game has to approximate that the diagonal with very small squares, and very small lead nodes.

Non-axis-aligned structure is less efficient, but that isn’t the same as “always bad”. Almost everything in level design is a trade off.

That statement explains nothing.

Most structural brushes aren’t trans, so they aren’t exactly the same.

What do you mean by trans? Translucent? I’m only talking about with respect to the -vis compile they are the same, and in that sense they both draw portal lines.

(SCDS_reyalP) #4

Correct. They aren’t.

which is contrary to what I have read.

Either what you read was wrong, or you misunderstood it. If you can provide a link, that might help.

Even in radiant the diagonal is not an actual diagonal line. It’s just a staircase that approximates a diagonal line.

That’s how it’s rasterized on your screen, but really it’s just a line between two points.

To actually have a true diagonal line the squares would have to become infinitly small like in limits in calculus so the game has to approximate that the diagonal with very small squares, and very small lead nodes.

That’s not how it works.

What do you mean by trans? Translucent? I’m only talking about with respect to the -vis compile they are the same, and in that sense they both draw portal lines.

I mean surfaceparm trans, which has a very important effect on vis, although not strictly relevant to the question at hand.

(ACROBAT) #5

So can leaf nodes be any shape? Squares, triangles, octagons etc?

(SCDS_reyalP) #6

http://graphics.stanford.edu/~kekoa/q3/
http://hosted.planetquake.gamespy.com/spog/stuff/technical.html

A leaf is a convex volume. It does not need to be axis aligned or square.

(obsidian) #7

There is nothing wrong with non-axial structural brushes. Depending on the situation, non-axial structural brushes may be just as efficient as axial ones. What you want is simplified structural brushes to reduce the number of leaf nodes generated.

Diagonal hint brushes don’t automatically make them more efficient, it’s just that in many applications, that’s just what happens to work the best. Axial hints will work best in other situations, it all depends on what you are doing. See link below, I’ve used both axial and non-axial hint brushes efficiently to achieve different things.

By saying this, you are claiming leaf nodes are not square, which is contrary to what I have read. Even in radiant the diagonal is not an actual diagonal line. It’s just a staircase that approximates a diagonal line. To actually have a true diagonal line the squares would have to become infinitly small like in limits in calculus so the game has to approximate that the diagonal with very small squares, and very small lead nodes.

WTF? You’re way out on left field on this one. Diagonal vectors are diagonal vectors. Just because the pixels on your screen aren’t aliased doesn’t mean it’s not a true diagonal vector.

Read this, I think I’ve linked to it before. Regardless, you should read it or read it again.

http://www.quake3world.com/forum/viewtopic.php?t=3620

(obsidian) #8

Here we have some axial hints. They create three leafs, A B and C. You’ll notice that area B has a non-axial side. Big whoop-dee-doo, this doesn’t affect things one bit.

The blue tinted area is a raytrace of player1’s line of sight. He can see directly see everything that is shaded.

The gray area is the Potentially Visible Set (I wrote “Viewable”, sue me). Everything in this area is drawn by the graphics card regardless of the fact that the player can’t physically see most of the stuff in area C. You will notice that everything is shaded gray. That is because in this situation, axial hints are in a least efficient possible position.

Because player1’s line of sight includes just a small part of area C, all of area C and beyond is drawn. Not very efficient silly mapper!

Here, we see Player2’s line of sight. He can’t directly see into area C at all but it is still included in his PVS. Why? Because he has the potential of moving over to Player1’s position where area C is part of his line of sight. Imagine that there are actually large rooms beyond the doorways of this hallway on either end. Standing anywhere in one of those rooms, everything in the entire map will still be completely drawn because of badly placed hints. Yuck.

To fix, we have here a single diagonal hint. It now has 4 leaf nodes. The number of leaf nodes doesn’t exactly co-relate to efficiency. What is important is reducing the amount of geometry being drawn in the game world. That’s the whole point of the PVS and leaf nodes in the first place.

You can see that Player1’s LOS includes areas A B C, but no part of area D is not part of his LOS. He can move anywhere in area B and his LOS will never include area D. So we can drop area D from his PVS. Nothing in area D or beyond will be drawn. Yay.

Let’s say Player1 moves to Player2’s position in this newly hinted area. Player2 can move anywhere in area A and his LOS will only include areas A and B. As long as he stays in area A, C and D will never become part of his LOS so areas C and D are dropped from his PVS and are not drawn.

As you can see, in this situation, diagonal hint brushes are more useful than axial hint brushes. Keep in mind, this does not mean that diagonal hint brushes are always better, just better in situations like this. There are plenty of other cases where axial hints will do a better job. It all depends on the situation.

(ACROBAT) #9

Ya I think I have a good understanding of PVS sets and the stuff you are drawing. I guess I was just paranoid about the effects of diagonal portal lines in general beyond the scope of what the hint brush tutorials say because I had an impression that they were splitting leaf nodes. I have gotten that max_visability error many times and I thought that might be related to # of leaf nodes in the map.

Depending on where you default portal lines are drawn, the long sections of the hallway are normally divided up so without a hint brush you might see part of the long hallways on each end of that structure, but you won’t see the entire hallway or into the next room because of default portal lines that the blocksize command draws in the game.

Something like this. See even if you stand at one end, your game might draw part of thew hallway on the other end, but not all of it and you can never see the two main rooms that the hallways would lead to at the same time. I have been doing it this way because I assumed that drawing some extra hallway was better than diagonal portal lines?

On a different topic, I really want to start using _blocksize 0 in my maps. To do this I would use hint brushes, skip, hintskip, and subtle_hint? I mean I would basically be making square blocks of hint brush, and each block I made would be a lead node? Any suggestions or warnings on using _blocksize 0?

(obsidian) #10

What’s the point of disabling blocksize and then dropping in square hints? It’s the same thing!

In your diagram, when will you ever have hallways that large and long to span over 3 or 4 blocksize grids? That’s insane.

There is absolutely nothing wrong with non-axial leaf nodes. I can make an entire map and rotate it 45-degrees and as far as vis is concerned, it wouldn’t make a difference.

You really need to point out where you are reading these retarded tutorials because everything they are teaching you is wrong. These authors need to be taken out and shot.

(SCDS_reyalP) #11

blocksize zero is almost certainly NOT a good idea. Blocks split before everything else, so they aren’t quite the same as using cubes of hint.There might be some pathological cases where manually splitting everything was a win, but you’d have to have a very good understanding of how the compiler and engine work (which you clearly don’t yet, no offense intended), and a whole lot of spare time.

There is absolutely nothing wrong with non-axial leaf nodes. I can make an entire map and rotate it 45-degrees and as far as vis is concerned, it wouldn’t make a difference.

This generally true although it it would make some difference in the overall size and efficiency of your BSP. ISTR there is also a compiler limit you hit with excessive non-axial structure. However, as I said before, this is a trade-off, not a hard and fast rule that non-axial structure is bad.

(ACROBAT) #12

Well with super large maps I tend to get that max_visibility error, which is related to having too many portal lines and leaf nodes and too big of prt table.

Is there any reason why a large square room shouldn’t be represented as one gant leaf nodes rather than being cut up by the blocksize command?

I realize that I would have to make sure that you can’t see one room from the next room, and I think I could manage that. I’ve been using a shader called subtle_hint lately so that the diagonal hint brushes don’t extend through distant parts of the map so that helps also. I mean if I tested it with r_showtris and made sure that each room is sectioned off this seems like a good idea to me??

(SCDS_reyalP) #13

You can increase your block size, and/or completely disable blocking in the z direction. This will usually be preferable to completely disabling blocks. I’ve had situations where manually splitting in the Z axis was beneficial compared to blocking.

Keeping your structure simple is the other way to reduce vis data. Obviously, things like terrain need to be detail. You can also save by making your major walls line up with blocks.

Is there any reason why a large square room shouldn’t be represented as one gant leaf nodes rather than being cut up by the blocksize command?

It depends. If the room and it’s contents are simple, then this is probably fine. However, the leaf nodes also determine what brushes are considered for collision detection, so for example, having a whole terrain in a single leaf can lead to very bad performance, even if the r_speeds is OK.

I realize that I would have to make sure that you can’t see one room from the next room, and I think I could manage that. I’ve been using a shader called subtle_hint lately so that the diagonal hint brushes don’t extend through distant parts of the map so that helps also. I mean if I tested it with r_showtris and made sure that each room is sectioned off this seems like a good idea to me??

That’s why I added subtlehint to the radiant distribution. Normal hint splits before other brushes (but after blocks) while subtlehint spits with the same priority as normal brushes. There is also priority for which sides of a brush split first (axial over non-axial and vertical over horizontal, if I remember right). You can also mix hint, subtlehint, and skip on the same brush. (I also added a shader called hintskip, which is exactly the same as hint to the compiler, but filters correctly with hints in radiant)

The prtview plugin is a great way to see what is going on with your structure and hints.

(ACROBAT) #14

I’ve been using that hint_skip shader also. It’s very handy.

It depends. If the room and it’s contents are simple, then this is probably fine. However, the leaf nodes also determine what brushes are considered for collision detection, so for example, having a whole terrain in a single leaf can lead to very bad performance, even if the r_speeds is OK.

What is an example of collision detection? Like bumping into a wall that is made out of detail or something? Or shooting a wall?

Also I generally look at fps instead of r_speeds since I never really knew the difference. They seem similiar to me.

(SCDS_reyalP) #15

For every client frame, both the client and server have to check if the player ran into any of the brushes of any of the leafs that the client touches. Weapon hit detection etc. also has to do similar checks for every leaf the shot passes through.

Also I generally look at fps instead of r_speeds since I never really knew the difference. They seem similiar to me.

If you only look at FPS on your own system, you can miss problems that occur on different systems. For example, if your system has a strong CPU and a weak GPU, you will miss problems that happen on weak CPUs. There are many variables in system performance, so you can’t just say “if a fast system gets 100 fps here, a slow one will get at least 50”.

r_speeds is a measure of the number of polygons rendered. This doesn’t correlate directly to performance (some polygons cost more than others, and not all performance load is related to rendering), but it can give you a system independent idea of where problems are likely to be.

(ACROBAT) #16

For every client frame, both the client and server have to check if the player ran into any of the brushes of any of the leafs that the client touches. Weapon hit detection etc. also has to do similar checks for every leaf the shot passes through.

So basically you’re saying it’s very good to have portal lines every 1024 grid unites because of it is calculating collisions? This is with regard to detail brushes also I assume since you can collide with them?

So is it ideal if a portal line lines up perfect with say a square detail brush that is acting as a wall for example?

Also, in a big open room, as long as there is aboslutely nothing to run into in the middle it would be good to have one giant leaf node in that area?

(SCDS_reyalP) #17

You have to have a lot of stuff in a single leaf for it to be a real problem. 1024 is probably a much smaller blocksize than you need on most maps. My pathological test map for this had 16000 brushes in a single room, and this of course had very large impact on performance.

So is it ideal if a portal line lines up perfect with say a square detail brush that is acting as a wall for example?

Not really sure what you are asking here.

Also, in a big open room, as long as there is aboslutely nothing to run into in the middle it would be good to have one giant leaf node in that area?

A big empty room should be OK, but manually blocking your whole map because you have some large rooms that don’t actually need the block splits would be silly. There are of course other reasons you might want to have splits in a relatively empty room.

I’d also note that people have tendency to obsess over optimal construction more than they need to. If a given room isn’t going to push the limits, you can construct it in whatever way is fastest to build. If you design your map such that only a few areas have the potential for performance problems, then you will have a lot more time to spend on making sure it looks good and plays well. Sometimes good enough is better than perfect :wink:

(ACROBAT) #18

For every client frame, both the client and server have to check if the player ran into any of the brushes of any of the leafs that the client touches. Weapon hit detection etc. also has to do similar checks for every leaf the shot passes through.

Well I keep coming back to this collision thing. It seems giant leaf nodes are no problem unless there is a lot of collision going on.

How do you define collision? bumping into walls or shooting walls?

What I meant earlier is it good to end a leaf node where a player will collide with something? Say you have and outdoor map and a wall over on one side that is 4 times as high as a player. Is that a good spot to end a leaf node?

(SCDS_reyalP) #19

A lot of potential collision. Also, this is assuming you don’t have any VIS related reasons to split things.

How do you define collision? bumping into walls or shooting walls?

Actually bumping into the wall or not doesn’t matter. The game has to figure out whether a player (or shot or any of the various other things that interact with world geometry) touched any of the brushes associated with that leaf.

What I meant earlier is it good to end a leaf node where a player will collide with something? Say you have and outdoor map and a wall over on one side that is 4 times as high as a player. Is that a good spot to end a leaf node?

Depends on the map. One wall more or less isn’t gonna matter.