1. The parameter and group formats both provide space for a description string – this should always be filled in to provide some basic information about the item and its use – consider this as providing documentation about the information stored in the file.
2. Spell group and parameter names correctly – a software application that expects to read data from a parameter called OFFSET will probably fail to find it if the parameter has been spelt incorrectly as OFFSETS. Although the C3D specification states that the first six characters must be unique, the specification does not require that applications treat similar parameter names in the same way. In fact, many modern applications will consider that these two names describe different parameters.
3. For all non-array parameters, the usual method of having ‘d = 0’ is directly equivalent to having ‘d = 1’ and ‘t = 1’, the only difference is that the second approach requires one extra byte of storage.
4. The storage order of multi-dimensioned array parameters follows the FORTRAN convention (for historical reasons). In this format, the dimension that changes more rapidly appears first. For example, the reconstruction volume (parameter “DATA_LIMITS” in group “SEG”) is made up from two 3D vectors stored in the order MinX, MinY, MinZ, MaxX, MaxY, MaxZ
5. Using the convention, this is defined as a 3 by 2 array. Therefore, the correct definition for the parameter is Number of parameter dimensions = 2, Value of first dimension = 3, Value of second dimension = 2
6. The parameter data section ends when the index to the next item is zero.
7. There is no count stored for the number of parameters in each group and all group and parameter records can appear in any order. This means that it is permissible for a parameter to appear in the parameter section before the group information and software accessing a C3D file should be prepared to deal with this situation.
8. Parameters are connected to groups by use of the group ID number. Group records have unique ID numbers within the file, which are stored as a negative value in byte 2. All parameters belonging to a group will store the same ID as a positive value, also in byte 2.
9. Always use the absolute value of the first byte to determine the length of the parameter name. This value may be set to a negative value to indicate that the data item has been marked as locked and should not be edited.
10. Traditionally, all integers used in the parameter section are signed integers with a range of –32768 to +32767 and all bytes are signed bytes with a range of –128 to +127. However, some parameters may use unsigned integers to store data that will never have a negative value. Unfortunately, there is no flag to indicate that a C3D file uses unsigned integers in the parameter section. The use of unsigned integers can only be determined by finding negative values in certain parameter, pointer or index values. For example, reading a negative array index is a clear indicator that unsigned integers are being used.
11. Be aware that a group ID number may not be the same for a given parameter in a given set of files. Group ID numbers are required to be internally consistent in a single file but may vary even within successive saves of the same file, although in practice, most software tends to preserve Group ID numbers.
12. All C3D files require a minimum set of parameters in order to be portable across different environments – always ensure that the minimum set of required parameters are present in every C3D file.
13. Always look before you leap – all C3D software applications must test that parameters exist before they try to read them.
14. Do not assume that just because a parameter exists and has the name that you expect, that it will contain the same type of data. The parameter structure provides a means to determine the type of the parameter (floating-point, signed integer, character etc) before you read it. The consequences of reading a signed integer value when the data structure turns out to have been (unexpectedly) floating-point will cause applications to fail.
15. It is important to note that many older C3D applications may have a fixed amount of storage allocated within the application for Parameter Storage – this is particularly true for programs written in FORTRAN with fixed COMMON blocks. This can cause problems for users who add large numbers of parameters (or reserve storage space by dimensioning large arrays within the parameter section). This limitation can cause applications to fail in unexpected ways when they attempt to access C3D files with large parameters sections.
16. Applications that modify C3D files must take care to preserve all groups and parameters from the original input file even if the application does not use or understand the parameters.
17. When an application creates parameter records, it is sensible to make sure that the records are created with some reasonable values – if the parameter values are unknown when the parameter is created then the parameter contents should be set to some convenient null value – ASCII spaces or 0.0 for instance.
18. Although the capability exists, in practice parameter groups themselves are never locked. Locking is only used by individual parameters to flag items that that contain critical values within the C3D file structure. These parameters are described in detail in the chapter entitled Required Parameters.