Hint Brush HowTo

[WolfWings ShadowFlight]

It's fairly straight-forward, for L-shaped hallways.



If you do more complicated hallways, hint-brush each corner like that in sequence, then merge the hint brushes if any of the faces you create along the red lines intersect. Don't bother trying to deal with intersecting hinting, just integrate the simple hinting pieces together. For example if you tried to hint-brush that S-curve hallway like the L-shaped one, you'd end up with two intersecting or nearly-intersecting hint brushes. Simplify that to the single larger 'hint brush' like above.

[DASPRiD]

Good explanation.. Works really well yet.

[WolfWings ShadowFlight]

And if you have a U-shaped hallway, don't just put a little V along one side of the U-turn. Either expand the U-turn or lengthen the hallway enough to make the far side of the point embed into the other side of the hallway, or manually stretch the point until it at least touches the far side of the hallway. I'll add another image to explain that case later today.

[David]

I'm not a mapper, and if this is going to be a mega long answer don't bother, but what is a hint-brush?

[Survivor]

A hint brush forces the compiler to use it for vis calculations. And now just an addition. Since trem uses the the visfield for radar calculations be careful. Good example is niveus in the corridor near the human base when you're an alien. Try it out.

[WolfWings ShadowFlight]

I'm not a mapper, and if this is going to be a mega long answer don't bother, but what is a hint-brush?

Long story short: It prevents the Q3A engine from drawing HUGE sections of the map you can't see that the 'automatic' visbility checks may mis-calculate. :-)

Since trem uses the the visfield for radar calculations be careful. Good example is niveus in the corridor near the human base when you're an alien. Try it out.

Ergo why I'm showing how to get the 'minimally obscured' hint brushes instead of the usual 'diagonal slash across the corridor' hint brushes. These obscure at the last possible moments.

Though Trem really SHOULD change to basing the Radar on the Audible set, not the Visible one.

[Survivor]

Audible set uses the vis set (but just includes 1 more field iirc SCRATCH THIS). See the niveus example again.

[gareth]

Though Trem really SHOULD change to basing the Radar on the Audible set, not the Visible one.

imho it should use the vis/hear sets, but just not with make it so closed area portals dont block it.

[Survivor]

the only use of portals is to close of vis. What you're saying removes the use of portals completely anyway.

And now the niveus example...

I can't save the audio but just trust me that i didn't hear any base sounds while the structures weren't on the radar.

Normal, Not on radar, no sound

Normal, Radar, Sound present

Wireframe mode, Not on radar, no sound

Wireframe mode, Radar, Sound present


If you don't trust me try it out yourself and see the lack. I think extending the radar by a single visportal could solve most problems since it isn't that intensive on the server or player computer iirc.

[gareth]

the only use of portals is to close of vis. What you're saying removes the use of portals completely anyway.

i meant the radar shouldnt be blocked by closed area portals, the vis oc should. or maybe the radar could just see objects in connected clusters upto x units away.

[WolfWings ShadowFlight]

TBH, the Radar systems need to be re-worked IMHO.

The server needs to track the Radar system seperately, and only notify the client as dots come in and go out of range, and specify their fixed position each time.

I.E. As you're moving around the Server should tell the Client 'HumanBuildingInRange #,<x>' and 'AlienBuildingOutRange #' type messages as events.

Right now the Radar just shows all entities the client can see as blips on the HUD as appropriate. Crude, kinda works, but makes the standard FPS-raising techniques invalid to use on most Tremulous maps as a side-effect.

[jal]

But the bandwitch increase required to send the radar dots alone is pretty big, and Trem already suffers with big player counts (note for devs: replacing huffman with zlib would help a lot, I did it for wsw and was shocked by the result). I don't know how it is sent now, but, since it seems to depend on vis, I guess it's simply not sent, but generated from the entities in the PVS.

[WolfWings ShadowFlight]

But the bandwitch increase required to send the radar dots alone is pretty big, and Trem already suffers with big player counts (note for devs: replacing huffman with zlib would help a lot, I did it for wsw and was shocked by the result). I don't know how it is sent now, but, since it seems to depend on vis, I guess it's simply not sent, but generated from the entities in the PVS.

Replacing huffman with zlib wouldn't gain any appreciable bandwidth over the Q3A networking system. News flash, zib (deflate compression) uses Huffman compression combined with LZ77. The 'delta packet' approach of Q3A is roughly equivilant to the LZ77 step, so in effect Q3A is using a modified Deflate approach to transmitting game-state already.

And as I said, right now the Radar is generated from the entities in the PVS that are already sent to the client. Converting the Radar as I mentioned would be unlikely to appreciably increase the bandwidth Tremulous used. And it would only be transmitted for entities the client can't see, but that need to show up on the Radar.

[techhead]

Not to mention trying to evolve in two hallways next to eachother.
"You are too close to the enemy's location to evolve. Please move away until you are no longer aware of the enemy's presence."

That, and the fact that you can be inside radar range and still be far enough away to evolve.

One of the most unhelpful error message in the game.

That, and "Overmind Needs Spawns"

[jal]

But the bandwitch increase required to send the radar dots alone is pretty big, and Trem already suffers with big player counts (note for devs: replacing huffman with zlib would help a lot, I did it for wsw and was shocked by the result). I don't know how it is sent now, but, since it seems to depend on vis, I guess it's simply not sent, but generated from the entities in the PVS.

Replacing huffman with zlib wouldn't gain any appreciable bandwidth over the Q3A networking system. News flash, zib (deflate compression) uses Huffman compression combined with LZ77. The 'delta packet' approach of Q3A is roughly equivilant to the LZ77 step, so in effect Q3A is using a modified Deflate approach to transmitting game-state already.

Don't teach your daddy how to make a baby.

I'm talking from a real experience here. Difference is not only appreciable, it's huge.
Since I changed to zlib I had to have > 25 players* in the server before the message started being fragmented in more than 1 packet. With Huffman it fragmented when > 11 players*. This players-per-packet view can't be compared inside Q3 scheme, since Q3 compresses after fragmenting*, but gives a good idea of the gain in a real game case. The rest of the Warsow netcode is pretty much the same as Q3A one: delta compression for ps and ents, and reliable command strings.

And btw, not everything is delta compressed in the Q3 message. Reliable commands aren't, for example, and they are a very big part of the message when they are present.

*Rough averages taken with bots playing ffa.

EDIT3: *Just reviewed Q3 src and I was wrong about the compression-fragmentation order. It fragments after compression for not oob msgs, so it's even better.

EDIT: Sorry for the off-topic. I just wanted to make a small side comment in my in-topic post. Since everything is clear now, I hope we can continue with the original discussion.

[WolfWings ShadowFlight]

Um... splitting the datastream arbitrarilly (fragmenting the packets) is a complete non-issue with Huffman compression. At most you round the data-stream off to the nearest byte, and suffer from an extra header on the packet.

Again, what you're describing is only adding an explicit LZ77 pass to the Q3A netcode, which I believe is unlikely to compress the datastream appreciably. Converting to Arithmetic or Range Coding would be a much larger improvement, for example.

[jal]

Again, what you're describing is only adding an explicit LZ77 pass to the Q3A netcode, which I believe is unlikely to compress the datastream appreciably.

I'm bored of coders who think they know everything. Trying to argue against a fact will make you a better politician, but not a better coder. And yes, maybe there are better compression algorithms that could be used, I'd have to try them to know, but switching to zlib doesn't take more than 30 lines of code, given that zlib is already linked in Q3. So I'm suggesting a prooven, superior to 200% effective gain, with virtually no work alternative.

[WolfWings ShadowFlight]

I'm bored of coders who think they know everything. Trying to argue against a fact will make you a better politician, but not a better coder. And yes, maybe there are better compression algorithms that could be used, I'd have to try them to know, but switching to zlib doesn't take more than 30 lines of code, given that zlib is already linked in Q3. So I'm suggesting a prooven, superior to 200% effective gain, with virtually no work alternative.

And how, exactly, am I arguing against a fact? zlib is nothing more than LZ77, followed by Huffman compression. Any cursory bit of research can verify that. Since Q3A already does delta compression, and already uses huffman compression just before transmission, the only difference switching the explicit Huffman-compression calls for ZLib calls would have is (in effect) adding an LZ77 pass between the delta compression and huffman compression. That's all I've been saying.

And I thought you were showing support for switching the Huffman calls to ZLib purely for reduced bandwidth usage. Re-phrasing as you did this time, which appears to be a code-cleanlyness improvement since it would remove the built-in compression routines to use a widely-available external compression library instead, is an entirely different kettle of fish, and a much more reasonable idea.

If you were going for pure bandwidth-reduction, a full-packet BWT combined with Range Compression would do a lot more good. BWT would be feasable mostly because the packets are so small so full-packet block-transforms are computationally feasable in realtime.

[jal]

You argue against a fact because you insist in that the compression wont be relevant, while I tell you that I tried and checked the result, and gave you the output. Those are facts, not arguments.
 I honestly don't feel like entering the discussion of why, first, because I don't really know the in and outs of zlib compression, but, let me tell you 2 details I know:
1/The Q3 message is not completely delta compressed, but only the entities.
2/The delta compression in Q3 has nothing to do with the delta compression pass at zlib. Q3 delta-compresses the snap data against the last snap data acknowledged by the client.

And yeah, it would be nice if someone could try other compression algorithms. I'm not any expert in compression, but I guess there are others that could do better.

[gareth]

Stop talking shit, get some test cases done for tremulous if you want to prove something.

[jal]

Sure, lesson learnt, don't worry. I will never again offer advise to those unable to accept it.

[Stof]

Don't listen to gareth, he is just flaming you.

About that zlib thing, I guess it warants testing. But someone would have to code it and submit a patch to bugzilla.

[jal]

I'm sorry, but I'm not going to do it myself. I don't have any plans on doing Trem modding, so I don't feel like mounting up all the stuff for compiling Trem. All I wanted to do is a small side comment with a suggestion.

[Dersaidin]

http://www.gamedesign-online.com/index.php?page=tutorials&t=bsp

Explanation for another game (based on Q3 engine) which is very good.
I map for this game, Wolfenstein:Enemy Territory

http://tremmapping.pbwiki.com/Understanding%20Vis%20and%20Hint%20Brushes
Another one for Trem.

[WolfWings ShadowFlight]

http://www.gamedesign-online.com/index.php?page=tutorials&t=bsp

Explanation for another game (based on Q3 engine) which is very good.
I map for this game, Wolfenstein:Enemy Territory

http://tremmapping.pbwiki.com/Understanding%20Vis%20and%20Hint%20Brushes
Another one for Trem.

Unfortunately, hint brushes as are commonly shown (the 45-degree angle wedges) are provably sub-optimal. Both of those articles are prime examples of this, in fact. Hint brushes as shown in my mini-picture are the mathematically optimal placement, and for many people explains how hint brushes work far better than simply saying 'cut all your corners in hallways at 45 degrees' which usually makes mappers ask why the tools don't do that automatically.

Admitedly, in huge ET-sized maps you can run into the plane-limit from the added planes created by the 'optimal' hint brushwork, but in general Tremulous maps are far too small to worry about that obstacle so it's better to create optimal brushwork IMHO.

I've mapped a bit, or at least helped map a fair bit for ET in the past, and have done some mapping for Q3A as well, and I am one of the people that helped Ratty refine his alpha-blended terrain technique, all because I understand the hard numbers behind things instead of accepting simplified explanations.

[techhead]

This topic should be renamed "Hints on Hint Brushes"

[WolfWings ShadowFlight]

This topic should be renamed "Hints on Hint Brushes"

How so? It shows the proper angles for the faces on a hint brush, which is what hinting actually is when you break it down to the core math. It gives concrete examples for the most common and the majority of the cases where you'd use a hint brush at all.

Are there any additional places where hint brushes are useful that you think I should add examples for? Any situation where the hint brush ends up parallel to the caulk hull does nothing though, so things like most U-turn hallways don't benefit from hinting in some recent testing I did.

This howto does assume that mappers are using modern techniques including caulk-hull mapping, but again that's because hinting is a final-stage optimization to a map. Building with the latest techniques will save far more in r_speeds and visibility than any amount of hinting would.

[Survivor]

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

[techhead]

I just liked the pun.

[WolfWings ShadowFlight]

I just liked the pun.

Ah. Sorry, I'm too literal-minded to catch puns a lot of the time. =^.^=