The C3D format is relatively complex from the programming viewpoint but, in exchange, the format offers the user unparalleled flexibility when its features are fully utilized within a software application.  When Dr. Dainis defined the format, all of the applications that accessed C3D files were written in FORTRAN.  As a result, many internal data structures within the C3D file are defined in ways that may seem counterintuitive to modern C++ programmers.  Additionally, all of the early documentation for the format referred to the file contents in terms of INT (integer) and REAL (floating point), thus requiring translations for younger programmers unfamiliar with traditional programming concepts.

A further complication arose when C3D reading and writing software was ported to other types of computer systems which have different internal number representations as compared to DEC computers.  The original implementation of AMASS transparently recognizes the three types of internal number formats, DEC, Intel, and SGI/MIPS.  Floating point number structure differs in all three architectures, while signed integer representation is the same for the first two but differs from the SGI/MIPS architecture.  This complication is not due to the C3D format but simply reflects the existence of differing computer environments.

These issues, and the fact that some areas of the original format description were not thoroughly documented, can result in problems when new C3D applications are written without thorough testing.  This can produce problems with other C3D applications and occasionally, the complete inability to read the resulting “C3D” file.  The cause can be due internal format errors within the C3D file or may be simply an internal limitation in the application:

·      Many older FORTRAN-based applications cannot read C3D parameter sections that contain more than twenty blocks of data.

·      One popular C3D application determines the start of 3D data in a C3D file incorrectly and is unable to read many standard C3D files that contain more than one data section.

·      Another widely used clinical C3D application uses a unique interpretation of a force platform parameter that does not agree with the published standard.

·      C3D files generated by another vendor used some nonstandard or miss-spelt parameter names in several early versions of their software.

·      Many older C3D applications support only one set of the C3D format variants (DEC, SGI/MIPS, Intel, and INT or REAL data) - often a problem with user-written applications.

·      Some software applications claim to produce C3D files but in practice, the files are unreadable due to various violations of the C3D specification (i.e. files that contain mixed floating-point and integer 3D data etc).

·      There has been some confusion over the use of signed vs. unsigned integers to store parameters within the C3D file – as a result it is possible to encounter C3D files with negative integer parameter values in interesting places (i.e. frame ranges and analog data offsets).

·      The C3D format description does not require that sensible scale values must be used.  As a result some C3D files exist that do not contain the correct values for the analog and point scale factors resulting in data corruption when files are converted from floating point to integer types. 

A list of major C3D application vendors is maintained at http://www.c3d.org with details of the various C3D applications available, manufacturer’s contact information and, in many cases, sample C3D files from the vendors.  This web site is maintained as a public resource for all C3D users and provides documentation and sample C3D files in the various formats that may be downloaded at any time for application testing and evaluation.