X3D player support for the .wav format is required, while .midi and .mp3 support are recommended.
Other audio formats are optional, you are welcome to check documentation for browsers of interest.
So far, no streaming protocol is required to be supported in X3D players.

For reliability an author can use a variety of formats at once, if desired. See
URL Links
for information how to link multiple formats/versions of an audio file.

Do not add audio files to open-source archives without proper permissions and
Credits.

X3D Schematron
provides an comprehensive form of XML validation for X3D scenes.
Authors can use X3D Schematron reports to verify semantic correctness and detect internal-consistency problems.

Actively fix any validation [Error], [Warning] and [Hint] messages in each scene.
Allowing errors and warnings to persist, even when apparently harmless, can mask further problems.
[Info] messages are informational and might not need corrective action by the author.

XML pretty-print file formatters can help make scene source more readable.
The most important and consistent is
X3D Canonicalization (C14N)
which is used prior to generating
X3D Compressed Binary (.x3db) format
or putting Web3D examples into version control.

If a scene depends on having the default value of a field for proper operation,
it is a good authoring practice to enter that default value in your original scene for emphasis.
Note, however, that some optimizers (such as
X3D Canonicalization C14N)
may remove it again.

Refer to the
X3D Standards
frequently to learn more.
The
X3D Abstract Specification
is especially important since it describes X3D functionality in complete detail.
You may also want to extract and install a
copy
on your local system.
All current X3D specifications are also bundled with X3D-Edit.

Each containerField value
is the field name from the X3D Specification that indicates a contained node's relationship to its parent node.

Addition of containerField values only occurs in the XML encoding of .x3d scenes.
For example:
<Transform><Shape containerField='children'/></Transform>
indicates that the Shape node is one of the children of the Transform node.

Default containerField values for each node are correct in most cases, so the need to override default containerField values is rare.

The containerField attribute is part of XML encoding for X3D scenes, and corresponds to the always-declared field labels in the ClassicVRML and VRML97 file encodings.

Example values include containerField='geometry' for Box node, containerField='children' for Group node, containerField='proxy' for hidden proxy shape within a Collision node, etc.

USE nodes are allowed to have a containerField value that is different than the corresponding DEF declaration of that node, since the containerField attribute describes each node's relationship with its parent.

Non-default containerField values

Disambiguation of parent-child field relationships is sometimes necessary, since
a few parent nodes have more than one child field that can accept the same node type.
In those ambiguous cases, the child node must have a correct containerField value
in order to precisely define parent-child field relationships.

Specifically, care must be taken with the following non-default child containerField values.

CADFace
can contain a single
Shape,
LOD or
Transform
node with containerField='shape'
(rather than default containerField='children').

CollidableShape
can contain a single
Shape
node with containerField='shape'
(rather than default containerField='children').

Collision
can contain a single nonrendered proxyShape
(or X3DGroupingNode)
node with containerField='proxy'
(rather than default containerField='children').

ComposedCubeMapTexture
can contain up to six X3DTexture2DNode (e.g.
ImageTexture)
nodes, each with a unique containerField value: back, bottom, front, left, right, or top
(rather than default containerField='texture').

GeoLOD
can contain multiple X3DChildNode nodes with containerField='rootNode'.
Curiously
GeoLOD
is not allowed to have child nodes with default containerField=children defined in a scene,
since that field is defined differently with accessType outputOnly and
thus is only able to send MFNode events at run time.

MetadataSet
can contain multiple other child X3DMetadataNode nodes by setting their containerField='value'
(rather than default containerField='metadata').
Similar to the other metadata nodes,
MetadataSet
can also contain a single X3DMetadataNode node describing itself (with default containerField='metadata').

Sound
can contain a single
MovieTexture
node with containerField='source'
(rather than default containerField='texture').

TextureBackground
can contain up to six X3DTexture2DNode (e.g.
ImageTexture)
nodes, each with unique containerField values: backTexture, bottomTexture, frontTexture, leftTexture, rightTexture, or topTexture
(rather than default containerField='texture').

Angular rotations are expressed in radians, using right-hand rule (RHR)
with thumb pointing along positive direction for axis of interest and the
other fingers curling in the direction of positive rotation.

Don't add scenes, images or audio files to the archive unless permission has been granted from the respective owners.
This means that there are clear and documented distribution rights attached.
This can be meta tag information, WorldInfo node at the top,
or a email/document statement by the owner duplicated locally.

Name identifiers (DEF/USE and Prototype names), sometimes referred to as
fragment identifiers,
must only use UTF-8 characters.

Note that a variety of character encodings are possible for the XML-based .x3d encoding
(reference
19776-1 paragraph 4.4.1),
while only the utf8 character encoding is allowed for the ClassicVRML .x3dv encoding.

It is important to include DEF and USE when multiple copies of an image or video file are present in a scene.
This avoids delays and reduces memory consumption that results from reloading the same file multiple times.

If the image file might be different each time it is retrieved, then DEF/USE isn't appropriate.

Portable network graphics (PNG) is the preferred image format for capturing screen images,
providing the best support for lossless compression and transparency.

Joint Photographic Experts Group (JPEG)
format is also excellent.
The preferred file extension is CoolImage.jpg.
JPEG is the best choice for photographic images since it captures color gradations exceptionally well.
Be careful to evaluate results when modifying JPEG compression quality, since it is lossy and highest image quality is often best.
Note that
JPEG does not support transparency.

X3D browsers may offer to support multiple video formats.
Since the X3D url field is an ordered list, authors can provide and link
more than one format if they wish. X3D browsers will honor the first successfully playable link
that they find.

However consistent support for other formats beyond MPEG1 is not guaranteed since
most popular video formats are highly encumbered by patents and licensing fees.
Having authors or content providers account and pay for content is antithetical to
the free growth of open standards and the World Wide Web.

If a royalty-free (RF) video format
becomes sufficiently popular and has multiple efficient open-source and commercial codec
software implementations available, then the X3D Graphics Working Group and Web3D Consortium members
will likely adopt its usage as a required format. Until then, support for any video format
other than MPEG1 remains optional for X3D.

Of related interest: the existence of the open X3D Graphics standard prevents
a similar sad state of affairs from allowing patent-holding companies from "locking up"
3D graphics on the Web. Members of the
Web3D Consortium
deserve credit for maintaining this important achievement. Feel free to join or contribute
so that such efforts can continue.

Many other
image file formats exist.
The best authoring practice is to use
GIMP
to convert the original image
into .png or .jpg format, as described above, to ensure the X3D player can display it.
It is often best to save and provide both formats so that the original highest-quality image remains available.
Example:

Use high-resolution quality (e.g. 300 dpi or better) since textured imagery is often viewed at close ranges.
Try to keep image file size under 200-300 KB, if possible.
Consider using both low-resolution and high-resolution versions as appropriate for level of detail (LOD) and Web delivery.

Inline scenes load a file containing an external scene into the current scene

DEF/USE multiple instances of duplicate Inline, image, audio and video content.
This approach is more maintainable, uses less memory and can reduce file-transfer delays.

Inlined scenes ought to be interesting enough to stand on their own.
If an Inlined scene is unlikely to be reused more than once, then
the X3D content probably ought to get incorporated in the parent scene.

Do not wrap field definitions in a ProtoInterface element since that construct is illegal.

For important prototypes, make a separate NewNodeExample.x3d scene
that provides copyable/reusable ExternProtoDeclare/ProtoInstance definitions
corresponding to each NewNodePrototype.x3d scene.
This encourages authors to avoid copying the ProtoDeclare definitions,
so that a master version remains stable and improvable.

Do not include initialization values in field definitions.
They are illegal since the defaults in the original ProtoDeclare field declarations take precedence.

Copy annotation tooltips from the corresponding ProtoDeclare annotation tooltips for each ExternProtoDeclarefield.
Listing default values used by the prototype can be helpful.

Explicitly include initialization values, even if they match default values, to ensure proper operation.
Sometimes a prototype can have different initialization values than expected, if it is modified elsewhere.

First debug proper ProtoInstance operation in the scene defining the original ProtoDeclare, rather than
using an ExternProtoDeclare.
Why - to make sure they work first!
Browser debugging can be more cryptic for externally defined prototypes
and different versions may occur in various remote url addresses, making it difficult to determine
precisely which ExternProtoDeclare is being referenced.

X3D authors can place meta statements in a scene to document what license being applied.
For example, one of the following is typically included in the X3D scenes found in the Web3D Consortium and NPS open-source example archives:

This default
open-source license
is available for X3D models and source code produced by NPS (and others)
for the various Web3D and Savage model archives.

The license is available as
license.html
and also available in plain-text form as
license.txt
for embedding in source-code files.

The terms of this non-viral
BSD open-source license
permit both commercial & non-commercial uses. The contributing authors retain original copyright as appropriate.
This license can be adapted for use by other open-source contributors, as desired.

The Open Source Initiative (OSI) lists alternate
open-source licenses
that are also acceptable for other public contributions to the Web3D Consortium's archives and resources.

There are many kinds of
polygon mesh
structures in 3D graphics. A wide variety of X3D nodes are available for representing various polygonal meshes.

3D modeling tools with 3D interfaces make it easy to create unusual and irregular geometry,
but it often remains hard to size them correctly or shape them precisely.
Use reference grids and cross-section slices to check that dimensions are accurate when creating new models.

Exporting a model mesh to X3D polygons usually means that the shape(s) can only be transformed and scaled,
with no internal animation modifications at run time. Therefore it is a good idea to split up any pieces
of geometry that need to be animated separately.

Scaling in meters is usually preferred. Using other units (feet, inches, millimeters etc.) is OK if that
preserves the original data exactly.
Simply adding a parent Transform node with uniform scaling can restore overall units to meters,
but watch out for additional scale conversions of event streams if any internal components need animation.

When maintaining models in an archive, keep both the original version and the .x3d version in case future
modifications are needed. Saving documentation, README notes about construction and metadata information is also important.

Tool-assigned DEF/USE names for nodes are also often quite obscure.
When possible, assign clear names for DEF/USE labels of top-most parts in order to make animation and inlining easier.

Many of these issues are common to the export of Computer Aided Design (CAD) models from various formats into X3D.
The
X3D CAD Working Group
is a long-standing source of resources, tools and best practices.

NURBS and other parametric surfaces are often preferable to polygonal meshes since they provide exact
representations that are concise and work at any level of detail. Nevertheless polygon meshes may be
preferable for public distribution if complex source needs to be protected. Including both types of
representations within Switch or LOD nodes is another possibility.

Applying
X3D Security
techniques can support secure distribution of sensitive portions of an X3D model (such as the high-value NURBS representation).

meta Statements

Each X3D scene can contain metadata about the document itself.
Top-level statements of interest are
X3D,
Scene,
head,
component
and
meta.

BVH references

The Biovision Hierarchy (BVH) character animation file format was developed by Biovision, a defunct motion capture services company, to give motion capture data to customers. This format largely displaced an earlier format Biovision providing skeleton hierarchy information as well as motion data.
As of 2008, BVH is widely used, however not all applications support importing and exporting files in this format.

BVH tools

bvhacker (Windows)
is an open-source tool for simple editing of bvh files.

Using clear and consistent names for node names and DEF labels greatly improves the clarity of how a scene work.
In effect, names can make the purpose of a scene self-documenting.

CamelCaseNaming: capitalize each word, never use abbreviations,
strive for clarity, and be brief but complete.

startWithLowerCaseLetter when defining field names (i.e. attributes) within Prototypes and Scripts.

Ensure consistent capitalization throughout.
Of note: the Windows operating system is not case sensitive, but http servers are.
Thus mismatched capitalization can hide target files, and
this error only is revealed when placed on a server.

Use the underscore character ("_") to indicate subscripts on mathematical variables.
Otherwise avoid use of underscores since they look like whitespace when part of a URL address.

Avoid use of hyphens ("-") since these are erroneously turned into subtraction operators when converted into class or variable names.

Avoid use of space characters, 'apostrophes' and "quotation marks" in file names since they can cause lots of problems for tools and search,
especially when going from one operating system to another.

Naming conventions can apply to .x3d files and reference files, as well as Prototype names, field names, and DEF/USE names.
Starting names similarly (e.g. NavigationWalk, NavigationFly) can help alphabetize with indexing in the pretty-print HTML documentation,
thus improving readability and searchability.

Portability is important. There are multiple requirements for characters allowed in DEF/USE names.

Most restrictive and most interoperable guidance regarding choice of characters in names:
can start with letter or underscore character, but not a number or a colon.
Can then include letters, numbers, hyphen, underscore, or period characters.
This interoperability is important so that files can be converted equivalently between encodings without validation problems.

Similarly good choices for directory and subdirectory names can help keep scene names terse.

Portability is important.
Suggestions for XML Names
in W3C XML 1.1 Recommendation
describes best practices for construction of XML names and
provides detailed character-set guidance. It also notes
Names which are nonsensical, unpronounceable, hard to read, or easily confusable with other names should not be employed.

Naming of multiple similar autogenerated files:
Concatenate the following name components as appropriate.
Separate components by period characters, since underscores disappear as part of a url and since hyphens will break across a line.

By default, the X3D International Standard uses the
International System of Units
(Système international d'unités (SI)),
the modern international standard version of the metric system.

Scaling changes within a scene are possible (and usually a good practice) in order to match the measured values of 3D objects.

For consistency in X3D scene composition, preferred scaling of length data is to use default units in meters.

If portions of a scene use units other than meters,
add a parent Transform node to uniformly scale back to meters.

X3D version 3.3
UNIT statement
provides support for scene-wide definition of alternate measurement.
Allowed category values are:
<unit/>
for angle (default radians),
length (default meters),
mass (default kilograms) and
force (default newtons).
Note that authors can use any label they choose for the name field,
since the category field provides the strict definition of how a
conversionFactor field is applied.
Example usage:

Source code can be placed in url attribute but may be unparsable due to escaping of special characters and elimination of line breaks
(causing comments to nullify follow-on code). Use contained CDATA section instead for embedding source code.

Preferred alternative to using the url field for Script nodes:
insert a CDATA section to contain embedded source code.
CDATA can protect literals like < and > from undesirable conversions by XML parsers.
Furthermore, it eliminates the need to use &lt; and &gt; escape-character replacements (which make script code nonportable).
Example:

If both url field and CDATA section are provided simultaneously, the url field is processed first.
This approach allows utilization of update modifications or live queries in external scripts, while still providing reliable script source as a fallback alternative within the model itself.
For further detail see
X3D XML Encoding, 4.3.13 Encapsulating Script node code

Use Browser.print(...) rather than a simple print(...) function
when printing to the console.
Browser.print(...) is the form supported by X3D, the unqualified
print(...) was VRML97 syntax and is now obsolete.
For backwards compatibility, X3dToVrml97.xslt will strip
the preceding Browser.class qualifier when converting scripts to VRLM97.

For toggle-able tracing in ecmascript: scripts, first add the following field interface to the Script.

Scalable Vector Graphics (SVG)
is a markup language for describing two-dimensional graphics applications and images, and a set of related graphics script interfaces.
SVG is supported by all modern browsers for desktop and mobile systems.
There are many SVG authoring tools, and export to SVG is supported by all major vector graphics authoring tools.

Use with X3D

SVG can be used together with X3D in an HTML page.

SVG can be used to export image files that can be utilized in ImageTexture nodes.

SVG has been proposed for direct use in ImageTexture nodes as part of
X3D version 4.

Tools

Amaya
is an open-source Web document editor from the World Wide Web Consortium (W3C)
supporting HTML5, stylesheets, SVG and other document formats.

Batik
is a Java-based toolkit for applications or applets that want to use images in the Scalable Vector Graphics (SVG) format for
display, generation or manipulation.

Inkscape
is a professional vector graphics editor for Windows, Mac OS X and Linux. It's free and open source.

SVG-Edit
is a fast, web-based, JavaScript-driven SVG drawing editor that works in any modern browser.

X3D url links are an ordered array of legal addresses for a given single resource.
The first retrieved address which provides a legal result is used, otherwise the retrieval fails if no links work.
The redundancy of this approach provides authors with greater portability and reliability for retrieval of content than is provided by HTML and other languages.

Include both relative and persistent (online) url links. Use relative links first, since they are most portable
and do not require unnecessary use of the network.

Special case: use online links before relative links when updated network versions are preferred.

Ensure each url link is valid. These can be easily checked manually via the pretty-print HTML version of the scene.

Usage examples follow. First is the preferred form with 'single-quoted'url attribute values:

XML validation is defined by the
Extensible Markup Language (XML) 1.0.
A number of document variations are possible for X3D scenes.
For example,
encoding information
is optional and may designate a variety of character sets.
The X3D specifications are carefully designed to be fully compatible with XML requirements.

The following sections provide detailed information on the proper file syntax for X3D DTD and XML Schema headers in an .x3d scene.
Each version matches the corresponding X3D version (3.0, 3.1, 3.2, and 3.3).
Thanks to X3D stability, each version is backwards compatible.
For example, the X3D v3.2 DTD and schema can validate X3D v3.2, v3.1, or v3.0 content, but not v3.3 content.

When offline, X3D-Edit 3.1 can only load scenes containing the proper DTD one at a time.
When disconnected from the network, click on a scene (or drag & drop the scene onto the X3D-Edit icon)
to launch it - the DOCTYPE will be converted to Transitional DTD upon launch, and restored to Final DTD upon normal exit.
Alternatively, use a different X3D/XML/text editor
or the Transitional X3D DOCTYPE/DTD with X3D-Edit.

Viewpoints are typically the most important mechanism for an author to suggest scene navigation to a user.
Recommended keyboard defaults are listed in
Annex G Recommended navigation behaviours.
In this way, new users interacting with an X3D scene can have a relatively consistent experience, regardless of which X3D player might be used.

Use clear, understandable Viewpoint description fields.
Viewpoints are a primary user tool for scene navigation, so let users know what each Viewpoint is intended to show.

Use an object's name first when many viewpoints follow, so that they are more easily identified in a viewpoint list that has many different objects in it.
Examples: "Sports car driver view", "Sports car rear view mirror", "Sports car from above", etc.

Use whitespace instead of underscores in Viewpoint (and sensor) descriptions.

The default X3D initial viewpoint is typically on +Z-axis, looking toward origin along -Z-axis.
This helps provide consistent catalog viewing since vehicles and other entities are aligned with their nose along the +X-axis.

A good second viewpoint for vehicles provides an "over-the-shoulder" view, namely behind and above the geometry.
This provides users with a good vantage point to follow the vehicle when it is animated in a scene.

Since the default body coordinate system
for an X3D scene with +Y-axis up, with the model body commonly pointed or aligned along the +X-axis,
individual entities are typically pointed to the right when seen from the default view (on the +Z-axis looking towards the origin).

Put objects in the center of a scene for default EXAMINE mode to work properly.
Alternatively, use Viewpoint centerOfRotation field to indicate local center.

Use Savage/HeadsUpDisplay/CrossHaironline prototype
to put a cross-hair overlay HUD in the center of a viewpoint.

Use ViewpointGroup (X3D v3.2)
to hide high-detail viewpoints from the viewpoint list at long ranges.
This allows better navigability when there are many objects in a single aggregate scene.

Use Savage/Tools/Authoring/AnimatedViewpointRecorderPrototypeonline prototype
to hide high-detail viewpoints from the viewpoint list at long ranges.
This allows scalability of many objects in a single scene.

Fiji and ImageJ (found under Images) support image slicing from volumes.

ITK-SNAP
SNAP is a software application used to segment structures in 3D medical images. It provides semi-automatic segmentation using active contour methods, as well as manual delineation and image navigation
Windows Macintosh Linux).