X3D Scene Authoring Hints

Don Brutzman (brutzman at nps.edu)

A collection of style guidelines, authoring tips and best practices to improve the quality, consistency and maintainability of X3D scenes.

Authoring | Coordinate Systems | Credits | Dates | HTML | Images | Inlines/Prototypes | License | Meshes | meta Tags | Naming Conventions | Resources | Scripts | URL Links | Validation | Viewpoints | X3D-Edit | X3D for Web Authors | X3D Resources | Contact

Authoring practices

• 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, Portuguese and Spanish.
• 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 Specifications 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. (Local copies of all current X3D specifications are also bundled with X3D-Edit.)

Coordinate systems for 3D

• Preferred scaling of scene 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 now supports 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 author selection and definition of alternate units by using the UNITS declaration in X3D version 3.3.
  • Additional conversion tools include Unit conversion information site, Wikipedia unit conversion factors, Online unit conversion site, and (TODO) SEDRIS unit conversion
• 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. Example scene: ModelOrientation.x3d (.wrl) (.html) (image)
• Position the default center of airborne, space and underwater entities in the centroid (geometric center) or center of gravity (for physics-based models). 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.
• Coordinate-system example scene: CoordinateAxesNSEW.x3d (.wrl) (.html) (image)
• Coordinate-system gimbals, including DIS axis conversions: Gimbals.x3d (.wrl) (.html) (image)
• 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.

Credits

• Ensure that all contributors to your content receive proper credit.
• The Basic X3D Examples, VRML 2.0 Sourcebook, X3D ConformanceNist Suite, Savage and X3D for Web Authors model archives are free for duplication and further use.
• Don't add scenes, images or audio files to the archive unless permission has been granted from the owner. 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='15 May 2010'/>

• Use full 4-digit numbers for years, e.g. 2004.
• For consistency, readability and program parsability, please use the date format 10 July 2004 (rather than other forms such as July 10, 2004 or 10/7/2004).
• 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.

HTML

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

• 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
  • HTML-Kit
  • HTML Tidy
  • WDG HTML Validator
• Encoding values for special characters in XML/HTML files are found under Character entity references in HTML.
• Want to learn more about HTML? Many books and online tutorials are available. Recommended: online lessons by Dave Raggett.
  • Introduction to HTML
  • More advanced HTML features
  • Adding a touch of style
• 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
  • Choosing a DOCTYPE

Images

• An excellent open-source image editor is the GNU Image Manipulation Program (GIMP).
• Do not add images to the open-source archives without proper permissions and Credits.
• Follow Naming Conventions for image 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).
• 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.
• 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.
• Use the W3C Image Info Service to check the properties of your online image.

Inline and Prototype Subscenes

• Inline scenes
  • 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
  
  
• Prototype Declarations
  • 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
  • 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
  • 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 specification

License

• An open-source license is applied to X3D models and source code produced by NPS (and others) for the various Web3D and Savage model archives. Typically the following meta tag is included in archived X3D scenes:

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

  The license is available as license.html and also available in plain-text form as license.txt for embedding in source-code files. Under the terms of this BSD open-source license both commercial & noncommercial uses are permitted, and the contributing authors retain original copyright as appropriate. This license can be adapted for use by other open-source contributors, if desired. Discussion, rationale and references regarding this license are available via the XMSF bugtracker license entry.

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 Chisel, Meshlab, X3D-Edit quality assurance (QA), Xj3D CAD filter, etc.
• Tool names for nodes are often quite obscure. 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 good 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 XML Security can support secure distribution of sensitive portions of an X3D model (such as the high-value NURBS representation).

meta tags

• 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 &#10; character entities). Example:

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

• 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.
• Metadata conventions for default values used in name="value" attributes are defined by the Dublin Core metadata terms.
• 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
  META "generator" "X3D-Edit, https://savage.nps.edu/X3D-Edit"
  This matches best practices in XHTML.

Naming Conventions

• CamelCaseNaming: capitalize each word, never use abbreviations, strive for clarity, and be brief but complete.
• startWithLowerCaseLetter when defining field names (i.e. attributes) for 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.
• Naming conventions apply to .x3d files, image files, and Prototypes. It is also a good idea to follow them for DEF/USE names.
• 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
• Good choices for directory and subdirectory names can help keep scene names terse.

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.

Scripts

• 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 JavaScript/ECMAscript 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);
  

• Caveat: more tips will be added when we begin working on Scene Access Interface (SAI) using Java.

URL Links

• 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 (with documentation)
  • 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 &quot; 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 using DTD and XML Schema

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.

X3D Specifications: DTD and Schema Validation provides links to the latest approved DTDs, schemas and documentation.

The following sections provides 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 will validate X3D v3.1 or v3.0 content, etc.

• Version 3.3: X3D 3.3 proposed 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">
  

  There is no Transitional X3D 3.2 or 3.3 Transitional DTD 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, 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, 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-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 (no longer providing 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://x3d.svn.sourceforge.net/viewvc/x3d/www.web3d.org/specifications

Viewpoints

• 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 is aligned along +X-axis with +Y-axis up, individual entities are typically pointed to right when seen from default view.
• Use clear, understandable 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", "Sports car from above", etc.
• Use whitespace instead of underscores in Viewpoint (and sensor) descriptions.
• 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.

Contact

Updated: 3 December 2011
Maintained by Don Brutzman (brutzman at nps.edu). Comments & suggestions are welcome.
These hints were collected while teaching X3D Graphics and writing X3D for Web Authors.
Online at http://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html