More About the *PROP_MASKS Block
More About the *PROP_MASKS Block
You only need to understand property "masks" if you plan to create your own property files, or to read the D3PLOT-generated ones into 3rd party software.
A "mask" defines the bits in a word that are used to contain data. In this context a "word" is always a single precision 32 bit integer, so you will be defining which of these 32 bits contain the data you want.
As an example let us take the problem of defining colour, which is specified by 4 components, generally known as RGBA in computer graphics:
| Component | Property mask | Description |
| R ed | RED_MASK | For each of red, green and blue the value must be in the range 0 to 100% |
| G reen | GREEN_MASK | |
| B lue | BLUE_MASK | |
| A lpha (transparency) | ALPHA_MASK | A value must lie in the range 0% (fully transparent) to 100% (fully opaque) |
Therefore bright red, with no transparency, would comprise 100% Red, 0% Green, 0% Blue, 100% Alpha.
Example 1: External data contains each colour component as a separate floating point value in the range 0.0 to 100.0
In this case the easiest solution would be to express your colours as 4 separate values. These must be integers, and the full bit field must imply 100%, so the easiest solution would be to convert the floating point range 0.0 to 100.0 into values in the range 0 to 255 by multiplying by 2.55 and writing the result as integers. The data masks you define might then be:
|
RED_MASK1255
GREEN_MASK2255 BLUE_MASK3255 ALPHA_MASK4255 |
Each colour channel is defined in a separate integer word Red = word #1, Green = word #2, Blue = word #3, Alpha = word #4 and lies in the range 0 - 255 |
And a typical property line to define some shells with labels 1 to 10 that are cyan (green + blue) and 50% transparent would then be
| Item name | Start label | End label | Word 1: Red value | W2: Green value | W3: Blue value | W4: Alpha value | .. further columns |
| SHELL | 1 | 10 | 0 | 255 | 255 | 128 | ... |
The choice of columns 1 to 4 for the RGBA components is arbitrary, you could choose any columns you like.
Example 2: External data contains each colour component packed in a single 32 bit word
A more compact, and very common, way of storing RGBA data is to express each colour component in the range 0 - 255, which requires 8 bits or 1 byte, and to pack these four bytes into a single 32 bit word. Drawn as a diagram we could express the 32 bits in this word as:
| Highest byte: Alpha bits | Blue bits | Green bits | Lowest byte: red bits |
| AAAAAAAA | BBBBBBBB | GGGGGGGG | RRRRRRRR |
We can now define our colour masks, assuming that the colour word is in column #1, as
RED_MASK10x000000ff
GREEN_MASK10x0000ff00
BLUE_MASK10x00ff0000
ALPHA_MASK 10xff000000
Hexadecimal (0x...) format has been used here, but the values could equally well - if less conveniently - be expressed in decimal. For example the Red mask 0x000000ff is the same as decimal 255 , and it would be legal to use that instead. Using this format our 50% transparent cyan shells would now be defined more compactly as:
| Item name | Start label | End label | Word 1: RGBA | .. further columns |
| SHELL | 1 | 10 | 0x80ffff00 | ... |
Again hexadecimal has been used here, since the decimal equivalent would be an unwieldy negative number.
What property masks are required?
You only have to provide property masks for the values you want to change. When property files are read in they only overwrite the attributes that they define so, for example, if you only included blanking information in a file the colour and lighting attributes of the model would be unchanged when it was read. Another example might be that you only have RGB colour information, and no Alpha (transparency) data. In that case omitting the Alpha mask and data word would leave item transparency unchanged when a file is read.
Which columns may data occupy?
Up to 20 columns of data may be provided, numbered 1 to 20, and any attribute may exist in any column. When the *PROP_MASKS data block is read the highest column number is remembered and the subsequent *PROP_DATA block must contain that many columns of data on each line. It doesn't matter if data in a given column is not read, for example if you already have formatted data and you want to ignore some of it simply define masks that only specify the data you want.
Valid property masks for D3PLOT:
| Mask name | Meaning | |
| BLANKED | The bit(s) used to designate that an item is blanked, ie blanked (non-zero) or unblanked (zero) | |
| MODE_MASK | The display mode for element graphics: 0= wireframe, 1 = hidden, 2 = shaded, 3 = current | |
| ALPHA_MASK |
The Alpha (transparency)
bits. 100% = opaque. |
It is assumed that a fully occupied bit field is 100% of the given component value for all these types |
| RED_MASK | The Red bits | |
| GREEN_MASK | The Green bits | |
| BLUE_MASK | The Blue bits | |
| BRIGHT_MASK | The diffuse brightness | |
| SHINE_MASK |
The specular brightness
(shininess) |
|
| OVLAY_MASK | The display mode for the element overlay: 0= wireframe, 1 = hidden, 2 = shaded, 3 = current | |
| OVL_R_MASK | Overlay red bits | It is assumed that a fully occupied bit field is 100% of the given component value for all these types |
| OVL_G_MASK | Overlay green bits | |
| OVL_B_MASK | Overlay blue bits | |
|
The following are D3PLOT-specific and reflect its internal storage of colour. External programmes would not normally use these, and can ignore them. They are included here for completeness. |
||
| OVL_CURRENT | Whether element overlay uses "current" colour or some other | |
| OVL_DEFAULT | Whether element overlay uses the parent element colour | |
| ENTITY_DEF | Whether elements use their default parent colour | |