ISO/FDIS 14306-4

ISO/DISFDIS 14306-4:2025(en)
ISO/TC 184/SC 4/JWG 16
Date:2025-04-21
Secretariat: ANSI
Date: 2025-11-10
Industrial automation systems and integration –
— JT file format specification for 3D visualization – —
Part 4:
Version 3
Systèmes d'automatisation industrielle et integration -
Spécification de format de fichier JT pour visualisation 3D – Partie 4: Version 3
FDIS stage
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
EmailE-mail: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
Contents
Foreword . v
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 . 12
5 File format . 13
5.1 General . 13
5.2 Object types . 13
5.3 File structure. 13
5.4 Data segments . 26
6 LSG segment . 27
6.1 Segment overview . 27
6.2 Graph elements . 28
6.3 Node elements . 29
6.4 LSG attribute elements . 57
6.5 Property atom elements . 107
6.6 Property table . 117
7 Shape LOD segment . 120
7.1 Shape LOD segment overview . 120
8 Geometry segments . 154
8.1 Geometry segments overview . 154
8.2 STEP B-Rep segment . 154
8.3 Wireframe segment . 154
8.4 XT B-Rep element . 155
9 MetaData segment . 155
9.1 MetaData segment overview . 155
9.2 Property proxy MetaData element . 156
9.3 PMI manager MetaData element . 161
10 Info segment . 210
11 Data compression and encoding . 212
11.1 Data compression and encoding overview . 212
11.2 Common compression data collection formats . 212
11.3 Encoding algorithms . 259
11.4 LZMA compression . 269
12 Conformance requirements . 269
12.1 General conformance . 269
12.2 Conformance classes . 270
13 Common data conventions and constructs . 270
13.1 Overview . 270
iii
13.2 Late-loading data . 271
13.3 TOC segment location . 271
13.4 Bit fields . 271
13.5 Empty field . 271
13.6 Hash value . 271
13.7 Scene graph construction . 272
13.8 Metadata conventions . 272
13.9 LSG attribute accumulation semantics . 284
13.10 LSG part structure . 284
13.11 Range LOD node alternative rep selection . 285
13.12 B-Rep face group associations . 286
13.13 Smart topology table (STT) segment . 286
13.14 Watermark image . 287
13.15 State flags . 287
Annex A (normative) Information object registration . 289
Annex B (informative) Object type identifiers . 290
Annex C (informative) Coding algorithms – An implementation . 293
Annex D (informative) Hashing – An Implementation . 330
Annex E (informative) Polygon mesh topology coder . 335
Annex F (informative) Per face group attributes . 364
Annex G (normative) STEP B-Rep . 369
Annex H (normative) STEP schema . 372
Annex I (informative) XT B-Rep data segment . 461
Annex J (informative) Smart topology table (STT) segment . 585
Annex K (normative) Wireframe segment . 624
Annex L (informative) Mapping table 14306-4 XT B-Rep to STEP . 628
Annex M (informative) Procedural geometry – Evaluation and approximation . 635
Annex N (normative) Information Object Registration Scheme . 682
Annex O (informative) Change history . 684
Bibliography . 687

iv
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 documents 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.
This first edition of ISO 14306-4, together with ISO 14306-1, ISO 14306-2, ISO 14306-3, cancels and replaces
the second edition ISO 14306:2017, which has been technically revised.
The main changes are as follows:
— this document defines the requirements based upon the JT 10.5 file format requirements,
whereas ISO 14306:2017 defines the requirements based upon the JT 9.5 file format requirements. A detailed
list of the changes are shown in Annex O;
— — the version string in the File Header has been updated to reflect ISO 14306-4 Version 3.
— — the file compression format has changed from Z-Lib to the publicly available LZMA format;
— — the technical description for MbStrings Composite Data Types has been updated to include UTF 16;
— — new segment types have been added for Smart Topology Table (STT) and Info Segment;
— — the Base Attribute Data description has been expanded to include the logical collection Base Attribute
Data Fields V2;
— — a new attribute element has been added to the LSG definition, Palette Map Attribute Element.
v
— — a new attribute element, “Sabot Attribute Element”, has been added to the LSG definition. Sabot is used
to insulate earlier readers from attributes with non-fallback palette Index attributes in order to preserve
forward compatibility;
— — new PMI Association values have been included to support partial scene sectioning;
— — a complete description of all PMI String Property Atom Element values is made available as a Reference
Data Library in electronic format;
— — generic PMI Entity Type values have a new value; 0x0309 Weld Note Type;
— — an Annex F (Per Face Group Attributes) has been added;
— — two new PMI Associations Reason Code values have been added, code 256 and code 257.
— — Annex I is related to the XT BREP geometry definition. The following changes have been made in
Annex I.1.1.1.5
Updates in the “Topology” description.
Updates in the “World Topologies” table.
Updates to the “Body fields” table.
Updates to the “Region fields” table.
— this document defines the requirements based upon the JT 10.5 file format requirements, whereas ISO
14306:2017 defines the requirements based upon the JT 9.5 file format requirements. A detailed list of
the changes are shown in Annex O;
— the version string in the File Header has been updated to reflect ISO 14306-4 Version 3;
— the file compression format has changed from Z-Lib to the publicly available LZMA format;
— the technical description for MbStrings Composite Data Types has been updated to include UTF 16;
— new segment types have been added for Smart Topology Table (STT) and Info Segment;
— the Base Attribute Data description has been expanded to include the logical collection Base Attribute
Data Fields V2;
— a new attribute element has been added to the LSG definition, Palette Map Attribute Element;
— a new attribute element, “Sabot Attribute Element”, has been added to the LSG definition. Sabot is used
to insulate earlier readers from attributes with non-fallback palette Index attributes in order to
preserve forward compatibility;
— new PMI Association values have been included to support partial scene sectioning;
— a complete description of all PMI String Property Atom Element values is made available as a Reference
Data Library in electronic format;
— generic PMI Entity Type values have a new value; 0x0309 Weld Note Type;
— an Annex F (Per Face Group Attributes) has been added;
— two new PMI Associations Reason Code values have been added, code 256 and code 257;
— Annex I is related to the XT BREP geometry definition. The following changes have been made in
I.1.1.1.5
Updates in the “Topology” description.
Updates in the “World Topologies” table.
Updates to the “Body fields” table.
vi
Updates to the “Region fields” table.
A list of all parts in the ISO 14306 series can be found on the ISO website.
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;
— — 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);
— — 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;
— — occlusion culling and fixed-framerate display modes;
— — layers, and layer filters.
NOTE This document is based on the JT Open version 10.5 specification, which defines a logical scene graph with
geometry specific node and attribute support, extended to support the ISO 10303 series.
Annex AAnnex A contains an identifier that conforms to ISO/IEC 8824-1. The identifier unambiguously
identifies this document in an open information system.
Annex AAnnex 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 in Annex NAnnex N.
viii
DRAFT International Standard ISO/DIS 14306-4:2024(en)

Industrial automation systems and integration – — JT file format
specification for 3D visualization- —
Part 4:
Version 3
1 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 ISO 14306 file format specification for 3D visualization includes data descriptions that can represent the
following data:
— — facet information (triangles), stored with geometry compression techniques;
— — visual attributes such as lights, textures and materials;
— — product manufacturing information (PMI);
— — boundary representation (b-rep) solid model shape representation and associated metadata;
— — configuration representations; and
— — delivery methods such as asynchronous streaming of content.
The file format specification for 3D visualization does not specify the implementation of, or definition of a run-
time architecture for viewing and/or processing ISO 14306 data.
2 2 Normative references
ISO 10303--21:2016, Industrial automation systems and integration — Product data representation and
exchange — Part 21: Implementation methods: Clear text encoding of the exchange structure
ISO 10303--42:2024, Industrial automation systems and integration –— Product data representation and
exchange –— Part 42: Integrated generic resource: geometricGeometric and topological representation
ISO 14306--2:2024, Industrial automation systems and integration — JT file format specification for 3D
visualization — Part 2: Vocabulary
Reference Data Library - https://standards.iso.org/iso/14306/-4/ed-
1/en/ISO14306_PMIPropertiesStrings.xlsx (electronic insert).
Reference Data Library – https://standards.iso.org/iso/14306/-4/ed-
1/en/ISO14306_MaterialSurfaceProperties.xlsx (electronic insert).
3 3 Terms, definitions and abbreviated terms
3.1 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/obp3.2
— 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 Valueabsolute value
Bbox Bounding Boxbounding box
B-Rep Boundary Representationboundary representation
CAD Computer Aided Designcomputer aided design
CODEC Coder-Decodercoder-decoder
GD&T Geometric Dimensioninggeometric dimensioning and Tolerancingtolerancing
GUID Globally Unique Identifierglobally unique identifier
HSV Hue, Saturation, Valuehue, saturation, value
LCS local coordinate system
LsbFirst Least Significant Byte Firstleast significant byte first
LZMA Lempel–Ziv–Markov
Max Maximummaximum
MCS machine coordinate system
Min Minimumminimum
MsbFirst Most Significant Byte Firstmost significant byte first
N/A Not Applicablenot applicable
PCS Parameter Coordinate Spaceparameter coordinate space
PLM Product Lifecycle Managementproduct lifecycle management
RGB Red, Green, Bluered, green, blue
ISO/DISFDIS 14306-4:20242025(en)
RGBA Red, Green, Blue, Alphared, green, blue, alpha
TOC Tabletable of Contentscontents
VPCS Viewpoint Coordinate Systemviewpoint coordinate system
URL Uniform Resource Locatoruniform resource locator
WCS world coordinate system
4 4 Notational conventions
4.1 4.1 Diagrams and field descriptions
Symbolic diagrams are used to describe the structure of the ISO 14306 file. The symbols used in these
diagrams are shown in Table 1Table 1 and 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” (therefore, 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.23.2 Data Types. data types.
In the example shown in Figure 1Figure 1 the Data_Type is “I32” (a signed 32 bit integer) and Field_Name is
“Count.”
Figure 1 — rectangle — Rectangle box diagram
Diagram “folder” (therefore, logical data collections) symbols are simply titled with a collection name. In the
example shown in Figure 2Figure 2 the collection name is “Graph Elements.”

Figure 2 — folder — 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 3Figure 3 the logic step name is “Recover First Shell Indices”.

Figure 3 — rectangle — Rectangle box with lines at left and right sides diagram
Diagram “rectangle box with clipped right side corners” (therefore, compressed/encoded data fields) are
titled using one of the following three formats:
Data Typetype; followed by open brace “{“,“{”, number of bits used to store value, closed brace “}”, and a colon
“:”; followed by the Field Namefield 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 4Figure 4 the Data Typedata
type is “U32”, “6” bits are used to store the value, and Field Namefield name is “Count”

Figure 4 — rectangle — Rectangle box with clipped right-side corners
Data Typetype followed by open brace “{“,“{”, compressed data packet type, “,”, Predictor Typepredictor 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 (therefore, 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 – Thethe Int32CDP (therefore, Int32 Compressed Data Packetcompressed data packet) represents
a third-generation format used to encode/compress a collection of data into a series of Int32 based symbols.
This version of the Int32CDP supersedes the two similarly-named ones from the ISO 14306 Edition 2
ISO/DISFDIS 14306-4:20242025(en)
Specification,:2017 and should not be confused with either of its predecessors. A complete description for
Int32 Compressed Data Packetcompressed data packet can be found in 11.2.2Int32 Compressed Data Packet.
The Int32 Compressed Data Packetcompressed data packet type is used for compressing/encoding both
“integer” and “float” (through quantization) data.
In the example shown in Figure 5Figure 5 the Data Typedata type is “VecU32”, Int32 Compressed Data Packet
compressed data packet type is used, Lag1 Predictor Typepredictor type is used, and Field Namefield name is
“First Shell Index.”
Figure 5 — compressed — Compressed data packet diagram
As mentioned above (with Predictor Typepredictor-type algorithm), the primal input data values are NOTnot
always what is encoded/compressed. This is because the primal input data is first run through a Predictor
Typepredictor-type algorithm, which produces an output array of residual values (therefore, the difference
from the predicted value), and this resulting output array of residual values is the data which is actually
encoded/compressed. This document format supports several Predictor Typepredictor-type algorithms and
each use of Int32CDP specifies, using the notation format described above, what Predictor Typepredicto-type
algorithm is being used on the data. The supported Predictor Typepredictor type algorithms are as shown in
Table 2Table 2 (note that (a sample implementation of decoding the predictor residual values back into the
primal values can be found in Annex CAnnex C).).
Table 2 — Predictor Typetype
Predictor Description
Typetype
Lag1 Predicts as last value
Xor1 PredictPredicts as last, but useuses XOR instead of subtract to
compute residual
NULL No prediction is applied
Each predictor type 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.
The format “Data Type : Field Name” . This formatused 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
Typesdata types and usually representrepresents a vector/array of data. How the data is compressed and
encoded into the Data Typedata type is indicated by a CODEC type and other information stored before the
particular data in the file. In the example shown in Figure 6Figure 6 the Data_Type is “VecU32” and Field_Name
is “CodeText.”
Figure 6 — data type — Data_Type: field name diagram
Note that forFor some file Segment Typessegment types there is LZMA compression also applied to all bytes
of element data stored in the segment. This LZMA 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 Elementelement in the file segment to determine if LZMA
compression is applied to all data in the segment. A complete description of the format data compression and
encoding can be found in 5.4 and Clause 11Data Segment and Data Compression and Encoding.
Following eachEach data collection diagram isincludes 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 shall be set to “0”.
For folders (therefore, 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 7Figure 7,, shows data field A followed by (depending on value of A) either data field B, C, or
D.
ISO/DISFDIS 14306-4:20242025(en)

Figure 7 — data — 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 looks as shown in
Figure 8Figure 8::
Figure 8 — loop — 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 looks as shown in Figure 9Figure 9 (data field D is repeated C value
times).
Figure 9 — loop — Loop construct with iterations example
4.2 4.2 Data Typestypes
The data types that can occur in the binary files are listed in the following two tables.
Table 3The Basic Data Types table, shown in Table 3, lists the basic/standard data types which can occur.
Table 3 — Basic Data Typesdata 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 4Table 4 — Composite Data Types, as shown in Table 4, lists some composite data types which are used
to represent some frequently occurring groupings of the basic data types (for example Vector, vector, RGBA
colour). The composite data types are defined in this reference simply for convenience/brevity in describing
the file contents.
ISO/DISFDIS 14306-4:20242025(en)
Table 4 — Composite Data Typesdata types
Type Description Symbolic Diagramdiagram
BBoxF32 The BBoxF32 type defines a bounding box using two CoordF32
types to store the XYZ coordinates for the bounding box minimum
and maximum corner points.
CoordF32 The CoordF32 type defines X, Y, Z coordinate values. So aA
CoordF32 is made up of three F32 base types.

DirF32 The DirF32 type defines X, Y, Z components of a direction vector.
So aA DirF32 is made up of three F32 base types.

GUID The GUID type is a 16 byte (128-bit) number. GUID is
stored/written to the ISO 14306 file using a four-byte word (U32),
2 two-byte words (U16), and 8 one-byte words (U8) such as:

{3F2504E0-4F89-11D3-9A-0C-03-05-E8-2C-33-01}

In the ISO 14306 format, GUIDs are used as unique identifiers (for
example Data Segment, data segment ID, Object Typeobject type
ID, etc.)).
Type Description Symbolic Diagramdiagram
MbString The MbString type starts with an I32 that defines the number of
characters (NumChar) the string contains. The number of bytes of
character data is “2 * NumChar” (therefore, the strings are written
out as multi-byte characters where each character is UTF16 size).

Mx4F32 DefinesThe Mx4F32 type 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 most subscript, column varies fastest), that is, the first 4four
elements form the first row of the matrix.

Mx4F64 DefinesThe Mx4F64 type defines a 4-by-4 matrix of F64 values for
a total of 16 F64 values. The values are stored in row major order
(right most subscript, column varies fastest), that is, the first 4four
elements form the first row of the matrix.

PlaneF32 The PlaneF32 type defines a geometric Planeplane using the
General Formgeneral form of the plane equationformula (Ax + By +
Cz + D = 0). The PlaneF32 type is made up of four F32 base types
where the first three F32 define the plane unit normal vector (A, B,
C) and the last F32 defines the negated perpendicular distance (D),
along normal vector, from the origin to the plane.

Quaternion The Quaternion type defines a 3-dimensional orientation (no
translation) in quaternion linear combination form (a + bi + cj +
dk) where the four scalar values (a, b, c, d) are associated with the
4four dimensions of a quaternion (1one real dimension, and 3three
imaginary dimensions). So theThe Quaternion type is made up of
four F32 base types.
RGB The RGB type defines a colour composed of Red, Green, Bluered,
green, blue components, each of which is a F32. So aAn RGB type is
made up of three F32 base types. The Red, Green, Bluered, green,
blue colour values typically range from 0.0 to 1.0.

ISO/DISFDIS 14306-4:20242025(en)
Type Description Symbolic Diagramdiagram
RGBA The RGBA type defines a colour composed of Red, Green, Blue,
Alphared, green, blue, alpha components, each of which is a F32. So
aAn RGBA type is made up of four F32 base types. The Red, Green,
Bluered, green, blue colour values typically range from 0.0 to 1.0.
The Alphaalpha value ranges from 0.0 to 1.0 where 1.0 indicates
completely opaque.
String The String type starts with an I32 that defines the number of
characters (NumChar) the string contains. The number of bytes of
character data is “NumChar” (therefore, the strings are written out
as single-byte characters where each character is U8 size).

VecF32 The VecF32 type defines a vector/array of F32 base type. The type
starts with an I32 that defines the count of following F32 base type
data. So aA VecF32 is made up of one I32 followed by that number
of F32. Note that itIt is valid for the I32 count number to be equal
to “0”, indicating no following F32.

VecF64 The VecF64 type defines a vector/array of F64 base type. The type
starts with an I32 that defines the count of following F64 base type
data. So aA VecF64 is made up of one I32 followed by that number
of F64. Note that itIt is valid for the I32 count number to be equal
to “0”, indicating no following F64.

Type Description Symbolic Diagramdiagram
VecI16 The VecI16 type defines a vector/array of I16 base type. The type
starts with an I32 that defines the count of following I16 base type
data. So aA VecI16 is made up of one I32 followed by that number
of I16. Note that itIt is valid for the I32 count number to be equal to
“0”, indicating no following I16.

VecU16 The VecU16 type defines a vector/array of U16 base type. The type
starts with an I32 that defines the count of following U16 base type
data. So aA VecU16 is made up of one I32 followed by that number
of U16. Note that itIt is valid for the I32 count number to be equal
to “0”, indicating no following U16.

VecI32 The VecI32 type defines a vector/array of I32 base type. The type
starts with an I32 that defines the count of following I32 base type
data. So aA VecI32 is made up of one I32 followed by that number
of I32. Note that itIt is valid for the I32 count number to be equal to
“0”, indicating no following I32.

VecU32 The VecU32 type defines a vector/array of U32 base type. The type
starts with an I32 that defines the count of following U32 base type
data. So aA VecU32 is made up of one I32 followed by that number
of U32. Note that itIt is valid for the I32 count number to be equal
to “0”, indicating no following U32.

4.3 4.3 Empty field
When writing aan ISO 14306 file whose data did not originate from reading a previous ISO 14306 file, an
empty field shall be set to a value of “0”.
ISO/DISFDIS 14306-4:20242025(en)
When writing aan ISO 14306 file whose data originated from reading a previous ISO 14306 file (therefore,
rewriting aan ISO 14306 file), empty fields should be written with the same value that was read from the
originating ISO 14306 file.
Refer to Empty Field guidelines in the Common Data Conventions and Constructs section
5 5 File Formatformat
5.1 5.1 General
This document shall be unambiguously identified in an open information system by the code defined in
Annex AAnnex A.
5.2 5.2 Object Typestypes
All objects represented in the format are assigned an “object identifier” (for example, see Base Node Database
node data, or Base Attribute Data Base Attribute Database attribute data base attribute data) and all references
from one object to another object are represented in the format using the referenced object’s “object
identifier”. It is the responsibility of format readers/writers to maintain the integrity of these object references
by doing appropriate pointer unswizzling/swizzling as data is read into memory or written out to disk. Where
“pointer swizzling” refers to the process of converting references bas
...