Difference between revisions of "Mapping:Mindriot hinting"
(→Mindriots Hint tutorial) |
(→Mindriots Hint tutorial) |
||
Line 1: | Line 1: | ||
+ | {{WIP}} | ||
+ | |||
==Mindriots Hint tutorial== | ==Mindriots Hint tutorial== | ||
Hinting guides the compiler in portal/node creation. Why is this done? The goal is to limit how much the engine draws based on where the player is currently in the map. This is an important method used to improve FPS. | Hinting guides the compiler in portal/node creation. Why is this done? The goal is to limit how much the engine draws based on where the player is currently in the map. This is an important method used to improve FPS. |
Revision as of 20:16, 19 August 2011
This page is work in progress! |
Mindriots Hint tutorial
Hinting guides the compiler in portal/node creation. Why is this done? The goal is to limit how much the engine draws based on where the player is currently in the map. This is an important method used to improve FPS.
Hint brushes must touch structural brushes on all sides for hinting to work properly. (Although it is possible to pull off hinting without hint brushes touching structural brushes, it has no benefit and is not recommended because it could just as easily not work during another compile.) All brushes should be detail unless they are part of the structural hull. Think of the structural hull as the frame of a house which you never see. The detail brushes would then be the painted drywall.
What is drawn is not based on the player line of sight, but on all possible lines of sight of the node that the player is in. So it's all about what nodes each node can see and those relationships are built into the bsp. Example: The player is in a node, which I'll call the active node. Every node that the active node can see is now valid, so everything (brushes, patch meshes, entities, etc.) within those valid nodes is drawn.
I'll start with version 6 and show how blocking is not achieved with this configuration.
This is the hallway with structural and detail brushes visible. It's best to do all hint work with detail brushes filtered - CTRL-D.
Now that the detail is filtered you can see the hint brush is selected as a prism brush. A 45 degree cut is typically used for hint brushes though they can be any shape and angle.
This is the same orientation, but now I've turned on the portal viewer. The portal viewer shows how the compiler has created the nodes by overlaying blue lines on the grid anywhere that the node boundaries don't follow structural brushes. You can also see the nodes in the 3D view. Follow this link and read the middle of the post on how to use the portal viewer.
Now back to the issue of line of sight. I've labeled all the portals with letters. In this case, the goal would be to prevent node A and C from seeing each other. Yet as the green line shows, A and C have a direct line of sight. That means if a player is anywhere in node A, then node C will be drawn and vice versa.
As it is, this is not a huge problem. Though once we join templates, the issue becomes apparent. The image below shows two joined templates connecting at the hallways as well as the nodes that have been created, which I have labeled.
As you can see with the green lines, node A can see node C. Also, nodes G, H, and I can also see node C. The real problem is if the player is standing in node C, because then all the nodes will be drawn with the possible exception of M. Of course, if there are any other nodes that C can see beyond what Radiant is currently showing, those also will be drawn.
Now for how this is avoided with Version 5.
By making sure that the hint brush touches the structural brush, node C is now isolated. The yellow circle shows this now that the hint brush has been resized.
By resizing the hint brush, it is now extending beyond the structural brush as shown by the yellow circle. This is not an issue because hint brushes are only a guide for the compiler and will only affect valid volumes formed by structural brushes. So the node guided by the hint brush is still bound by the structural brushes. The result is that node D is 4 sided, which is not a problem
In examining the line of sight between nodes A and C, we can see via the green line that node A will never see node C, so node C will never be drawn if a player is anywhere in node A or vice versa.
The same method applies if two templates are joined at the hallways. The image below shows two joined templates connecting at the hallways as well as the nodes that have been created, which I have labeled.
Again, upon examination of line of sights, we can see that the nodes are isolated from each other. Nodes A and C cannot see each other and nodes C, H, and I cannot see each other. The critical point is that if a player is anywhere in node C, only nodes D and E will be drawn and nothing else. This is the vis blocking and drawing reduction that occurs with proper hinting.
Please read this post for my method on hinting.
My method has changed slightly because I now use the 'skip' shader found in common_extra.shader packaged along with q3map2 2.5.16. The skip shader is not critical as hinting can be done without it. The skip shader is used to allow the hint shader to be applied to only certain faces of a brush.
I did not use the skip shader for this template. If I were to use the skip shader with this template, I would put skip on the entire hint brush and then put the hint shader only on the 45 degree angle face.