ISO 14306-3:2025

International
Standard
ISO 14306-3
First edition
Industrial automation systems
2025-06
and integration — JT file format
specification for 3D visualization —
Part 3:
Version 2
Reference number
© ISO 2025
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword . vi
Introduction . viii
1 Scope . 1
2 Normative references . 1
3 Terms, definitions and abbreviated terms . 2
3.1 Terms and definitions . 2
3.2 Abbreviated terms . 2
4 Notational conventions . 3
4.1 Diagrams and field descriptions . 3
4.2 Data Types . 8
4.3 Empty field . 11
5 File Format . 12
5.1 General File Format . 12
5.2 File Structure . 12
5.2.1 File Header . 12
5.2.2 TOC Segment . 14
5.2.3 Data Segment . 16
5.3 Logical Element Header ZLIB . 20
5.4 Data Segments . 21
6 LSG Segment . 23
6.1 LSG Data Collection . 23
6.2 Graph Elements . 23
6.2.1 Node Elements. 24
6.2.2 Attribute Elements. 49
6.3 Property Atom Elements . 93
6.3.1 Base Property Atom Element . 93
6.3.2 String Property Atom Element . 94
6.3.3 Integer Property Atom Element . 95
6.3.4 Floating Point Property Atom Element . 96
6.3.5 JT Object Reference Property Atom Element . 96
6.3.6 Date Property Atom Element . 97
6.3.7 Late Loaded Property Atom Element . 99
6.3.8 Vector4f Property Atom Element . 100
6.4 Property Table . 101
6.4.1 Element Property Table . 102
7 Shape LOD Segment . 103
7.1 General Shape Lod Segment . 103
7.2 Shape LOD Element . 103
7.2.1 Base Shape LOD Element . 103
7.2.2 Vertex Shape LOD Element. 104
7.2.3 Tri-Strip Set Shape LOD Element . 119
7.2.4 Polyline Set Shape LOD Element . 119
7.2.5 Point Set Shape LOD Element . 120
7.2.6 Null Shape LOD Element . 121
7.3 Primitive Set Shape Element . 121
7.3.1 Lossless Compressed Primitive Set Data . 123
7.3.2 Lossy Quantized Primitive Set Data . 125
iii
8 Geometry Segments . 130
8.1 General Geometry Segments . 130
8.2 STEP B-Rep Segment . 130
8.3 XT B-Rep Segment . 130
8.4 JT ULP Segment . 130
8.5 JT LWPA Segment . 130
8.6 Wireframe Segment . 130
8.7 JT B-Rep Element (deprecated) . 131
9 Meta Data Segment . 132
9.1 General Meta Data Segment . 132
9.2 Property Proxy Meta Data Element . 132
9.2.1 Date Property Value . 134
9.3 PMI Manager Meta Data Element . 135
9.3.1 PMI Entities . 138
9.3.2 PMI Associations. 160
9.3.3 PMI User Attributes . 162
9.3.4 PMI String Table . 163
9.3.5 PMI Model Views . 164
9.3.6 Generic PMI Entities . 166
9.3.7 PMI CAD Tag Data . 171
9.3.8 PMI Polygon Data . 173
10 Data Compression and Encoding. 177
10.1 General Data Compression and Encoding . 177
10.2 Common Compression Data Collection Formats . 177
10.2.1 Int32 Compressed Data Packet . 177
10.2.2 Int32 Compressed Data Packet Mk. 2 . 183
10.2.3 Float64 Compressed Data Packet . 189
10.2.4 Compressed Vertex Coordinate Array . 193
10.2.5 Compressed Vertex Normal Array . 194
10.2.6 Compressed Vertex Texture Coordinate Array . 197
10.2.7 Compressed Vertex Colour Array . 198
10.2.8 Compressed Vertex Flag Array . 201
10.2.9 Point Quantizer Data . 201
10.2.10 Texture Quantizer Data . 202
10.2.11 Colour Quantizer Data . 202
10.2.12 Uniform Quantizer Data . 204
10.2.13 Compressed Entity List for Non-Trivial Knot Vector . 204
10.2.14 Compressed Control Point Weights Data . 208
10.2.15 Compressed Curve Data . 209
10.2.16 Compressed CAD Tag Data . 212
10.3 Encoding Algorithms . 215
10.3.1 Uniform Data Quantization . 215
10.3.2 Bitlength CODEC . 216
10.3.3 Arithmetic CODEC . 217
10.3.4 Deering Normal CODEC . 222
10.4 zlib compression . 224
11 Common Data Conventions and Constructs. 225
11.1 General Data Conventions and Constructs . 225
11.2 Late-Loading Data . 225
11.3 TOC Segment Location . 225
11.4 Bit Fields . 225
11.5 Empty Field . 225
11.6 Local version numbers . 225
11.6.1 Version numbers . 226
iv
11.7 Hash Value . 228
11.8 Scene graph construction . 228
11.9 Metadata Conventions . 229
11.9.1 CAD Properties . 229
11.9.2 PMI Properties . 234
11.9.3 Tessellation Properties . 331
11.9.4 Miscellaneous Properties . 332
11.10 LSG Attribute Accumulation Semantics . 333
11.11 LSG Part Structure . 334
11.12 Range LOD Node Alternative Rep Selection . 334
11.13 Brep Face Group Associations . 334
11.14 Handling of different states / variants in a ISO 14306 file . 335
11.14.1 Reference Sets . 336
11.15 Watermarks . 337
11.15.1 Background . 337
11.15.2 Issue – Missing specification in the ISO . 337
11.15.3 Recommended Solution . 337
11.15.4 Issue – Protection of data . 339
12 Conformance requirements . 341
Annex A (normative) Information object registration . 342
Annex B (informative) Object Type Identifiers . 343
Annex C (normative) STEP B-Rep . 346
Annex D (normative) STEP schema . 350
Annex E (informative) Coding Algorithms – An Implementation . 422
Annex F (informative) Hashing – An Implementation . 458
Annex G (informative) Polygon Mesh Topology Coder . 461
Annex H (informative)  XT B- Rep segment . 480
Annex I (informative)  XT B- Rep data segment . 486
Annex J (informative) PMI Data Segment . 570
Annex K (informative) Mapping table from ISO 10303-42 to XT B-Rep . 571
Annex L (informative) JT B-rep Segment . 577
Annex M (informative) Wireframe Segment . 604
Annex N (informative) JT ULP Segment. 608
Annex O (informative) Change History . 663
Bibliography . 664

v
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national
standards bodies (ISO member bodies). The work of preparing International Standards is
normally carried out through ISO technical committees. Each member body interested in a subject
for which a technical committee has been established has the right to be represented on that
committee. International organizations, governmental and non-governmental, in liaison with ISO,
also take part in the work. ISO collaborates closely with the International Electrotechnical
Commission (IEC) on all matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed
for the different types of ISO document should be noted. This document was drafted in accordance
with the editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
ISO draws attention to the possibility that the implementation of this document may involve the
use of (a) patent(s). ISO takes no position concerning the evidence, validity or applicability of any
claimed patent rights in respect thereof. As of the date of publication of this document, ISO had
received notice of (a) patent(s) which may be required to implement this document. However,
implementers are cautioned that this may not represent the latest information, which may be
obtained from the patent database available at www.iso.org/patents. ISO shall not be held
responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does
not constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see
www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 184, Automation systems and
integration, Subcommittee SC 4, Industrial data, in collaboration with Technical Committee
ISO/IEC JTC 1 Information Technology, Subcommittee SC 24, Computer graphics, image processing
and environmental data representation and Technical Committee ISO/TC 171, Document
management applications, Subcommittee SC 2, Document file formats, EDMS systems and
authenticity of information.
This first edition cancels and replaces the second edition (ISO 14306:2017), which has been
technically revised.
The main changes are as follows:
— correction of specification of TRANSMIT FILE in section H.2 which previously stated the
definition to be SCH_1200000_12. This has been corrected to read SCH_
SCH_1200000_12006;
— added a normative reference to ISO 14306-2;
— updated reference to STEP schema to read {1 0 14306 3 114};
— changed references to JT to read ISO 14306 where applicable.
A list of all parts in the ISO 13406 series can be found on the ISO website.
vi
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html.
vii
Introduction
The ISO 14306 format is an industry focused, high-performance, lightweight, flexible file format
for capturing and repurposing 3D product definition data for visualization to enable collaboration
and validation throughout the extended enterprise. The ISO 14306 format is streamable and
contains compression for compact and efficient representation.
Some of the highlights of the ISO 14306 format include:
— built-in support for assemblies, sub-assemblies and part constructs;
— a flexible partitioning scheme, supporting single or multiple files;
— b-rep solid shape representations to provide precision to the light-weight viewing
processes;
— product manufacturing information in support of paperless manufacturing initiatives;
— precise and imprecise wireframe shape representations;
— discrete purpose-built levels of detail;
— triangle sets, polygon sets, point sets, line sets and implicit primitive sets (such as cylinder,
cone and sphere);
— a full array of visual attributes such as for materials, textures, lights;
— hierarchical bounding box and bounding spheres;
— data compression that allows producers of ISO 14306 files to fine tune the trade-off
between compression ratio and fidelity of the data.
Beyond the data contents description of the ISO 14306 format, the overall physical
structure/organization of the format is also designed to support operations such as:
— offline optimizations of the data contents, therefore file granularity and flexibility
optimized to meet the needs of enterprise data translation solutions;
— asynchronous streaming of content, therefore viewing optimizations such as view frustum
and occlusion culling and fixed-framerate display modes;
— layers, and layer filters.
NOTE This document is based on the JT Open version 9.5 specification, which defines a scene graph with
geometry specific node and attribute support, extended to support the ISO 10303 series.
Annex A contains an identifier that conforms to ISO/IEC 8824-1. The identifier unambiguously
identifies this document and the schema in an open information system. The ISO 14306 series
applies the method as described by ISO 10303-1.
viii
International Standard ISO 14306-3:2025(en)

Industrial automation systems and integration —
JT file format specification for 3D visualization —
Part 3:
Version 2
1 Scope
This document defines the syntax and semantics of a file format for the 3D visualization and
interrogation of lightweight geometry and product manufacturing information derived from CAD
systems, using visualization software tools that do not need the full capability of a CAD system.
This document has been adopted as a 3D visualization capability in addition to the ISO 10303
series.
The ISO 10303 series are the ISO standards adopted for the engineering data exchange, sharing
and long-term archiving of product definition information throughout the product lifecycle.
In this document 3D visualization is defined as the visual presentation on a screen or another
media of graphical and textual 3 dimensional representations of a set of data representing an
object, information or results of a computational process in order to enable decision process by a
human looking at the data visualized in a medium.
The file format supports the following information:
— facet information (triangles), stored with geometry compression techniques;
— visual attributes such as lights, textures and materials;
— product manufacturing information, such as dimensions, tolerances and other attributes;
— boundary representation (b-rep) solid model shape representations. Several
alternatives are available, including a representation based on the geometry standard
defined in ISO 10303;
— configuration representations;
— delivery methods such as asynchronous streaming of content.
The document does not specify the implementation of, or definition of a run-time architecture for
viewing or processing of the file format.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies.
For undated references, the latest edition of the referenced document (including any
amendments) applies.
ISO 10303-21, Industrial automation systems and integration — Product data representation and
exchange — Part 21: Implementation methods: Clear text encoding of the exchange structure
ISO 10303-42, Industrial automation systems and integration — Product data representation and
exchange — Part 42: Integrated generic resource: Geometric and topological representation
ISO 14306-2, Industrial automation systems and integration — JT file format specification for 3D
visualization — Part 2: Vocabulary
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 14306-2 apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp
— IEC Electropedia: available at https://www.electropedia.org/
3.2 Abbreviated terms
For the purposes of this document, the following abbreviated terms apply.
Abs Absolute Value
Bbox Bounding Box
B-Rep Boundary Representation
CAD Computer Aided Design
CODEC Coder-Decoder
GD&T Geometric Dimensioning and
Tolerancing
GUID Globally Unique Identifier
HSV Hue, Saturation, Value
JT Jupiter Tesselation
LsbFirst Least Significant Byte First
Max Maximum
Min Minimum
MsbFirst Most Significant Byte First
N/A Not Applicable
PCS Parameter Coordinate Space
PLM Product Lifecycle Management
RGB Red, Green, Blue
RGBA Red, Green, Blue, Alpha
TOC Table of Contents
URL Uniform Resource Locator
4 Notational conventions
4.1 Diagrams and field descriptions
Symbolic diagrams are used to describe the structure of the ISO 14306 file, see Table 1. The
symbols used in these diagrams have the following meaning:
Table 1 — Symbols
Symbol Description
Rectangles represent a data field of one of the standard data types.

Folders represent a logical collection of one or more of the standard data types. This
information is grouped for clarity and the basic data types that compose the group

are detailed in following sections of the document.
Rectangles with extra lines at left and the right sides corners clipped off represent
information logical steps that has been compressed.

Rectangles with the right side corners clipped off represent information that has been
compressed.
Arrows convey the ordering of the information.

The format used to title the diagram symbols is dependent upon the symbol type as follows:
Diagram “Rectangle box diagram” (standard data types) symbols are titled using a format of
“Data_Type : Field_Name.” The Data_Type is an abbreviated data type symbol as defined in 3.2
Data Types. In the example shown in Figure 1 the Data_Type is “I32” (a signed 32 bit integer) and
Field_Name is “Count.”
I32 : Count
Figure 1 — Rectangle box diagram

Diagram “folder” (logical data collections) symbols are simply titled with a collection name. In the
example shown in Figure 2 the collection name is “Graph Elements.”
Graph Elements
Figure 2 — Folder diagram
Diagram “rectangle box with lines at left and right sides” are simply titled with a logic step name.
In the example shown in Figure 3 the logic step name is “Recover First Shell Indices”.
Recover First Shell
Figure 3 — Rectangle box with lines at left and right sides diagram

Diagram “rectangle box with clipped right side corners” (compressed/encoded data fields) are
titled using one of the following three formats:
Data Type; followed by open brace “{“, number of bits used to store value, closed brace “}”, and a
colon “:”; followed by the Field Name. This format for titling the diagram symbol indicates that
the data is compressed but not encoded. The compression is achieved by using only a portion of
the total bit range of the data type to store the value (for example if a count value can never be
larger than the value “63” then only 6 bits are needed to store all possible count values). In the
example shown in Figure 4 the Data Type is “U32”, “6” bits are used to store the value, and Field
Name is “Count”.
U32{6} : Count
Figure 4 — Rectangle box with clipped right side corners

Data Type followed by open brace “{“, compressed data packet type, “,”, Predictor Type, closed
brace “}”, and a colon “:”; followed by the field name. This format for titling the diagram indicates
that a vector of “Data Type” data (primal values) is ran through predictor type algorithm and the
resulting output array of residual values is then compressed and encoded into a series of symbols
using one of the two supported compressed data packet types.
The two supported compressed data packet types are:
Int32CDP – The Int32CDP ( Int32 Compressed Data Packet) represents the format used to
encode/compress a collection of data into a series of Int32 based symbols. A complete description
for Int32 Compressed Data Packet can be found in 10.1.1 Int32 Compressed Data Packet.
Int32CDP2 – The Int32CDP2 (.Int32 Compressed Data Packet Mk. 2) represents a second-
generation version of the above compressed data packet, and sports a simplified and more
compact file layout, and the ability to more efficiently encode clustered data and bitfields. A
complete description for Int32 Compressed Data Packet Mk. 2 can be found in 10.1.2 Int32
Compressed Data Packet Mk. 2.
Float64CDP – The Float64CDP (therefore Float64 Compressed Data Packet) represents the format
used to encode/compress a collection of data into a series of Float64 based symbols. A complete
description for Float64 Compressed Data Packet can be found in 10.1.3 Float64 Compressed Data
Packet.
The Int32 Compressed Data Packet type is used for compressing/encoding both “integer” and
“float” (through quantization) data. While the Float64 Compressed Data Packet type is used for
compressing/encoding “double” data.
In the example shown in Figure 5 the data type is “VecU32”, Int32 Compressed Data Packet type
is used, Lag1 predictor type is used, and Field Name is “First Shell Index.”
VecU32{Int32CDP, Lag1} : First Shell Index

Figure 5 — Compressed data packet diagram

As mentioned above (with predictor type algorithm), the primal input data values are not always what is
encoded/compressed. This is because the primal input data is first run through a predictor type algorithm,
which produces an output array of residual values (therefore difference from the predicted value), and this
resulting output array of residual values is the data which is actually encoded/compressed. The ISO 14306
format supports several predictor type algorithms and each use of Int32CDP or Float64CDP specifies, using
the above described notation format, what predictor type algorithm is being used on the data. The ISO
14306 format supported predictor type algorithms are as follows (note that a sample implementation of
decoding the predictor residual values back into the primal values can be found in Annex C).

Table 2 — Predictor Type
Predictor Description
Type
Lag1 Predicts as last value
Lag2 Predicts as value before last
Stride1 Predicts using stride from last two values
Stride2 Predicts using stride from values 2 and 4 back
StripIndex This is a completely empirical predictor. Looks at the values
two back and four back in the stream, and uses the stride
between these two values to predict the current value if and
only if the stride lays between -8 and 8 noninclusive, else it
predicts the value as the one two back plus two. In pseudo-
code form the predicted values is computed as follows:
if(val2back - val4back < 8 && val2back - val4back
> -8)
iPredicted = val2back + (val2back -
val4back);
else
iPredicted = val2back + 2;
Ramp Predict value “i” as values “i’s” index
Xor1 Predict as last, but use XOR instead of subtract to compute
residual
Xor2 Predict as value before last, but use XOR instead of subtract to
compute residual
NULL No prediction applied
Each predictor type, shown in Table 2, can be combined with additional processing steps, and in
such case the predictor type is prefixed with “Combined:” For example, “Combined:Lag1” means
that predictor type “Lag1” is combined with additional preprocessing steps. Additional
description about the processing steps is provided whenever such combined predictor is used.
“Data Type : Field Name”. This format for titling the diagram symbol indicates that the data is both
compressed and encoded. The data_type is an abbreviated data type symbol as defined in data
types and usually represent a vector/array of data. How the data is compressed and encoded into
the data type is indicated by a CODEC type and other information stored before the particular data
in the file. In the example shown in Figure 6 the Data_Type is “VecU32” and Field_Name is
“CodeText.”.
VecU32 : CodeText
Figure 6 — Data type : Field Name diagram

For some ISO 14306 file segment types there is ZLIB compression also applied to all bytes of
element data stored in the segment. This ZLIB compression applied to all the segment’s data is not
indicated in the diagrams through the use of “rectangle box with clipped right side corners”.
Instead, one shall examine information stored with the first element in the file segment to
determine if ZLIB compression is applied to all data in the segment. A complete description of the
ISO 14306 format data compression and encoding can be found in 5.2.3 Data Segment and 10 Data
Compression and Encoding.
Following each data collection diagram is detailed descriptions for each entry in the data diagram.
For rectangles this detail includes the abbreviated data type symbol, field name, verbal data
description, and compression technique/algorithm where appropriate. If the data field is
documented as a collection of flags, then the field is to be treated as a bit mask where the bit mask
is formed by combining the flags using the binary OR operator. Each bits usage is documented,
and bit ON indicates flag value is TRUE and bit OFF indicates flag value is FALSE. All bits fields that
are not defined as in use should be set to “0”.
For folders (data collections), if the collection is not detailed under a sub-section of the particular
document section referencing the data collection, then a comment is included following the
diagram indicating where in the document the particular data collection is detailed.
If an arrow appears with a branch in its shaft, then there are two or more options for data to be
stored in the file. Which data is stored will depend on information previously read from the file.
The following example, shown in Figure 7, shows data field A followed by (depending on value of
A) either data field B, C, or D.
I32 : A
A = = 2
A = = 1
U8 : B U16 : C U32 : D
Figure 7 — Data filed dependency example

In cases where the same data type repeats, a loop construct is used where the number of iterations
appears next to the loop line. There are two forms of this loop construct. The first form is used
when the number of iterations is not controlled by some previous read count value. Instead, the
number of iterations is either a hard coded count (for example always 80 characters) or is
indicated by some end-of-list marker in the data itself (thus the count is always minimum of 1).
This first form of the loop construct is shown in Figure 8.
I32 : A
U8 : B
Figure 8 — Loop construct example

The second form of this loop construct is used when the number of iterations is based on data (for
example count) previously read from the file. In this case it is valid for there to be zero data
iterations (zero count). This second from of the loop construct, shown in Figure 9, looks as follows
(data field D is repeated C value times).
I32 : C
U8 : D
C
Figure 9 — Loop construct with iterations example

4.2 Data Types
The data types that can occur in the ISO 14306 binary files are listed in the following two tables,
Table 3 and Table 4.
Table 3 lists the basic/standard data types which can occur in ISO 14306 file.
Table 3 — Basic Data Types
Type Description
UChar An unsigned 8-bit byte.
U8 An unsigned 8-bit integer value.
U16 An unsigned 16-bit integer value.
U32 An unsigned 32-bit integer value.
U64 An unsigned 64-bit integer value.

I16 A signed two’s complement 16-bit integer value.
I32 A signed two’s complement 32-bit integer value.
I64 A signed two's complement 64-bit integer value.

F32 An IEEE 32-bit floating point number.
F64 An IEEE 64-bit double precision floating point number

Table 4 lists some composite data types which are used to represent some frequently occurring
groupings of the basic data types (for example Vector, RGBA colour). The composite data types
are defined in this reference simply for convenience/brevity in describing the ISO 14306 file
contents.
Table 4 — Composite Data Types
Type Description Symbolic Diagram
BBoxF32 The BBoxF32 type defines a bounding box using two
CoordF32 types to store the XYZ coordinates for the
CoordF32 : Min Corner
bounding box minimum and maximum corner points.
CoordF32 : Max Corner
CoordF32 The CoordF32 type defines X, Y, Z coordinate values. So a
CoordF32 is made up of three F32 base types.
F32 : Data
CoordF64 The CoordF64 type defines X, Y, Z coordinate values. So a
CoordF64 is made up of three F64 base types.
F64 : Data
DirF32 The DirF32 type defines X, Y, Z components of a direction
vector. So a DirF32 is made up of three F32 base types.
F32 : Data
GUID The GUID type is a 16 byte (128-bit) number. GUID is
stored/written to the ISO 14306 file using a four-byte
U32
word (U32), 2 two-byte words (U16), and 8 one-byte
words (U8) such as:
U16
{3F2504E0-4F89-11D3-9A-0C-03-05-E8-2C-33-01}
In the ISO 14306 format GUIDs are used as unique
U8
identifiers (for example Data Segment ID, Object Type ID,
etc.)
HCoordF32 The HCoordF32 type defines X, Y, Z, W homogeneous
coordinate values. So an HCoordF32 is made up of four
F32 : Data
F32 base types.
HCoordF64 The HCoordF64 type defines X, Y, Z, W homogeneous
coordinate values. So an HCoordF64 is made up of four
F64 : Data
F64 base types
MbString The MbString type starts with an I32 that defines the
number of characters (NumChar) the string contains. The
I32 : Count
number of bytes of character data is “2 * NumChar”
(therefore the strings are written out as multi-byte
U16 : Char
Count
characters where each character is U16 size).

Mx4F32 Defines a 4-by-4 matrix of F32 values for a total of 16 F32
values. The values are stored in row major order (right
F32 : Data
most subscript, column varies fastest), that is, the first 4

elements form the first row of the matrix.
...