headsUpDisplay

The number of blocks that will be visible within each section is dependent on the size of blocks contained in each section and the current size of the window. Blocks begin enumerating from 0 and flexibly increase based on need.

The resultant output string of each HUD is formatted within each block, using parameters defined by the formatting flags listed below (eg. justify, padding, labelWidth and dataWidth). The layout is shown in the following diagram:

 __________________________________________
|     |     |        |         |     |     |
|  P  |  J  |   LW   |   DWX   |  J  |  P  |
|_____|_____|________|_________|_____|_____|
P = Sub-block of width, padding
J = Justification of the entire block
LW = Sub-block of width, labelWidth
DWX = X number of sub-blocks of width, dataWidth, for X data elements.

Block Layout

The above diagram shows the layout of each block. The widths: padding, labelWidth and dataWidth are defined by their respective flags. To elaborate on the layout of the blocks, First the padding of the block is calculated. Then the two main sub-blocks (LW and DWX) in the above diagram, are justified and positioned together between the left and right margins of the block. The widths of the main sub-blocks are not variable based on it's contents. The only sub-block in the above diagram which is unique is the DWX sub-block which actually represents X number of sub-blocks, where X is the number of data elements returned by the command.

Block Positioning

Blocks on the top section begin from the top edge of the main viewport, while the bottom section begins from the bottom edge. Blocks are dynamically removed from visibility from the midpoint of the viewport. So, a relatively large block number will not draw to the viewport.

Lastly, there can be at most one HUD occupying a block at any time. Trying to position a HUD in an occupied block will result in an error. Keep this in mind when positioning the HUD.

In query mode, this flag needs a value.

attributeChange:  The script will be sensitive to any attribute changes in the currently
                  selected nodes.

connectionChange: The script will be sensitive to any connection changes in the currently
                  selected nodes.

instanceChange:   The script will be sensitive to any changes to an instance in the
                  currently selected nodes.

On query mode, this flag will return the values of all nodeChanges in pairs of values (the name of the nodeChange followed by its value).

WARNING: (Performance Warning)
         Attaching a nodeChange trigger to a selection based trigger can cause a large
         performance drop, if the node change that is being watched is caused by the
         HUD script itself.

         With this said, an attempt should be made to keep the HUD command/script
                 simple and limited to retrieving data. Changing an attribute, creating or
                 modifying a connection or instance will all result in a performance drop.

The following is a list of available presets and a description of each:

cameraNames

This will return the camera name that the view is looking through, in the data block, for each view that the HUD is drawing to.

polyVerts

This will return three values in the data block, regarding the number of vertices that are visible by the camera.

• 1st Value: Represents the number of camera visible vertices, both active and inactive.
• 2nd Value: Represents the number of camera visible vertices, on active objects only.
• 3rd Value: Represents the number of camera visible vertices, that are active.

polyEdges

This will return three values in the data block, regarding the number of edges that are visible by the camera. The order of these three values are similar to the polyVerts preset.

polyFaces

This will return three values in the data block, regarding the number of faces that are visible by the camera. The order of these three values are similar to the polyVerts preset.

polyUVs

This will return three values in the data block, regarding the number of UVs that are visible by the camera. The order of these three values are similar to the polyVerts preset.

polyTriangles

This will return three values in the data block, regarding the number of triangles that are visible by the camera. The order of these three values are similar to the polyVerts preset.

materialLoadingCount

This will return the material loading count. It updates on each refresh.

textureLoadingCount

This will return the texture loading count. It updates on each refresh.

frameRate

This will return a single string carrying both the frame rate and the "fps" string in the data block. It updates on each refresh.

viewAxis

This will draw the orientation of the grid axes within the HUD. It updates on each refresh. While this preset can take in all attribute flags, the only one which will have an effect are block attribute related flags (ie. block alignment and block size). The block dimensions of this preset are: blockSize - "large" and blockWidth - "50", which results in a 50x50 pixel region.

distanceFromCamera

This will return in the data block the distance from the view's camera to the centre of the bounding box containing the selected objects in the view.

 ________________________
|    |    |    |    |    |
|    |    |    |    |    |
| 0  | 1  | 2  | 3  | 4  |
|    |    |    |    |    |
|____|____|____|____|____|
|    |    |    |    |    |
|    |    |    |    |    |
| 5  | 6  | 7  | 8  | 9  |
|    |    |    |    |    |
|____|____|____|____|____|

Each section is denoted by a number from 0 to 9 as illustrated above. For example, if the second column of the top row was desired, the section would be defined as: -sec 1

To prevent HUD objects from displaying over each other and causing a clutter of letters, each row has a defined visibility precedence, where each section would have a visibility priority level. Depending on each priority level, when the screen space begins to shrink to a point where the section widths of a given row begin to collide, the HUD automatically compensates for this by removing the sections of least priority. These sections are made invisible and a warning is issued to inform the user of the removal. This continues until only the section of highest priority remains.

For each row, the priorities are defined as follows. Using the top row as an example: Section 0, has the highest priority, followed by Section 4, making the outermost sections of highest priority. Next in the list is Section 2, and lastly Sections 1 and 3 are of the equal and least priority. This priority structure can be applied to the bottom row as well. The two outermost sections have the highest priority, followed by the middle section, and finally the remaining two sections are of lowest priority.

This means that as the viewport gradually decreases in width to the point where sections in the top row begin to overlap, sections 1 and 3 will be removed from view first, followed by section 2, and finally section 4. A similar note is provided below for the block layout.