X3D Scene Authoring Hints

These hints provide a collection of style guidelines, authoring tips and best practices to improve the quality, consistency and maintainability of Extensible 3D (X3D) Graphics scenes.

Audio | Authoring | Color | containerField | Coordinate Systems | Credits | Dates | Encodings | HTML | Images and Videos | Inlines and Prototypes | License | Meshes | meta Tags and Metadata Nodes | Naming Conventions | Scale Factors | Scripts (Java, JavaScript, JSON) | SVG | Tooltips | URL Links | Validation | Viewpoints and Navigation | Volumes | X3D-Edit | X3D for Web Authors | X3D Resources | Contact

Audio and Sound Tools

• Tool recommendations:
  • Audacity is an excellent open-source audio editing and recording tool (Windows Macintosh Linux).
  • MuseScore is an excellent open-source music-score editing and recording tool that can produce .midi and .wav files (Windows Macintosh Linux).
  • Video tools can typically play audio files.
• 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.
• Further resources:
  • X3D Graphics specification Sound component.
  • X3D for Web Authors online course: Chapter 12 - Environment Sensor Sound, examples, slideset and video.

Authoring Practices

• Establishing a habit of following best practices for scene authoring can greatly increase your ability to create, debug and maintain high-quality X3D scenes.
• Validate, validate, validate! Detecting errors is extremely important: an undetected error is the worst error because it is only blocks end users instead of being discovered by the author.
• The five levels of X3D validation checking available include XML well-formedness checking, XML DOCTYPE (DTD) checking, XML Schema checking, X3D-to-VRML stylesheet conversions, and X3D Schematron rules.
• 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.
• Look in the X3D Tooltips (online) for questions about node and field usage. These are embedded in X3D-Edit popups, and are also available separately in Chinese, English, French, German, Italian, Korean, Portuguese, Spanish and Thai.
• 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.

Color

• Color Calculator by Fraunhofer IGD
• Exporting to VRML and X3D for color printing by Shapeways
• X3D Example Archives: X3D for Web Authors, Chapter 07 - Event Animation Interpolation, Color Interpolator example
• X3D Example Archives: Savage, Tools, Animation, Color Sequencer prototype and example scene
• CSS Color Names by Douglas Crockford
• InfoHound Color Schemer by Jonathan Hedley
• Paletton Color Scheme Designer
• COLOURlovers: Color Trends + Palettes
• 4096 Color Wheel by Jemima Pereira

Material

• Pellucid is a Java applet that simulates the VRML/X3D illumination model given a default view of a sphere, a default directional light with direction [ -1 -1 -1 ], and a default material.
  • example Pellucid screenshot).
  • Caveat: to run the applet, you may need to add this site to your Java Control Panel Security Exception Site List (documentation).
• The Basic X3D Example Archives includes Universal Media Materials, a large suite of color-coordinated X3D/VRML Materials for easy usage by authors.

containerField

For the .x3d XML encoding of scenes, containerField is the field-label prefix indicating this node's field relationship to its parent node, for example <Transform><Shape containerField='children'/></Transform>.

• Default containerField values for each node are correct in most cases, so the need to override default containerField values is rare.
• Example values include containerField='geometry' for Box node, containerField='children' for Group node, containerField='proxy' for hidden proxy shape within a Collision node, etc.
• 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.

Coordinate Systems

• Each Transform node can create a new relative coordinate system for all children nodes in the scene graph.
  • Each set of axes follows the right-hand rule (RHR) for coordinate systems.
• 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.
  • Each set of orientations follows the right-hand rule (RHR) for angle rotations.
• Local/world coordinate systems: +X-axis is nose/East, +Y-axis is vertical/up, +Z-axis is right-hand side (RHS)/South.
• Entities (planes, trains, automobiles etc.) also must follow these coordinate system conventions. Consistent orientation allows models to be composed and animated together in combined scenes. Example scene: ModelOrientation.x3d (.wrl) (.html) (image)
• Coordinate-system example scene: CoordinateAxesNSEW.x3d (.wrl) (.html) (image)
• Coordinate-system gimbals, including DIS axis conversions: Gimbals.x3d (.wrl) (.html) (image)
• Position the default center of ground vehicles so that the bottom touches the ground. That way the entity can be properly animated by a parent Transform.
• Position the default center of airborne, space and underwater entities in the centroid (geometric center) or Center of Gravity (Cg) (for physics-based models).
  • Structured X3D metadata can record Center of Gravity (Cg) or Center of Buoyancy (Cb) information within a model. Such information can be read by simulation applications at run time.
  • Further information about this technique can be found in the NPS Savage Modeling and Analysis Language (SMAL) documentation, with corresponding example metadata templates.

Credits

• Ensure that all contributors to your content receive proper credit.
• The X3D for Web Authors, X3D for Advanced Modeling, VRML 2.0 Sourcebook, X3D ConformanceNist Suite, Basic X3D Examples, and Savage model archives are free for duplication and further use. Each model document gives appropriate credit to scene authors.
• 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.

Dates

• Use meta tags to note the dates when a scene is created and revised:

  <meta name='created' content='1 October 2003'/>
  <meta name='revised' content='18 June 2015'/>

• Use full 4-digit numbers for years, e.g. 2014.
• For consistency, readability, disambiguation and program parsability, please use the date format 4 July 2014 (rather than other forms such as July 4, 2014, 7/4/14, or 4/7/2014).
• Leading zeroes on dates are not usually used but are OK. They are sometimes helpful as part of filenames or tokens to ensure proper alphabetization of lists.

Encodings

• X3D MIME Media Types are approved two-part identifiers for X3D file formats on the Internet: x3d+xml, x3d-vrml and x3d+fastinfoset.
• 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.
• The Unicode FAQ UTF-8, UTF-16, UTF-32 & BOM contains further information.

HTML

HTML is the publishing language of the World Wide Web. HTML web pages can embed or launch X3D scenes.

• Tool recommendations:
  • Amaya is an open-source Web document editor from the World Wide Web Consortium (W3C) supporting HTML5, stylesheets, SVG and other document formats.
  • Netbeans and X3D-Edit are open-source integrated development environments (IDE) supporting HTML5, stylesheets, X3D and other source formats.
• HTML Object Tag for X3D shows how to place X3D objects within an HTML page, and newHtmlPageWithX3dObject.html is an example HTML scene with X3D object tag to copy, edit and reuse.
• Ensure HTML content is valid.
  • W3C Markup Validator Service and Nu Html Checker
  • HTML Tidy
  • WDG HTML Validator
  • HTML-Kit
• Want to learn more about HTML? Many books and online tutorials are available. Recommended: the following online lessons by Dave Raggett.
  • Introduction to HTML
  • More advanced HTML features
  • Adding a touch of style
• Character entity references in HTML defines encoding values for special characters in XML/HTML files. Additional resources:
  • Character Entity Reference Chart
  • List of XML and HTML character entity references
  • XML Entity Definitions for Characters (2nd Edition)
  • Stylized/curly quotation marks: David Baron's Quotation Marks in HTML examples, and David A. Wheeler's Curling Quotes in HTML, SGML, and XML essay.
• Internationalization (I18N) and Localization (L10N) requirement: when HTML pages include foreign-language characters, declare that the content is UTF-8. Example:

  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>

• Looking ahead: the X3D and HTML5 effort is working to ensure the best possible integration of X3D with HTML.
• Additional references:
  • HyperText Markup Language (HTML) Home Page
  • XHTML 1.0
  • HTML 4.01
  • Web Design Group's FAQ Archives
  • Recommended List of DOCTYPE Declarations (W3C QA) and Choosing a DOCTYPE (WDG Web Design Group)
  • Google HTML/CSS Style Guide (WDG Web Design Group)

Images and Videos

• Tool recommendations:
  • An excellent open-source image editor for scaling, resizing, clipping, reformatting etc. is the GNU Image Manipulation Program (GIMP).
  • Additional open-source image-modification tools of interest include Fiji (which extends ImageJ) and ImageMagick Image Converter (screenshot).
  • VLC is a free open-source cross-platform multimedia player that plays most multimedia files.
  • Audio tools can typically play soundtracks from video files.
• Follow Naming Conventions for image and video file names: no abbreviations, CamelCaseNaming, no embedded whitespace or underscore characters, etc.
  • Don't arbitrarily rename images provided from other sources.
  • Starting with the same name as the scene of interest helps directory alphabetization.
  • Ensure that filename extensions are lower case (e.g. CoolImage.png vice CoolImage.PNG).
• 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.
• Quality assurance (QA) image validator: W3C Online Image Info service
• Choice of image file formats:
  • 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.
  • Tagged Image File Format (TIFF) is a high-quality format for images, photographs and line art. However it is proprietary and not always supported.
  • Avoid using Graphics Interchange Format (GIF) if possible. It is technically inferior, larger size, and has licensing encumbrances. Rationale: PNG versus GIF considerations.
• Integrating textures. Exporting to VRML and X3D for color printing PixelTexture image-conversion import can embed an image directly inside a single X3D scene file by converting it into an SFImage array within a PixelTexture node.
• Choice of video file formats:
  • X3D browser support for the MPEG1 video file format format is required by the MovieTexture node definition in the X3D Specification.
  • 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:
  

  <ImageTexture DEF='grid'
      url='"OahuGrid.png"
           "https://savage.nps.edu/Savage/Locations/Hawaii/OahuGrid.png"
           "OahuGrid.rgba"
           "https://savage.nps.edu/Savage/Locations/Hawaii/OahuGrid.rgba"'/>

• 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.
• An image file can be embedded inside an X3D scene by converting it into a PixelTexture node. These will take up more size (often by a factor of 10), but nevertheless do compress well and do not require a separate file fetch over the network. A PixelTexture image import feature is provided by X3D-Edit. For an example conversion program, see PixelTextureGenerator.java which was used to create PixelTextureNavyJackDontTreadOnMe.x3d in the Savage/Tools/Authoring collection.
• Do not add images or videos to open-source archives without proper permissions and Credits.
• Use the W3C Image Info Service to check the properties of your online image.
• Further resources:
  • X3D Graphics specification Texturing component.
  • X3D for Web Authors online course: Chapter 05 - Appearance Material Textures, examples, slideset and video.

Inline Scenes and Prototype Templates

• 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.
  • Provide well-formed urls for reliability.
  • Ensure that named IMPORT/EXPORT connections match.
  • Inline tooltips and X3D specification describe functionality in detail.
  • Experimental: annotate Inline node with profile to assist in overall scene validation. Example:

    <Inline url='"string array values"'> <MetadataString name='profile' value='Immersive'/> </Inline>

• Prototype Declarations define a template for a new node
  • Follow Naming Conventions for node and field definitions.
  • Provide useful/safe default initialization values for each field, rather than depending on default field values internal to the ProtoBody.
  • Include annotation tooltips for each field.
  • Avoid copying ProtoDeclare definitions into additional scenes, instead copy ExternProtoDeclare/ProtoInstance definitions.
  • Tooltips for ProtoDeclare, ProtoInterface and ProtoBody
  • Avoid duplicate DEF names for nodes inside multiple prototype declarations contained in a single file. Although the DEF namespaces contained inside each independent ProtoBody declaration are logically independent from an X3D perspective, duplicate DEF names will provoke XML validation errors regarding duplicate ID names.
  • X3D Specification clause: Prototype Semantics
  
  
• External Prototype Declarations refer to prototypes declared in another file
  • 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 ExternProtoDeclare field. Listing default values used by the prototype can be helpful.
  • ExternProtoDeclare tooltips and X3D specification
  
  
• Prototype Instances create example node instances using the declared prototype template
  • 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.
  • Remember to include proper containerField attribute, identifying parent-node field name for this ProtoInstance. Default value: children. Example values: color, coord, geometry, fontStyle, proxy, sound, texture, textureTransform.
  • 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.
  • ProtoInstance tooltips and X3D XML Encoding specification

License

• X3D authors can place a meta tags 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:

  <meta name="license" content="../../license.html">

  <meta name="license" content="http://www.web3d.org/x3d/content/examples/license.html">

  <meta name="license" content="https://savage.nps.edu/Savage/license.html">

• 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.
• Book: Understanding Open Source and Free Software Licensing by Andrew M. St. Laurent, O'Reilly Media, Sebastopol California, 2004. Also available online.
• Creative Commons is another important resource for crafting appropriate licenses.
• The Savage Developers Guide includes further references of value regarding Intellectual Property Rights (IPR) issues: Free as in Freedom and Licensing.
• The X3DOM dual license is open source and includes both the MIT License and GNU General Public License (GPL) v3 or later.

Meshes

• 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.
• Polygon meshes can be created in many different tools. Results are easily exported to X3D, VRML, or other compatible formats. The X3D Resources page lists current conversion and translation tools.
• 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.
• Exported polygon meshes often have geometric problems: misaligned front/back normals, clockwise vice counterclockwise (ccw) definition, one-sided versus two-sided, non-coplanar quadrilaterals, etc.
• Running output meshes through one or more "cleanup" tools can help identify and correct these otherwise-obscure errors.
• Useful tools include Blender, Chisel, MeshLab, X3D-Edit quality assurance (QA) with embedded Xj3D CAD filter, etc.
• 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.
• Geometric compression in the .x3db binary encoding can reduce unnecessary significant digits, merge coplanar polygons, quantize colors and normals, etc.
• 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 Tags

• Each X3D scene can contain metadata about the document itself. Top-level elements of interest are X3D, Scene, head, component and meta.
• Follow meta-tag norms found in newScene.x3d (.html)
• Description tags are used for catalog entries. Ensure the first sentence provides a good overall description of the scene. Example:

  <meta name="description" value="This beautiful model of an actual clean bedroom will impress your mom."/>
  

• Update or remove meta tags with *default content descriptions*
• Remove extraneous trailing newline characters (which may be escaped as 
 character entities). Example:

  <meta name="description" value="This description has a trailing newline character.&#10;"/>
  

  X3D Canonicalization (C14N) rules include normalization of whitespace and C14N tools can take care of this task for you.
• Ensure you include both <meta name="title"/> (for document name) and <meta name="identifier"/> (for document url) tags, with filename values ending in .x3d (rather than VRML97 .wrl) extension.
• Dublin Core metadata terms define common conventions for default values used in name="value" attributes.
• The XHTML1 strict DTD and schema include formal definitions for all meta attributes.
• Translation programs should indicate that the output file is a conversion by adding a meta tag such as

  <meta name="generator" content="X3D-Edit, https://savage.nps.edu/X3D-Edit"/>

  or, when using ClassicVRML encoding,

  META "generator" "X3D-Edit, https://savage.nps.edu/X3D-Edit"

  The X3D approach to meta tags matches best practices in HTML.
• Metadata terms for consistent referencing can be found in the following authoring resources:
  • Dublin Core Metadata Initiative (DCMI): Terms and Element Set
  • HTML5 section 4.2.5: The meta element
  • HTML4 section 7.4.4: Meta data
  • Dictionary of HTML META Tags (About)
• Metadata terms for language codes:
  • IETF Best Current Practice (BCP) 47: Tags for Identifying Languages
  • ISO 639-2: Codes for the Representation of Names of Languages
  • Internet Assigned Numbers Authority (IANA) Protocol Registries: Language Tags
• Chapter 1, Technical introduction section 2.5.5 for the book X3D for Web Authors (also slides) provides details on the use of meta tags in X3D scene headers.

Metadata Nodes

• Detailed description of the X3D Metadata nodes appears in
  • Core component of the X3D Abstract Specification
  • Chapter 15, Metadata information online chapter for the book X3D for Web Authors
  • X3D Tooltips: MetadataBoolean, MetadataDouble, MetadataFloat, MetadataInteger, MetadataString and MetadataSet
• Typically the Metadata nodes have default containerField='metadata' except when they are child values of a MetadataSet node, in which case they have containerField='value'

Naming Conventions

• 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.
• There are multiple requirements for characters allowed in DEF/USE names.
  • .x3d, .x3db encodings: must follow XML requirements for ID/IDREF data type.
  • .x3dv, .wrl encodings: must follow ClassicVRML Grammar requirements for Id/IdFirstChar.
• 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.
• Use lower case for filename extensions. Examples: .png .jpg .txt. Although Windows systems are insensitive to upper/lower case, any differences will cause "file not found" failures on Unix systems (Apple, Linux) and http servers.
• Be consistent. When multiple files pertain to a single entity, start with the same name so that they will alphabetize adjacent to each other in the catalog and the directory listings. Examples: WaypointInterpolatorPrototype.x3d WaypointInterpolatorExample.x3d WaypointInterpolatorExample.png
• Similarly good choices for directory and subdirectory names can help keep scene names terse.
• Of related interest for DEF/USE and name attributes, focusing on Unicode characters: W3C Recommendation Extensible Markup Language (XML) 1.0, Appendix J: Suggestions for XML Names.

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.

• ConsistentDescriptiveName
• .PhysicalLocation (for example .KauaiHawaii)
• .SequenceNumber
• .01Month200x
• .ext

General notes on naming conventions:

• These conventions are suitable for X3D scenes, XML tagset design, and corresponding Java classes.
• This approach matches the node and field naming conventions in the X3D Specification (and most XML).
• (Ironic) Success Metric: when is a name successful?
  Answer: when no one has to discuss that name any more.

Scale Factors and Unit Conversions

• 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:
  <unit/> for angle (default radians), length (default meters), mass (default kilograms) and force (default newtons).
• X3D-Edit supports convenient Transform scale selection or definition of alternate units.
• X3D-Edit supports convenient Transform scale selection or definition of alternate units.
• Additional conversion tools include Unit conversion information site, Wikipedia unit conversion factors, Online unit conversion site
• ISO STEP is an ISO standard for the computer-interpretable representation and exchange of product manufacturing information, often used for computer-aided design (CAD) 3D models. STEP includes expression of units, as shown in TYPE si_unit_name metadata terms.
• TODO: SEDRIS unit conversion

• Length conversions:

  Common scaling factors, from given length unit to meters (m)
  Pica	Inches	Feet	Yards	Fathoms	Miles	Nautical Miles	Meters	Microns	Millimeters	Centimeters	Kilometers
  0.0042175176	0.0254	0.3048	0.9144	1.8288	1609.344	1852	1.0	0.000001	0.001	0.01	1000

  
  
• Angle conversions:

  Common scaling factors, from given angular unit to radians
  Degrees	Full Circle	Grads
  0.0174532925167 (Pi/180)	6.283185307179	0.01570796326795

  
  
• Force conversions:

  Common scaling factors, from given force unit to Newtons (N)
  Dynes	Kilogram-force	Pounds-force	Poundals
  0.00001	9.8068	4.4482	0.13826

  
  
• Mass conversions, avoirdupois:

  Common scaling factors, from given avoirdupois mass unit to kilogram (kg)
  Grains (gr)	Drams (dr)	Ounces (oz)	Troy Ounces (toz)	Pounds (lb)	Stone (14 lb)	Tons (U.S. short)
  0.00006479891	0.001771845195312	0.028349523125	0.0311034768	0.45359237	6.35029318	907.18474

  
  
• Mass conversions, metric:

  Common scaling factors, from given metric mass unit to kilogram (kg)
  Micrograms	Milligrams	Centigrams	Carats	Grams	Dekagrams	Metric Tonnes (t)
  0.000000001	0.000001	0.00001	0.0002	0.001	0.01	1000.0

Scripts

• The Script node embeds imperative programming code within a declarative X3D scene. It can perform computation as part of rendering a frame or reacting to user inputs.
• Event values are passed into and out of a Script using ROUTE connections.
• For consistent response among differing browser JavaScript implementations, avoid var declaration of variables. Instead, declare any persistent variables as field definitions in the parent Script node.
• newECMAscript.js is an editable example ECMAScript (JavaScript) source file for use with X3D Script node.
• Use lower-case boolean values true and false to match XML and ECMAScript/JavaScript rules. Capitalized TRUE and FALSE are only used in VRML syntax.
• Be sure to set <Script directOutput='true'> when using SFNode/MFNode fields.
• Use Browser.print(...) rather than a simple print(...) function when printing to the console. Browser.print(...) is the form supported by X3D, 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.
• 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 < and > escape-character replacements (which make script code nonportable). Example:
  

  <Script mustEvaluate="true">
      <field name="message" type="SFString" accessType="initializeOnly" value="World!"/>
  <![CDATA[
  ecmascript:
  
  function initialize (timestamp)
  {
           Browser.print ('Hello ' + message);
  }
  ]]>
  </Script>
  

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

  <field accessType="initializeOnly" name="localTraceEnabled" type="SFBool" value="true"/>
  

  Then, at end of the CDATA section:
  

  function tracePrint(outputString)
  {
      if (localTraceEnabled)
           Browser.print('[ScriptNameHere] ' + outputString);
  }
  function forcePrint(outputString)
  {
           Browser.print('[ScriptNameHere] ' + outputString);
  }
  

  This lets the script author use trace-aware output functions as a substitute for Browser.print() as follows.
  

                    tracePrint('Only print when localTraceEnabled is true');
                    forcePrint('Always print: localTraceEnabled=' + localTraceEnabled);
  

• Java Resources
  • Java.com install and Java Development Kit (JDK).
  • Savage Developers Guide: Java
  
  
• JavaScript (ECMAScript) Resources

  JavaScript is a common programming language used in Web browsers for HTML and X3D scripts.

  • ECMAScript-262 specification defines JavaScript functionality required by the X3D specifications.
  • Douglas Crockford videos, book JavaScript: The Good Parts, Wrrrld Wide Web site and code conventions
  • Google JavaScript Style Guide
  • Mozilla Developer Network (MDN) JavaScript Guide
  • Savage Developers Guide: JavaScript
  • Wikipedia: ECMAScript including version correspondence
  • Wikipedia: JavaScript including version history

  Notes on JavaScript specification naming:

  • JavaScript is not the same as Java, they are different programming languages.
  • ECMAScript is the standardized version of JavaScript that is specified for use with the X3D international standards. ECMAScript is produced by the Ecma International (formerly European Computer Manufacturers Association) with subsequent ratification by the International Organization for Standardization (ISO).
  • VrmlScript was a subset of JavaScript originally proposed for use with VRML 97.
  
  
• JavaScript Object Notation (JSON) Resources

  JSON is a data-structure convention for JavaScript.

  • Syntax correctness is testable using jslint and http://pro.jsonlint.com
  • jslint4java is a Java wrapper around Douglas Crockford's jslint tool,and https://code.google.com/p/jslint4java

Scalable Vector Graphics (SVG)

Overview. 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.

Resources

• SVG References and SVG Tutorial by Mozilla Developer Network (MDN)
• An SVG Primer for Today's Browsers by David Dailey, W3C Working Draft, September 2010
• Learn SVG site: coding, learning and resources

URL Links

• 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:

  <ImageTexture url='
     "earth-topo.png"
     "earth-topo-small.gif"
     "http://www.web3d.org/x3d/content/examples/earth-topo.png"
     "http://www.web3d.org/x3d/content/examples/earth-topo-small.gif"
  '/>
  

  or, if using the equivalent but more awkward syntax for "double-quoted" url attribute values:

  <ImageTexture url="
     &quot;earth-topo.png&quot;
     &quot;earth-topo-small.gif&quot;
     &quot;http://www.web3d.org/x3d/content/examples/earth-topo.png&quot;
     &quot;http://www.web3d.org/x3d/content/examples/earth-topo-small.gif&quot;
  "/>
  

• Sample usage of multiple (relative and online) url fields can be found in the X3D examples.
• Run a link checker to verify that URLs are correct and reachable. This step is performed periodically on the X3D example archives.
  • W3C Link Checker
  • Xenu's Link Sleuth
  • X3D-Edit node editing panes include url list editor checks for resource availability (green=found, black=retrieving, red=unavailable)
• Include "quotation marks" around each individual address, since url has type MFString.
• XML-aware editors may escape each " character as " for proper XML encoding. When using a text editor directly, it may be easiest to enclose the entire field in 'apostrophes' as shown next.
• References
  • X3D url tooltips
  • X3D specification: 9.2.1 URLs
  • Internet Engineering Task Force (IETF) Requests for Comments (RFC) 2396, Uniform Resource Identifiers (URI): Generic Syntax
  • World Wide Web Consortium (W3C) Naming and Addressing: URIs, URLs, ...

Validation of X3D Scenes using DTD and XML Schema

This section shows example declarations of DTD and Schema in X3D scenes.

One of the biggest benefits of the .x3d file encoding is XML validation. XML checks for well-formed documents, DTD validation and schema validation greatly improve quality assurance (QA) for X3D scenes. This approach exposes many possible errors and helps authors eliminate Garbage In Garbage Out (GIGO) problems. Useful links:

• X3D Validator is a Web application that comprehensively checks X3D scene validity.
• X3D Quality Assurance (QA) identifies errors and warnings in order to make X3D scene content more portable and reliable.
• X3D Specifications: DTD and Schema Validation includes the latest approved DTDs, schemas, change logs and documentation.

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" target="_blank"> is optional and may designate a variety of character sets. The X3D specifications are carefully designed to be fully compatible with XML requirements.

• Version 3.3: X3D 3.3 International Specification DOCTYPE/DTD and schema

  <?xml version="1.0" encoding="UTF-8"?>
  <!DOCTYPE X3D PUBLIC "ISO//Web3D//DTD X3D 3.3//EN"
                       "http://www.web3d.org/specifications/x3d-3.3.dtd">
  <X3D profile="Immersive" version="3.3"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema-instance" xsd:noNamespaceSchemaLocation="http://www.web3d.org/specifications/x3d-3.3.xsd">
  

• Version 3.2: X3D 3.2 final specification DOCTYPE/DTD and schema

  <?xml version="1.0" encoding="UTF-8"?>
  <!DOCTYPE X3D PUBLIC "ISO//Web3D//DTD X3D 3.2//EN"
                       "http://www.web3d.org/specifications/x3d-3.2.dtd">
  <X3D profile="Immersive" version="3.2"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema-instance" xsd:noNamespaceSchemaLocation="http://www.web3d.org/specifications/x3d-3.2.xsd">
  

  Transitional DTD use is not recommended. There is Transitional DTD beyond X3D 3.1 since this approach is no longer needed.

• Version 3.1: X3D 3.1 final specification DOCTYPE/DTD and schema

  <?xml version="1.0" encoding="UTF-8"?>
  <!DOCTYPE X3D PUBLIC "ISO//Web3D//DTD X3D 3.1//EN"
                       "http://www.web3d.org/specifications/x3d-3.1.dtd">
  <X3D profile="Immersive" version="3.1"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema-instance" xsd:noNamespaceSchemaLocation="http://www.web3d.org/specifications/x3d-3.1.xsd">
  

  The Transitional X3D 3.1 DOCTYPE/DTD was originally used by some tools during development, but is no longer recommended since it is not portable across different machines.

  <?xml version="1.0" encoding="UTF-8"?>
  <!--Warning:  transitional DOCTYPE in source .x3d file-->
  <!DOCTYPE X3D PUBLIC "http://www.web3d.org/specifications/x3d-3.1.dtd"
                       "file:///www.web3d.org/TaskGroups/x3d/translation/x3d-3.1.dtd">
  <X3D profile="Immersive" version="3.1"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema-instance" xsd:noNamespaceSchemaLocation="http://www.web3d.org/specifications/x3d-3.1.xsd">
  

• Version 3.0: X3D 3.0 final specification DOCTYPE/DTD and schema

  <?xml version="1.0" encoding="UTF-8"?>
  <!DOCTYPE X3D PUBLIC "ISO//Web3D//DTD X3D 3.0//EN"
                       "http://www.web3d.org/specifications/x3d-3.0.dtd">
  <X3D profile="Immersive" version="3.0"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema-instance" xsd:noNamespaceSchemaLocation="http://www.web3d.org/specifications/x3d-3.0.xsd">
  

  The Transitional X3D 3.0 DOCTYPE/DTD was originally used by some tools during development, but it is no longer recommended since it is not portable across different machines.

  <?xml version="1.0" encoding="UTF-8"?>
  <!--Warning:  transitional DOCTYPE in source .x3d file-->
  <!DOCTYPE X3D PUBLIC "http://www.web3d.org/specifications/x3d-3.0.dtd"
                       "file:///www.web3d.org/TaskGroups/x3d/translation/x3d-3.0.dtd">
  <X3D profile="Immersive" version="3.0"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema-instance" xsd:noNamespaceSchemaLocation="http://www.web3d.org/specifications/x3d-3.0.xsd">
  

  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.

• You can use X3dDoctypeChecker.java to convert from one DOCTYPE to the other:

  C:\www.web3d.org\x3d\content> java X3dDoctypeChecker
  
  usage: java X3dDoctypeChecker sceneName.x3d [-setFinalDTD | -setTransitionalDTD]
  

• Errata-correction versions of the XML Document Type Definition (DOCTYPE DTD) and Schema are provided as part of the X3D-Edit distribution or directly online as follows.

  X3D XML DOCTYPE (DTD)	X3D XML Schema
  x3d-dtd-changelog.txt	x3d-schema-changelog.txt
  x3d-3.3.dtd and documentation x3d-3.3-InputOutputFields.dtd x3d-3.3-Web3dExtensionsPublic.dtd x3d-3.3-Web3dExtensionsPrivate.dtd	x3d-3.3.xsd and documentation (.zip) x3d-3.3-Web3dExtensionsPublic.xsd x3d-3.3-Web3dExtensionsPrivate.xsd
  x3d-3.2.dtd and documentation x3d-3.2-InputOutputFields.dtd x3d-3.2-Web3dExtensionsPublic.dtd x3d-3.2-Web3dExtensionsPrivate.dtd	x3d-3.2.xsd and documentation (.zip) x3d-3.2-Web3dExtensionsPublic.xsd x3d-3.2-Web3dExtensionsPrivate.xsd
  x3d-3.1.dtd and documentation x3d-3.1-InputOutputFields.dtd x3d-3.1-Web3dExtensionsPublic.dtd x3d-3.1-Web3dExtensionsPrivate.dtd	x3d-3.1.xsd and documentation (.zip) x3d-3.1-Web3dExtensionsPublic.xsd x3d-3.1-Web3dExtensionsPrivate.xsd
  x3d-3.0.dtd and documentation x3d-3.0-InputOutputFields.dtd x3d-3.0-Web3dExtensionsPublic.dtd x3d-3.0-Web3dExtensionsPrivate.dtd	x3d-3.0.xsd and documentation (.zip) x3d-3.0-Web3dExtensionsPublic.xsd x3d-3.0-Web3dExtensionsPrivate.xsd

  Developmental versions of all X3D DTDs and schemas are maintained under version control at
  http://sourceforge.net/p/x3d/code/HEAD/tree/www.web3d.org/specifications

Viewpoints and Navigation

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/CrossHair online 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/AnimatedViewpointRecorderPrototype online prototype to hide high-detail viewpoints from the viewpoint list at long ranges. This allows scalability of many objects in a single scene.
• Key references: X3D Specification
• Further resources:
  • X3D Graphics specification: Navigation component, Viewpoint node (tooltip), NavigationInfo node (tooltip).
  • X3D for Web Authors online course: Chapter 05 - Appearance Material Textures, examples, slideset and video.

Volume Tools and Volume Visualization

• Tool recommendations:
  • 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).
  • Teem: nrrd (Nearly Raw Raster Data) is a file format and software library designed to support scientific visualization and image processing involving N-dimensional raster data.
  • Seg3D is a free volume segmentation and processing tool that combines a flexible manual segmentation interface with powerful higher-dimensional image processing and segmentation algorithms from the Insight Toolkit (Windows Macintosh Linux).
  • 3D Slicer is a multi-platform, free and open-source software package for visualization and medical-image computing (Windows Macintosh Linux).
• Additional resources:
  • X3D Graphics specification, version 3.3: Volume rendering component.
  • Medical and Volume Visualization Tutorial by Nicholas F. Polys, Virginia Tech
  • X3D Basic Examples Archive: Volume Rendering examples.

Contact

Questions, suggestions, additions and comments about this X3D Scene Authoring Hints page are welcome. Please send them to Don Brutzman (brutzman at nps.edu) who maintains it.

These hints were collected while teaching X3D Graphics and writing X3D for Web Authors. Questions, suggestions, additions and comments are welcome.

Online at http://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html

Updated: 29 November 2016