Extensible 3D (X3D) encodings
Part 3: Binary encoding
4 Concepts
This clause describes key concepts in this part of ISO/IEC 19776. This includes how the X3D constructs defined in ISO/IEC 19775-1 are encoded as a binary file.
Table 4.1 lists the topics is this clause.
Table 4.1 — Topics in this clause
This X3D encoding provides a compact transmission format that minimizes delivery size and maximizes parsing speed. Privacy and ownership protections are optionally provided using XML Security mechanisms. Size, parsing and security capabilities are typically superior to that provided by simple gzip compression alone.
There is an essential one-to-one match between the nodes and fields of the abstract X3D scene graph and corresponding constructs in the binary encoding. This section describes the design patterns that govern the correspondence.
Part 1 of ISO/IEC 24824 specifies the technique used to encode a binary stream representing an X3D scene graph. This technique has the name of Fast-InfoSet. Conceptually, a slightly modified X3D XML-encoded document is fed to a Fast-InfoSet processor to write the binary stream. Implementations are not required to follow this conceptual model.
The following compression steps are provided for the X3D compressed binary encoding. The actual processing order and methods of accomplishment may vary between applications. An implementation may skip any step so long as the resultant binary file is the same as if these steps were followed.
An X3D file is structured as specified in ISO/IEC 19775-1.
Conceptually, the X3D scene input to the Fast-InfoSet encoder is an XML-encoded document with certain restrictions. X3D Canonical Form eliminates file ambiguities that have no impact on the 3D content but which otherwise would negatively impact security issues, compression or parsing performance.
The following X3D canonicalization restrictions are applied to an X3D scene (or scene fragment) prior to encryption, signature or compression:
<NavigationInfo type='"WALK" "EXAMINE" "ANY"'/>
′
character entity."
character entity (and escaped by a leading backslash \ character).Default or substitute
Document Type Definition (DTD) as specified in
Part 1 of ISO/IEC 19776
is included following the
<?xml version="1.0" encoding="UTF-8"?>
header in canonical form.
NOTE The default DTD is not included in the final binary encoding, only substitute DTD values are compressed.
Default or substitute
X3D Amendment 1 Schema
attributes included in the root <X3D>
element.
NOTE The default X3D Schema attributes are not included in the final binary encoding, only substitute X3D Schema attributes are compressed.
2.004e3
(equal to 2004.0).DEF
, USE
and (non-default) containerField
must appear before other attributes, which then follow in alphabetic order.
This ordering typically provides higher parsing performance during subsequent decoding.
This step supercedes the
XML canonicalization
rule that all attribute values are provided in alphabetic order.
All MFNode content for a child field shall be provided in a contiguous block with no intermixed containerField usage.
EXAMPLE the following code exhibits X3D not in this form:
<Collision> <Shape containerField="children" /> <Shape containerField="proxy" /> <Shape containerField="children" /> </Collision>
The canonical form would be:
<Collision> <Shape containerField="proxy" /> <Shape containerField="children" /> <Shape containerField="children" /> </Collision>
EXAMPLE Example headers:
Other XML header elements like the DTD or schema definition are encoded using standard Fast-InfoSet mechanisms.<?xml encoding='finf'?>'11100000000000000000000000000000000'
<?xml version='1.0' encoding='finf' standalone='yes'?>'11100000000000000000000000000000000'
Three additional fields are appended to the X3D tag to denote X3D binary version information. These attributes are:
EXAMPLE
<X3D binaryVersion="3.1"
serializerVersion="FastInfoSet 2004"
geometricCompressionVersion="Java3D 2004"
>
</X3D>SFString
SFString
SFString[initializeOnly]
[initializeOnly]
[initializeOnly]
All Prototype-related elements are treated in a manner consistent with the representations of the X3D XML encoding. Thus, Prototype instances are treated as PrototypeInstance constructions in XML.
EXAMPLE
<ProtoDeclare name="ExampleSensor"> <ProtoInterface> <field accessType="initializeOnly" name="enabled" type="SFBool" value="true"/> </ProtoInterface> <ProtoBody> <TouchSensor description="touch to activate"> <IS> <connect nodeField="enabled" protoField="enabled"/> </IS> </TouchSensor> </ProtoBody> </ProtoDeclare> <ProtoInstance name="ExampleSensor"> <fieldValue name="enabled" value="false"/> </ProtoInstance>
The following "native-tag" representations is not legal and shall not be used within the compressed binary encoding:
<ExampleSensor enabled="false"/>
Specific compression techniques for individual nodes is described in 6 Encoding of Nodes
These techniques will override all field specific rules. The compressor is responsible for encoding all data needed to reconstitute the node. A node compressor must retain all scenegraph structure and DEF/USE relationships.Further type-specific field compression is specified in 5 Encoding of fields.
EXAMPLE 1 Encryption of an IndexedFaceSet:
<?xml version='1.0'?> <X3D> <Scene> <Shape> <IndexedFaceSet> <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#' Type='http://www.w3.org/2001/04/xmlenc#Content'> <CipherData> <CipherValue>A23B45C56</CipherValue> </CipherData> </EncryptedData> </IndexedFaceSet> </Shape> </Scene> </X3D>
EXAMPLE 2 Encrpytion of a whole document:
<?xml version='1.0'?> <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#' MimeType='text/xml'> <CipherData> <CipherValue>A23B45C56</CipherValue> </CipherData> </EncryptedData>
This part of ISO/IEC 19776 uses Fast-InfoSet to serialize and compress an X3D document. It uses several techniques that reduce the size of an X3D document and that increase the speed of creating and processing such documents. These techniques are based on the use of vocabulary tables that allow small (typically) integer values (vocabulary table indexes) to be used instead of character strings (for example, character strings that form the names of nodes or fields in an X3D document).
A further important optimization uses the encoding algorithm vocabulary table. This table identifies specialized encodings that can be employed for commonly occurring strings, again with a number of built-in algorithms. For example, if there is a string which looks like the decimal representation of an integer in the range -32768 to 32767, that string can be encoded by identifying that this vocabulary table is being used, giving the vocabulary table index, and then encoding the integer as a two-octet signed integer. Floating-point numbers and arrays of such numbers are supported in the same way. This part of ISO/IEC 19776 defines several unique encoders for X3D that utilize type-aware knowledge to further compress data. Further details are specified in 5 Encoding of fields.
An optional final step is gzip compression of the entire compressed scene. This step supports global compression, while the other compression techniques described in this part of ISO/IEC 19776 tend to be localized to individual chunks of data.
NOTE gzip compression of compressed binary encoded scenes may have a negative impact on parser processing performance during decompression.
Binary compressed X3D encoded files shall use the file extension “.x3db”. The MIME-type associated with that binary compressed X3D encoded file is “model/x3d+binary”.
Binary compressed X3D encoded files that have been “gzipped” shall use a file extension of “.x3db.gz”. The MIME type is “model/x3d+binary”. The content-encoding value is “gzip”.
The concept of MIME types is defined in 2.[MIME].