TC184 Visualization Requirements for X3D CAD

From Web3D.org
Revision as of 19:47, 22 October 2011 by Flux (Talk | contribs) (Flux http://mediamachines.wordpress.com/ and Vivaty http://vivaty.wordpress.com/ exist in parallel, each with its own company)

Jump to: navigation, search

Contents

Overview

TC184 is the ISO technical committee working on visualization standardization and interoperability support for CAD models.

  • The purpose of the assessment is to compile a summary report of 3D Visualization formats
  • The summary report will be used as part of an ISO ballot package
  • Balloting will take place to select formats which will be accepted by ISO as capable to support the 3D Visualization Requirements defined in document TC184/SC4 N2539
  • The ballot will allow selection of all formats if the level of compliance is sufficient.


TC184 is conducting the assessment process through a series of in-depth review sessions.

  • Format assessments are conducted by the Technical Experts that make up the 3D Visualization ad hoc committee
  • Each technical expert will be required to read the specification for the format being reviewed and assess its ability to support the 36 3D Visualization requirements
  • The technical expert will assign a value to each of the requirements a value of 0 – 5 will be assigned on each requirement. The value will define the level of support the technical expert found for the requirement while reviewing the format specification.


Formats under consideration for adoption as a 3D Visualization standard must either be already accepted by ISO or evaluated through the ISO Harvesting process.

  • X3D is already eligible as an approved set of ISO standards.
  • The X3D family of specifications are already approved by ISO. The Web3D Consortium is a Category C liaison to the ISO/IEC JTC1 SC24, and SC24 WG6 is the responsible working group.
  • The X3D CAD Working Group is responding to this survey of requirements support to determine suitability of X3D Graphics Specification for CAD interoperability.


X3D References

  • ISO/IEC 19775-1:2008 — X3D Architecture and base components — Edition 2 (Web3D) (ISO)
    • 27 NURBS component (Web3D)
    • 32 CAD geometry component (Web3D)
    • 35 Layering component
    • 36 Layout component
  • (Draft) X3D CAD Component Revision: Parametric Surfaces and Boundary Representations (BREPS)
  • ISO/IEC FCD 19776-1:200x — X3D XML encoding — Edition 2
  • ISO/IEC 19776-2:2008 — X3D Classic VRML Encoding — Edition 2
  • ISO/IEC FCD 19776-3:200x — X3D Compressed binary encooding — Edition 2
  • ISO/IEC 19777-1:2006 — X3D language bindings — ECMAScript
  • ISO/IEC 19777-2:2006 — X3D language bindings — Java


Terminology and Acronyms

  • CAx CAD/CAM/CAE
  • PDM Product Data Management
  • PMI Product Metadata Information


Evaluation Criteria

Ratings are evaluated on a scale of 0-5.

  • 0 - No support in the specification
  • 1 - Support is vaguely implied
  • 2 - Support appears available but the definition is not clear
  • 3 - Support is stated but the expert must seek clarification to determine how support is provided
  • 4 - Support is available in the specification
  • 5 - Full support for the requirement is readily available in the specification


Summary of Scores

The following table presents the self-assessment scores of the X3D CAD Working Group of the Web3D Consortium.

Interestingly, if current working-group effort to add B-REP capabilities to the X3D CAD Component is considered, few technical showstoppers remain that might limit X3D applications from implementing full support of TC184 Visualization Requirements.

Feedback is welcome.

Requirement Score
1 STEP Consistency 2
2 STEP Mapping 2
3 STEP & Product Life Cycle 2
4 View Geometry, Attributes, Viewing Attributes, Management and other information 5
5 Display selection & editing 4
6 Print/Plot 5
7 Zoom/Pan 5
8 Camera Rotation 5
9 Bill of Material (BOM) 4
10 Screen Capture 5
11 Measurement 4
12 Sectioning 4
13 Compare 3
14 Markup 4
15 Collaboration 4
16 Transformation/Manipulation 5
17 Grouping 5
18 Animation 5
19 Annotation Association 3
20 Clearance & Interference Analysis 3
21 View Annotation 5
22 Performance Settings 5
23 Standard View Creation 5
24 Create Reference Planes 2
25 Area Selection Filter 4
26 Entity Selection Filter 4
27 Visualization File Attributes 4
28 Interrogation 2
29 Instances 5
30 External References 5
31 Accuracy 3
32 Kinematics 5
33 Rendering Modes 5
34 Lighting Control 5
35 Data Format Footprint 5
36 Persistence of Visualization Information 4
Total (out of 180 possible points) 147
Percentage 81.7%


Requirement Descriptions and Self-Assessment

  • X3D response. For each requirement, a summary description of the ability of X3D to satisfy the requirement is provided along with one or more references to the specific X3D components that address the requirement.


Requirement 1: STEP Consistency

  • Formal Requirement. The information delivered via the visualization format should be consistent with the complete standardized product representation used for exchange and archiving purposes - the ISO STEP standard.
  • Survey Description. (same)
  • X3D response.

No formal assessment has been performed correlating ISO X3D constructs to the ISO STEP standard. Such an activity has significant potential value.

X3D is the third-generation successor to the ISO-standard Virtual Reality Modeling Language (VRML 97). As such it is designed as an interchange scene graph compatible with a wide variety of 3D file formats and application programming interfaces (APIs). Over 12 years of adoption and continuing deployment demonstrate that X3D serves well for visualization interchange and interoperability. Given these broad proven successes, the X3D working group is confident that X3D is likely to map satisfactorily to STEP visualization requirements.

Requirement 2: STEP Mapping

  • Formal Requirement. A published mapping specification as agreed to by SC4 is required from STEP to the visualisation format
  • Survey Description. (same as preceding requirement)
  • X3D response. Such a correspondence has not been created, but it is feasible and valuable to produce. Nothing prevents such an effort. Likely the biggest contribution might be mechanisms for embedding STEP metadata within X3D model components for tool usage. The Web3D Consortium is interested in pursuing such a possibility.

Commercial translators already allow automatic conversion from STEP (AP203 & AP214) to X3D. For instance, OKINO Polytrans supports the following STEP->X3D export functionality:

    • Output of clean mesh data with optional vertex normals and vertex texture coordinates.
    • Lights (point, spot and directional) and the perspective camera
    • 3D indexed line sets and 3D point sets
    • Material parameter output: ambient color, diffuse color, specular color, emissive color, shininess and transparency.
    • Hierarchy for geometry and folders
    • Export of Object, camera, light and material animation
    • Vertex colors for mesh data
    • NURBs surfaces with trim curves
    • 3D NURBS curves
    • Indexed triangle strip geometry
    • 3D NURBS independent curves
    • Control over the conversion of NURBS curves to NURBS or linear curves in the output file
    • Control over the conversion of Spline Shape primitives to NURBS or linear curves in the output file, or else conversion to meshes or NURBS surfaces if the curve(s) are closed.

Example reference links for Polytrans: STEP -> X3D, X3D -> STEP, export panel, nurbs settings panel

Requirement 3: STEP & Product Life Cycle

  • Formal Requirement. The 3D visualisation format may be used across the whole extended enterprise, throughout the supply chain, without restriction to a particular functional area
  • Survey Description. (same as preceding requirement)
  • X3D response.

X3D is a widely used visualisation standard for model interchange which includes file-format encodings for the Extensible Markup Language (XML), ClassicVRML and compressed binary. It is well suited for visualizing models across the extended enterprise. XML representations permit integration of metadata, animation behaviors and intelligent queries within the model, thus making models adaptable to requirements in different groups within an enterprise.

Because of this broad applicability, X3D is used for a variety of purposes relevant to CAD visualization.

    • Showcase purposes: ability to build integrated X3D applications with customized user-interface functionality and behavior animation embedded in the scene.
    • Industrial design: rich geometry representations, CAD Component, usefulness as an interchange format.
    • Public relations, thanks to: Most of the browser implementations can be embedded in a webpage, allowing lightweight 3D enhanced websites.

Companies using X3D include:

    • Bitmanagement, industrial design, showcases
    • EDF, industrial design, HPC numerical simulations, showcases
    • MBARI, daily operations by ships and underwater robots linking video and sensor data
    • MITRE, visualization service bus
    • NASA Ames, 3D models repositories, geospatial simulations
    • Naval Postgraduate School, 3D models repositories, teaching
    • Octaga, 3D real time industrial simulations
    • Planet 9 Studios, 3D Urban Simulation
    • Schlumberger, ocean and subterranean investigation
    • SenseGraphics, immersive multimodal environments
    • Vivaty, Online 3D avatar based communities
    • Yumetech, Rapid Scenario Generation, 3D model catalogs


Relevant X3D components include all aspects of X3D ISO/IEC 19775.

Requirement 4: View Geometry, Attributes, Viewing Attributes, Management and other information

  • Formal Requirement. Display 3-D representation of parts and assemblies independent of any CAx or PDM system. Any data within the scope of ISO 10303-1231 and 10303-1230 may have a viewable representation of Geometry, Attributes, Viewing parameters, and Management and other information.
  • Survey Description. Format is able to store the data which is the 3-D representation of parts and assemblies independent of any CAx or PDM system. Any data within the scope of ISO 10303-1231 and 10303-1230 may have a viewable representation of Geometry, Attributes, Viewing parameters, and Management and other information.
  • X3D response.

ISO/TS 10303-1230:2005 specifies the application module for Configuration controlled 3D parts and assemblies. It contains the following sections. X3D provides excellent support for each of these capabilities.

    • Products that are three-dimensional parts and assemblies can be modeled using regular X3D shapes and geometry, further structured using grouping nodes provided in 32 CAD geometry component
    • Configuration control data and product definition data tends to be application specific, but can be stored within the relevant portions of a model using 7.2.4 Metadata component
    • Shape representations that includes advanced boundary representation, faceted boundary representation, manifold manifold surfaces with topology, geometrically bounded surface and wireframe geometry, wireframe with topology, and constructive solid geometry in three-dimensions. can use numerous X3D capabilities, including 13 Geometry3D component, 14 Geometry2D component, 27 NURBS component, 32 CAD Geometry Component
    • Geometric presentation of geometric shape representations by the application of colours, layers and groups is possible via a broad range of grouping, appearance, material and texture components: 10 Grouping component, 11 Rendering component, 18 Texturing component, 35 Layering component
    • Geometric and dimensional tolerances applied to geometric shape representations.\ are possible. The X3D Specification is designed for more general use, but nothing prevents applications from building GD&T extensions. Furthermore, such capabilities can be portably embedded within models by using the 29 Scripting component and 4.4.4 Prototype semantics
    • Textual annotation and notes applied to geometric shape representations can be applied using the 15 Text component

Relevant X3D components include: 7 Core, 10 Grouping, 11 Rendering, 12 Shape, 13 Geometry3D, 14 Geometry2D, 15 Text, 32 CAD geometry, 35 Layering

Current development work includes adding a thorough set of boundary representation (BREP) support to the X3D CAD component.

Requirement 5: Display selection & editing

  • Formal Requirement. Any graphically selected element should be highlighted. All selected part or assembly from the assembly tree should be highlighted. The user should have the ability to, temporarily, turn on and off the display of selected elements (point, line, surface, solid annotation, mark-up, etc.) The user should have the ability to, temporarily, change the visual attributes of part(s) (e.g., turn parts on and off, change colour, make transparent) by selecting them from the assembly tree. The user should have the ability to select and display parts and assemblies sorted out by layers, colours, materials, dates, and other numerical or textual attributes.
  • Survey Description. The Format supports storage of data or constructs which enable the following activities in an implementing system
- Any graphically selected element should able to be highlighted.
- All selected part or assembly from the assembly tree should be able to be highlighted
- Support for the ability to temporarily, turn on and off the display of selected elements (point, line, surface, solid annotation, mark-up, etc.]
- Support for the ability to temporarily, change the visual attributes of part(s) i.e. turn parts on and off, change color, make transparent) by selecting them from the assembly tree.
- Support for the ability to select and display parts and assemblies sorted out by layers, colors, materials, dates, and other numerical or textual attributes
  • X3D response.

The X3D specification is capable of containing model information for all these capabilities.

Pointing-device sensors detect user motion of a cursor by using a mouse, wand, touchpad, touchscreen, keyboard arrow keys, or some other device. Interaction responses are expressed in a device-independent way that maximizes interoperability among diverse platforms. Viewer applications usually move a 2D cursor icon in front of the rendering 3D scene to show current screen position of the pointing device. Selected elements raise events, which in turn can raise and generate subsequent events, leading to precisely animated scene-graph modifications.

    • Object selection is handled by Pointing device sensor component
    • Rendering property alteration capabilities include any desired modification of appearance, single-sided or two-sided material values, transparency, texture images
    • Line properties and fill properties are especially helpful for indicating selection.

Relevant X3D components include 7 Core, 12 Shape, 20 Pointing device sensor, 35 Layering

Requirement 6: Print/Plot

  • Formal Requirement. Print and/or plot the information displayed on the screen. Users should be able to specify a scale to plot the image relative to native model boundaries, i.e., displayed images should be plotted at full scale, ½ scale, etc.
  • Survey Description. There are no restrictions in the format specification which prohibit the ability to print and/or plot the information displayed on the screen. No restrictions on the ability to scale and plot the data which represents the image relative to native model boundaries, i.e., displayed images could be plotted at full scale, ½ scale, etc. by an implementing system.
  • X3D response.

Applications implementing X3D often offer support for plotting 2D images at different scales and perspectives. Similarly, 3D printing is also feasible using various scales and output devices. No restrictions are included in the file format, leaving applications free to perform these functions as appropriate.

File:Shape small.jpg

Integration support with HTML web pages is also well defined and supported ( HTML Object Tag for X3D provides full details). For instance, an X3D browser used as a web plugin is able to display images relative to web page frame size.

Relevant X3D components include 7 Core, 9 Networking

Requirement 7: Zoom/Pan

  • Formal Requirement. Zoom/Pan into a local area of a 3D image without losing visual accuracy.
  • Survey Description. Data format does not restrict an implementing system from providing Zoom/Pan into a local area of a 3D image without losing visual accuracy.
  • X3D response.

Applications can provide full support based on the information available in an X3D model.

    • Authors can use either perspective-based 23.4.6 Viewpoint or orthographic 23.4.5 OrthoViewpoint to create model-specific animations
    • Applications can perform any of these capabilities based on information in the X3D scene
    • NavigationInfo types include two types of user-directed zoom (FLY and WALK), terrain following, EXAMINE rotation, and LOOKAT selection/zoom
    • Common alternate modes provided by applications include Fit to Screen, Tilt and Pan
    • Camera-to-object collision detection can be enabled/disabled on an object-by-object basis, permitting creation of guided paths or entry ways for user viewing
    • Authors can restrict or further extend built-in navigation features, either within a file format or programmatically
    • Remotely guided viewing viewing across a network is feasible using the IEEE Distributed Interactive Simulation (DIS) protocol

BsContact Browser, showing same model at different zoom levels:

File:Zoom small.jpg


Xj3D browser controls expose X3D navigation functionality typical to many viewing applications:

http://web3d.org/membership/login/groups/CAD/WikiImages/Xj3dNavigationButtonsHotkeys.png

Relevant X3D components include 10 Grouping, 23 Navigation

Requirement 8: Camera Rotation

  • Formal Requirement. Rotate the camera viewing perspective about a point either by an arbitrary or a specific axis. Rotation can occur either as a function of mouse/key input or by keying in exact angles. This is necessary in order to orient the parts relative to critical views for detailed analysis.
  • Survey Description. Format provides content definition which enables implementing systems to rotate the camera viewing perspective about a point either by an arbitrary or a specific axis.
  • X3D response.

Camera position and orientation can be precisely controlled for detailed model analysis. User-driven rotations occur by default as a function of pointer or arrow-key input. Alternatively applications or scenes may control rotation by allowing users to enter an exact angle. Precomputed view paths can be controlled using animation interpolators or follower nodes.

In X3D, camera functionality is primarily represented by the Viewpoint node. Viewpoint defines a specific location in the local coordinate system from which the user may view the scene. All subsequent changes to the viewpoint node's coordinate system change the user's view. Each Viewpoint includes a text description to assist user navigation and identify locations. The centerOfRotation field supports precise examination of objects. The Home key restores the original Viewpoint parameters by resetting local-user navigation steps. Applications can optionally provide an undo/redo history of user navigation steps.

An author can automatically move the user's view through the world by binding the user to a Viewpoint node and then animating either the Viewpoint node or the transformations above it. Such guided tours can be triggered by timers as well as user selection, proximity or visibility.

Here is the specification of the 23.4.6 Viewpoint node: 

Viewpoint: X3DViewpointNode { 
 SFBool     [in]     set_bind
 SFVec3f    [in,out] centerOfRotation  0 0 0   (-∞,∞)
 SFString   [in,out] description       ""
 SFFloat    [in,out] fieldOfView       π/4     (0,π)
 SFBool     [in,out] jump              TRUE
 SFNode     [in,out] metadata          NULL    [X3DMetadataObject]
 SFRotation [in,out] orientation       0 0 1 0 [-1,1],(-∞,∞)
 SFVec3f    [in,out] position          0 0 10  (-∞,∞)
 SFBool     [in,out] retainUserOffsets FALSE
 SFTime     [out]    bindTime
 SFBool     [out]    isBound
}

The NavigationInfo mode supplements Viewpoint information by specifying navigation type, transitionType between Viewpoints (LINEAR ANIMATE TELEPORT), transitionTime, user navigation speed (meters/sec), fieldOfView angle, view frustum parameters for near/far clipping plane, plus user avatar parameters for terrain following and object-collision standoff.

Note that the operation of all X3D nodes is defined in a device-independent manner. Authors can create scenes that work well on hand-held devices, desktop displays, headsets and immersive CAVE displays.

Relevant X3D components include 23 Navigation 19 Interpolation component 39 Followers component

Requirement 9: Bill of Material (BOM)

  • Formal Requirement. A selectable representation of the product structure (assembly Bill of Materials) should be displayed.

The product structure should be evident and individual parts and assemblies should be able to be displayed/highlighted by selecting from the product structure. The product structure representation shall be associated to the geometry representation, i.e. there is a bi-directional link between a part reference in the product tree and the corresponding part geometry.

  • Survey Description. The format provides data constructs such that an implementing system can define a selectable representation of the product structure (assembly Bill of Materials)

The product structure should be evident and individual parts and assemblies should be able to be displayed/highlighted by selecting from the product structure. The ability to support a bi-directional link between a part reference in an implementations product tree and the corresponding part geometry.

  • X3D response.

Authors and conversion tools can create X3D models directly from BOM listings.

The X3D 32 CAD Geometry component defines parts and assemblies:

    • The 32.4.1 CADAssembly node holds a set of assemblies or parts grouped together.
    • The 32.4.2 CADFace node holds the geometry representing a face of a part.
    • The 32.4.3 CADLayer node defines a hierarchy of nodes used for showing layer structure for the CAD model.
    • The 32.4.4 CADPart node is a grouping node that defines a coordinate system for its children that is relative to the coordinate systems of its ancestors.

X3D design includes several important and relevant capabilities:

    • Model metadata can be embedded directly in models or linked in external files.
    • Model catalogs (example) can be used to compose larger scenes of multiple Inline models.
    • XML encodings can greatly simplify the creation of X3D content by styling or converting XML-based BOM data directly into X3D.
    • Prototypes (author-defined node extensions) can codify design patterns to make best practices easily repeatable.
    • ExternProtoDeclare references facilitate the refinement and reuse of prototype declaration libraries, providing a more-powerful capability similar to macro definitions in earlier languages.

File:Parts small.jpg

Relevant X3D components include 7 Core, 32 CADGeometry

Requirement 10: Screen Capture

  • Formal Requirement. Capture the currently displayed image and save as another file. Users should be able to select from several neutral file types for the saved image.
  • Survey Description. An implementing system will be able to capture a displayed image of the data stored in the format and save it as another file type.
  • X3D response.

Printing or plotting the information displayed on the screen is performed by applications. X3D browsers generally integrate mechanisms to capture the rendered scene either by video recording or single-frame image capture. No internal mechanisms are defined that might prohibit image capture.

http://web3d.org/membership/login/groups/CAD/WikiImages/screenshot.JPG


Requirement 11: Measurement

  • Formal Requirement. Basic measurement capability would include the ability to get arbitrary point-to-point measurements.

Additional required functionality would include measurements relative to features such as Vertices (end of line), Lines (edge), Surfaces (face), and Parts. Advanced measurement includes distance along a curve or surface. The visualization tool should provide the capability to retrieve as much relevant information as possible, i.e., location, angle, size, area, volume, mass, etc. All measurements should be exact to model tolerance. The tool should measure in the unit of the native data.

  • Survey Description. Data stored in the format enables implementing systems to provide basic measurement capabilities such as
- arbitrary point-to-point measurements.
- measurements relative to features such as Vertices (end of line), Lines (edge), Surfaces (face), and Parts.
- the distance along a curve or surface.

The format should support the ability to store and retrieve as much relevant information as possible, i.e., location, angle, size, area, volume, mass, etc. The format will store data such that all measurements in an implementing system can be exact to model tolerance. The tool should support units of measure in the unit of the native data

  • X3D response.

X3D applications are capable of performing measurement tasks. X3D scene data is recorded using SI units, namely meters and radians.

    • X3D uses a Cartesian coordinate system in which three coordinate values (x, y, and z), stored as single-precision floating point values are sufficient to uniquely define any point in space.
    • Coordinate-frame transformation mechanisms are consistent throughout the X3D specification.
    • By providing an exact model of an object, proposed BREP representations might allow applications to perform measurements on parts length/area/volume/weight. This extension capability is currently defined and under working-group review, and thus is on track for implementation, evaluation and inclusion in the next version of X3D.
    • The 25 GeoSpatial component in X3D includes a variety of coordinates systems for positioning X3D objects using double-precision geospatial locations.


File:Measurement small.jpg


Authors can also embed Inline scenes, scripts or prototype widgets within a scene to facilitate end-user measurement via any X3D browser. Example scene follows GridsExample.x3d, along with a corresponding example user-modified version of the same scene showing embedded measurement capabilities: GridsExampleMeasurement.png. Embedded touch sensors enable users to toggle measurement grids on/off, and to drag graphs along their respective centerline axes in order to facilitate visual measurement of irregular dimensions. Coordinate values for each grid are updated via Script node calculations in Ecmascript, all in response to end-user manipulations of the X3D scene in an ordinary X3D browser.


http://web3d.org/membership/login/groups/CAD/WikiImages/GridExampleMeasurementInstantReality.png

Relevant X3D components include 7 Core, 12 Shape, 32 CAD Geometry, 35 Layering, 36 Layout

Requirement 12: Sectioning

  • Formal Requirement. Sectioning capabilities are critical to the ability to conduct upfront design evaluations. Viewers should have the greatest number of options possible for sectioning a part or assembly.

Critical functionality includes relative-to-model orientation (body position), radial sections (sections cut perpendicular to a curve relative to view position), true radial section (perpendicular to a curve or surface), and parallel to a surface. Should have the capability to drag the section plane through the part and have the section view update dynamically.

  • Survey Description. Format data definition must allow for the following tasks relative to section creation:
- relative-to-model orientation (body position)
- radial sections (sections cut perpendicular to a curve relative to view position)
- true radial section (perpendicular to a curve or surface)
- parallel to a surface.

The format cannot prevent an implementation from providing the capability to drag the section plane through the part and have the section view update dynamically.

  • X3D response.

In X3D, sectioning can be done by 11.2.4 Clip planes ( defined in 11 Rendering component). A clip plane is defined as a plane that generates two half-spaces. The affected geometry in the half-space that is defined as being outside the plane is removed from the rendered image as a result of a clipping operation. As a result a clip plane coordinates can undergo an arbitrary transformation and interactively cut an object either in its local coordinates space (i.e. perpendicular radial section), or in the global coordinates system (i.e. an arbitrary section).

File:Sectioning small.jpg

Relevant X3D components include 10 Grouping, 11 Rendering

Requirement 13: Compare

  • Formal Requirement. Identify differences between parts or versions of the same part.
  • Survey Description. Format data allows implementers to identify differences between parts or versions of the same part
  • X3D response.

Versioning and comparison is possible using X3D mechanisms for metadata and node identification, along with other external mechanisms.

    • In X3D, document-level metadata is supported by head and meta tags identical to HTML. Document-level versioning metadata typically follows Dublin Core (or other) conventions.
      Examples: <meta name="created" content="1 January 2003"/> <meta name="modified" content="1 January 2009"/>
    • Per-node 7.2.4 Metadata can be embedded in models so that relevant information is stored as an corresponding part of object geometry. This mechanism potentially allows versioning.
    • Version control is also easily accomplished using the XML encoding (or ClassicVRML encoding) via Subversion, CVS, etc. Some X3D tools (such as X3D-Edit) and most XML tools offer such support.
    • X3D models can be inlined and referenced via PHP or other server-side scripting mechanisms, enabling three-tier architectures as well as either database retrieval or data-driven creation of X3D models

These mechanisms allow easier maintenance of 3D scenes containing similar parts or objects. These capabilities also simplify the construction of 3D model catalogs. A 3D scene can then instantiate these objects by referencing the catalog entry, making it easier to identify different parts of assemblies, replace a part from an assembly, or perform version-based identification (and perhaps replacement) for parts in an assembly.

Identification and reuse of nodes or node groups via DEF/USE mechanisms avoids the need to check versions within a single scene, supporting copy-by-reference semantics.

    • In X3D, an object referencing mechanism allows arbitrary use of a previously declared object. When a node is given a DEF name, that name is an identification label that is unique in the file. USE names refer back to the unique node with the original DEF name.

Relevant X3D components include 7 Core

Requirement 14: Markup

  • Formal Requirement. Add markups to the 3D images so that they can be saved or printed and distributed to others. Minimum capabilities will include text and basic drawing functions such as circles and lines.

Visualisation tools should also give users the option of anchoring markups so that when the models are rotated, the markup maintains its original relationship with the model. Advanced functionality would include common symbols used in the engineering environment, i.e., Geometric Dimensioning and Tolerancing and Rubber Stamping.

  • Survey Description. Format provides for storage of markups to the 3D images so that they can be saved or printed and distributed to others.

- markups to include text and basic drawing data such as circles and lines. - support for anchored markups so that when the models are rotated, the markup maintains its original relationship with the model. - support for common symbols used in the engineering environment i.e., GD&T and Rubber Stamping

  • X3D response.

X3D supports labeling with the following elements:

As with several other requirements in this document, embedded or externally referenced metadata values can facilitate such constructs. All internal X3D scene metadata is typed (integer, float, double, string or set). Unlike comments or document metadata, such embedded metadata is persistent and must be retained during run-time so that it remains available to applications. The creation of markup-related prototype nodes to expose and render such data allows authors to make markup capabilities portable within a scene, as a helpful alternative to depending solely on applications to provide such capabilities.


http://web3d.org/membership/login/groups/CAD/WikiImages/markup.JPG


Relevant X3D components include 7 Core, 13 Geometry3D, 14 Geometry2D, 15 Text, 23 Navigation

Requirement 15: Collaboration

  • Formal Requirement. Present and share the capabilities of the visualisation tools in real time with others over a network
  • Survey Description. Format supports the ability present and share the capabilities of the visualization tools in real time with others over a network
  • X3D response.

Collaboration among users viewing 3D scenes has been implemented in several projects.

Simple yet effective collaboration techniques are also possible simply by refreshing URL connections within scenes.

http://web3d.org/membership/login/groups/CAD/WikiImages/shareX3D.JPG

File:DisEspduTestPanelDemo small.png


Relevant X3D components include 9 Networking, 28 Distributed interactive simulation (DIS)

Requirement 16: Transformation/Manipulation

  • Formal Requirement. Move parts from their original position to a new position. Functionality includes scale, drag, alignment, rotate, and transform relative to fixed axis.

Additional functionality will allow the users to rotate and transform relative to a particular feature. This function is only for visualization and will not change the master assembly definition.

  • Survey Description. Enable the storage of data that allows implementers to move parts from their original position to a new position.

- Includes scale, drag, alignment, rotate, and transform relative to fixed axis. Allow implementers to rotate and transform relative to a particular feature. - Must be able to perform this function without changing the master assembly definition.

  • X3D response.

In X3D, transformation and manipulation of collections of objects is accomplished by nodes defined in the X3D 10 Grouping component. The 10.4.4 Transform node defines a local coordinate system in the scene graph, translated rotated and scaled (perhaps nonuniformly) relative to its parent coordinate system. The adjusted coordinate system applies to every child of the node.

Specifically the Transform node defines a geometric 3D transformation consisting of (in order):

    • a (possibly) non-uniform scale about an arbitrary point;
    • a rotation about an arbitrary point and axis;
    • a translation.

Transformation details follow. Given a 3-dimensional point P and Transform node, P is transformed into point P' in its parent's coordinate system by a series of intermediate transformations. In matrix transformation notation, where C (center), SR (scaleOrientation), T (translation), R (rotation), and S (scale) are the equivalent transformation matrices. 

 P' = T * C * R * SR * S * -SR * -C * P

The following Transform node represents the preceding transformation: 

Transform {
 center           C
 rotation         R
 scale            S
 scaleOrientation SR
 translation      T
 children         [
   # Point P (or children holding other geometry)
 ]
}

This transformation is functionally equivalent to the general capabilities provided by 4x4 transformation matrices. Multiple Transform nodes can be nested to accomplish a composite transformation. Transform fields are directly animatable by type-specific value interpolators or user-defined scripts.


http://libx3d.sourceforge.net/tree/classX3D_1_1Transform__coll__graph.png


A rich set of user-interaction sensors permit authors to design content-specific manipulation modes for end users. Manipulators include PlaneSensor, CylinderSensor, SphereSensor, KeySensor and StringSensor. Sensors are hardware-device independent (i.e. mouse, laser pointer, wand, arrow keys, etc.) and include descriptive text to guide users. Sensor manipulation response can also distinguish between pointer hovering, pointer selection and pointer dragging.

As noted elsewhere, X3D interface nodes are defined in a device-independent way that allows authors to build scenes that render and interact well using all manner of interactive display devices.

The following example UserInteractivitySensorNodes.x3d shows before and after changes from user manipulation, including a TouchSensor which changes background color.

http://web3d.org/membership/login/groups/CAD/WikiImages/UserInteractivitySensorNodes.png http://web3d.org/membership/login/groups/CAD/WikiImages/UserInteractivitySensorNodesModified.png

Relevant X3D components include 10 Grouping, 20 Pointing device sensor, 22 Environmental sensor

Requirement 17: Grouping

  • Formal Requirement. Create groups of parts or assemblies that can be acted on as one. This function is only for visualization and will not change the master assembly definition.
  • Survey Description. Allow implementers of the format to create groups of parts or assemblies that can be acted on as one. Implementation of this functionality must not change the master assembly definition.
  • X3D response.

This is handled by the 10 Grouping component in X3D, which defines a common parent geometry that need to be grouped. There are several forms of grouping nodes for different situations. Additional CAD-specific grouping nodes are provided in the CAD component: CADAssembly, CADFace, CADLayer, and CADPart (described earlier in this document).

http://libx3d.sourceforge.net/tree/classX3D_1_1Group__coll__graph.png

Relevant X3D components include 10 Grouping, 32 CAD Geometry

Requirement 18: Animation

  • Formal Requirement. Create animations of one or more parts moving with respect to one another (e.g., simulating the assembly or disassembly process, mechanisms movement).
  • Survey Description. Format supports the creation of animations of one or more parts moving with respect to one another i.e., simulating the assembly or disassembly process, mechanisms movement
  • X3D response.

Thorough animation capabilities are provided by X3D for every aspect of the scene graph.

    • Similarly sequencer nodes are defined for animating discrete (integer or boolean) values.
    • Script nodes can define functional triggers and responses for animating any typed values in the scene graph, including the creation of new node sets.
    • Movement of parts with respect to one another is handled by the scene transformation hierarchy defined by embedded Transform nodes. Every 10.4.4 Transform node defines a local coordinate system relative to its parent, with properties that only affect its children.


Relevant X3D components include 7 Core, Grouping, Interpolation component, Scripting component, Event utilities component

Requirement 19: Annotation Association

  • Formal Requirement. CAx entities linked to a selected annotation (dimension, tolerance, note, etc.) should be highlighted
  • Survey Description. Format supports the ability for CAx entities to be linked to a selected annotation e.g. dimension, tolerance, note, etc. should be able to be highlighted
  • X3D response.

For annotations, see Requirement 14 (markups). Highlighting CAx entities according to selected annotation can be done by applications programmatically, or by authors explicitly, using the X3D event-routing system for animation. As with several other responses, the use of embedded or external metadata, in combination with application-specific functionality or embedded Prototype node extensions, can be applied to perform annotation association tasks.

Explanation details follow. The event model of X3D allows the declaration of connections between fields (routes) and a model for the propagation of events along those connections. The behaviour graph is the collection of these field connections. It can be changed dynamically by rerouting, adding or breaking connections. Events are injected into the system and propagate through the behavior graph in a well defined order. The ability to select an annotation can be done by picking (see I.5: Display selection and edition). Parts that have to be highlighted when an annotation is selected can be identified by routing events from an event sending node (e.g., a 20.4.4 Touch sensor node), to the actual part node, through a behaviour node (e.g., a 19.4.1 Color Interpolator node).

The semantics of the 7.2.5.6 ROUTE statement are specified in the 7 Core component.

http://www.web3d.org/x3d/specifications/ISO-IEC-FDIS-19775-1.2-X3D-AbstractSpecification/Images/ConceptualExecutionModel.png

Relevant X3D components include 7 Core, 12 Shape, 20 Pointing device sensor, 38 Picking sensor

Requirement 20: Clearance & Interference Analysis

  • Formal Requirement. Perform analysis of clearances and interferences of parts in assemblies.

The visualisation tool will then report the clearance values. Advanced functionality will display areas on parts where clearance conditions are violated. Visualisation tools should show users where clearances were violated or when contacts or interferences occurred.

  • Survey Description. Format supports retention of data required to perform analysis of clearances and interferences of parts in assemblies.

Data is available to support implementers in providing advanced functionality which will display areas on parts where clearance conditions are violated. Data is available that supports implementers of Visualization tools to show users where clearances were violated or when contacts or interferences occurred

  • X3D response.

Native support is not directly required in the X3D Specification for Clearance & Interference Analysis.

Similarly to previous requirement, a routing pipeline with scripted and reactive input/response functions can be defined in X3D to handle clearance and interference analysis. Collision nodes can be used to generate events when viewer and objects collide, and can be used to designate that certain objects should be treated as transparent to collisions. Support for inter-object collision is not specified in X3D Core.

Nevertheless, the 37 Rigid Body Physics component allows authors and application developers to animate their environments using real-time rigid-body physics engines. This makes scene objects to respond correctly to each other and the user in a non-scripted fashion, with physical responses that integrate collision detection with friction and forces.

Thus applications can offer relevant functionality, while authors can further create and embed such functionality directly within relevant scenes.

Relevant X3D components include 7 Core, 23 Navigation, 37 Rigid body physics

Requirement 21: View Annotation

  • Formal Requirement. View 3D annotations (i.e., Dimensions, notes, geometric and dimensional tolerances, PMI, symbols…) created in the native CAx models.
  • Survey Description. Format implementers area able to store data that supports the View of 3D annotations i.e., Dimensions, notes, geometric and dimensional tolerances, PMI, symbols … created in the native CAx models.
  • X3D response.

See Requirement 14 (Markups) Text nodes and indeed any geometry can be used as an annotation. X3D can instantiate custom prepared geometries from a catalog (4.4.3 DEF/USE semantics, 9.4.2 Inline node). To have 3D annotations, one would have to build a catalog of such annotations, using the representation function of X3D. (Geometry primitives, 18 Texturing, 15 Text, animations)

Of particular relevance is that Viewpoint, OrthoViewpoint and ViewpointGroup nodes can organize or indicate view annotations when they are applied as description strings. Applications are premitted to offer such descriptions in any appropriate manner (including text-to-speech auralization).

Relevant X3D components include 7 Core, 11 Rendering, 13 Geometry3D, 14 Geometry2D, 15 Text, 18 Texturing, 23 Navigation, 35 Layering, 36 Layout

Requirement 22: Performance Settings

  • Formal Requirement. Optimize the application and the way it works with the particular data set. Performance settings may allow users to automatically reduce the complexity of the model when it is being manipulated. The Levels of Details (LODs) the user requires may influence performances.
  • Survey Description. Provide constructs for Levels of Detail such that implementers can Optimize their application and the way they work with the particular data set. The format should support performance settings which allow users to automatically reduce the complexity of the model when it is being manipulated.
  • X3D response.

There are a large number of ways to reduce scene complexity and improve rendering performance of complex scenes in X3D. Many of these methods can be suggested or applied automatically by authoring tools.

    • Multiple equivalent shapes having varied fidelity and resolution can be used to perform dynamic level of detail (LOD)
    • Switch node can select a single appropriate child group containing geometry, or else select/render no child group
    • Decreasing the frustum back plane distance (i.e. NavigationInfo visibilityLimit) to hide objects which are beyond the usable or practical range of the camera
    • In X3D, the frustum back clipping plane distance is defined by 23.4.4 NavigationInfo node, in 23 Navigation component. Geometry beyond the visibilityLimit may not be rendered. A value of 0.0 indicates an infinite visibility limit.
    • Level of details is explicitly specified thanks to the eponymous node, 23.4.3 LOD (also in Navigation component). It allows to set which parts will be shown at an arbitrary distance from the camera. Authors can indicate whether transition distances are applied as optimization hints to the browser, or else strictly enforced to guarantee consistently predictable switching.
    • Geometry nodes in various X3D profiles have been carefully chosen to allow autoreduction of geoemetry constructs into forms supported by the high-performance Interachange and Interactive Profiles

Relevant X3D components include 23 Navigation 10 Grouping

Requirement 23: Standard View Creation

  • Formal Requirement. Define and save standard views on the computer, i.e., side view, plan view, rear view, die view, etc.
  • Survey Description. Provides for data constructs that define and save standard views on the computer, i.e., side view, plan view, rear view, die view, etc.
  • X3D response.

The 23.4.6 Viewpoint and 23.4.5 OrthoViewpoint nodes, in the 23 Navigation component, define a specific location in the local coordinate system from which the user may view the scene. Viewpoints can be stacked in order to define a list of view from standard locations relative to the object (front, rear, side, etc.)

ViewpointGroup nodes can collect and display (or hide) multiple child Viewpoint, OrthoViewpoint and ViewpointGroup nodes. This facilitates focused display and selectability of view description strings in large scenes.

http://web3d.org/membership/login/groups/CAD/WikiImages/viewpoints.JPG

Some Implementations also allow to have multiples views at the same time, just like on any traditional CAD design system. File:StdViews small.jpg

Relevant X3D components include 23 Navigation

Requirement 24: Create Reference Planes

  • Formal Requirement. Create reference planes on the model that can be used to perform functions relative to them such as measurement, sectioning, viewing, etc
  • Survey Description. Format provides data which can be used to create reference planes on the model

The reference plane data should allow implementers to provide functionality that can be used to perform functions relative to them such as measurement, sectioning, viewing, etc.

  • X3D response.

The 10.4.4 Transform node can be used to create convenient local coordinate systems which can then be used to define geometry. In addition, the 25 Geospatial component is being augmented to support spatial reference frames that inherently include reference planes (e.g., tangent planes).

Relevant X3D components include 7 Core, 10 Grouping, 25 Geospatial

Requirement 25: Area Selection Filter

  • Formal Requirement. Specify a bounding box to identify parts. Users should have a minimum of 2 options: select completely inside or partially inside. The third option, select part that cross the boundary, is highly desirable.
  • Survey Description. Implementers of the format will be able to specify a bounding box to identify parts with a minimum of 2 options: select completely inside, and select partially inside. An optional option would be to select a part that crosses a boundary.
  • X3D response.

Geometric shapes can be selected and activated by users via a TouchSensor. Alternatively transparent geometry can be placed around collections of irregular objects (such as text) to facilitate selecting objects of interest. This is a general technique.

Further functionality is available using picking sensors: LinePickSensor, PickableGroup, PointPickSensor, PrimitivePickSensor and VolumePickSensor.

Relevant X3D components include 22 Environmental sensor, 23 Navigation, 38 Picking sensor

Requirement 26: Entity Selection Filter

  • Formal Requirement. Select the type of feature to be used in some other visualisation operation. This makes it much easier to select a particular feature for manipulation.
  • Survey Description. Implementers of the format will be able to specify a bounding box to identify parts with a minimum of 2 options: select completely inside, and select partially inside. An optional option would be to select a part that crosses a boundary
  • X3D response.

The PickableGroup provides for identifying children as being of a given classification of picking types, thus enabling this capability.

Applications and authors can also build such functionality using sensor nodes for geometry, Anchor links for connecting url pages or viewpoints to selected geometry, embedded or external metadata, and scripts or prototype node extensions for implementing desired operations.

Relevant X3D components include 7 Core, 9 Networking, 23 Navigation, 29 Scripting

Requirement 27: Visualization File Attributes

  • Formal Requirement. Data specific to the creation of the visual representation (e.g., date and time translated, CAx file name, etc) should be available. Specific data associated with the product is covered by N°4 including any data quality stamps.
  • Survey Description. Format provides for data specific to the creation of the visual representation i.e. date and time translated, CAx file name, data quality stamps, etc.
  • X3D response.

In X3D, there are several ways of storing such information. In all cases, such information is considered to be metadata. Metadata can be global as shown in the two examples below. In addition, every node in X3D has the ability to have type-specific metadata attached. Thus, requirements that apply only to a portion of visual presentation can be specified locally.

    • Metadata can be stored in the file header, as shown on the following example: <head>
<meta name='title' content='Digitoxigenin.x3d'/>
<meta name='description' content='Autogenerated version of Digitoxigenin.x3d scene produced from Digitoxigenin.xml Chemistry Markup Language (CML) source file.'/>
<meta name='creator' content='Nicholas F. Polys'/>
<meta name='created' content='24 November 2005'/>
<meta name='modified' content='1 December 2008'/>
<meta name='reference' content='Digitoxigenin.xml'/>
<meta name='CML version' content='1.0'/>
<meta name='reference' content=' CML sources http://www.xml-cml.org '/>
<meta name='reference' content='JUMBO Chemical Format Conversion Tool'/>
<meta name='reference' content=' http://webbook.nist.gov/chemistry '/>
<meta name='reference' content='Polys.StylesheetTransformationsInteractiveVisualization.Web3d2003Symposium.pdf'/>
<meta name='reference' content='Originally Published in Proceedings of Web3D 2003, ACM Press'/>
<meta name='generator' content='CmlToX3d.xslt'/>
<meta name='identifier' content=' http://www.web3d.org/x3d/content/examples/Basic/ChemistryMarkupLanguage/Digitoxigenin.x3d '/>
<meta name='license' content='../../license.html'/>
</head> 
[...]
    • Typed internal metadata nodes include MetadataString, MetadataInteger, MetadataFloat, MetadataDouble, and MetadataSet (which can contain multiple other Metadata nodes). This is the primary mechanism for embedding scene-persistent metadata.
    • Metadata can also be stored on the specific 7.4.6 WorldInfo node, as in the following example: 
<?xml version="1.0" encoding="UTF-8" ?>
<X3D profile='Immersive'>
 <Scene>
  <WorldInfo info='
    "author  : "
    "tool    : Google SketchUp 7.0.8657"
    "created : 2009-02-05T19:56:36Z"
    "copyright: "
    "comments: " '/>
[...]

Note that the WorldInfo approach is an older and less-capable construct for embedded metadata that was carried forward from VRML97. Unlike Metadata nodes or XML-encoded name=value pairs, the WorldInfo info string is not easily parsed or validatable.

Relevant X3D components include 7 Core

Requirement 28: Interrogation

  • Formal Requirement. Interrogate product structure and GD&T (Geometric Dimensioning and Tolerancing)
  • Survey Description. Format provides for data that allows implementers to interrogate product structure and GD&T (Geometric Dimensioning and Tolerancing)
  • X3D response.

In its XML expression, XML tools can be used for interrogating the model. For instance, the project "3DSEAM: a model for annotating 3D scenes using MPEG-7", have been making extensive use of XPATH to interrogate X3D scenes.

Here is an extract: "The Structural Localization uses the structure of a document in order to indicate the document entries that correspond to the object. For instance, if the document has an XML-like hierarchical structure, a structural localization can be composed of a series of XPATH expressions. As an illustration, let us consider the scene described in the following code. The localization of the first floor of the White building can be defined by the following XPATH expressions: /X3D/Scene/Transform/Group[@DEF='WHITE']/Transform[position()=1]" 

<X3D profile="Core" ...>
<Scene>
<Transform>
<Group DEF="WHITE">
<Transform DEF="WHITE1st"
translation="-23 1 -12" scale="2 1 12">
...
</Transform>
<Transform DEF="WHITE2nd"
 translation="-23 3 -12" scale="2 1 12">
 ...
 </Transform>
<Transform DEF="WHITE3rd"
 translation="-23 5 -12" scale="2 1 12">
 ...
 </Transform>
 <Transform DEF="WHITE4th"
 translation="-23 7 -12" scale="2 1 12">
 ...
 </Transform>
 </Group>
 <Group DEF="BLUE">
 ...
 </Group>
 <Group DEF="RED">
 ...
 </Group>
 <Group DEF="ROADS">
 ...
 </Group>
 </Transform>
 </Scene>
</X3D>

Which represents the following scene: http://web3d.org/membership/login/groups/CAD/WikiImages/scene.JPG

Note that these capabilities are available due to carefully constructed compatibility with XML standards. Such query and interrogation features are optional and not required by X3D.

Relevant X3D components include 7 Core as well as the Scene access interface (SAI)

Requirement 29: Instances

  • Formal Requirement. View multiple instances of a single part in an assembly
  • Survey Description. The format does not prevent the implementation for view of multiple instances of a single part in an assembly.
  • X3D response.

See Requirement 13 (Compare) for a similar discussion.

    • In X3D, an object referencing mechanism allows arbitrary use of a previously declared object. When a node is given a DEF name, that name is an identification label that is unique in the file. USE names refer back to a node with a DEF name.
    • This mechanism allows easier maintenance of 3D scenes containing similar parts or objects. It also allows to build 3D models catalogs. A 3D scene can then instantiate these objects by referencing the catalog entry, making it easier to identify different parts of assemblies, replace a part from an assembly or doing version control over parts of an assembly.
    • Typically only one viewpoint is bound at a time in a single view, but applications showing multiple simultaneous views are not precluded or prevented.
    • Additionally, a single part can be reliably represented in different views using the Layering and Layout components.

One such example is shown on the following picture.


http://web3d.org/membership/login/groups/CAD/WikiImages/multipleViews.JPG

Relevant X3D components include 7 Core

Requirement 30: External References

  • Formal Requirement. Visualisation of externally referenced parts, drawn from a product library
  • Survey Description. Format supports data that enables the visualization of externally referenced parts, drawn from a product library.
  • X3D response.

In X3D, rendered objects can be stored for use by multiple scenes. This is done via 9.4.2 Inline node. An Inline node loads one X3D scene into another. 

<?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 '>
<head>
 </head>
 <Scene>
  <Inline url=' "http://X3dGraphics.com/examples/X3dForWebAuthors/KelpForestExhibit/KelpForestMain.x3d" '/>
 </Scene>
</X3D>

The 9.4.1 Networking component also provides support for the 9.4.1 Anchor grouping node. Such a node retrieves the content of a URL when the user activates (e.g., clicks) some geometry contained within the Anchor node's children. Anchor links can refer to a named viewpoint in the scene, a new external X3D scene, or a new external resource (such as an HTML page). Anchor links for X3D can be targeted for presentation within the currently displayed window, or else launched into a separate frame.

Direct support is also defined for images, movies, audio clips and HTML. Support for any other media type is allowed if the implementing X3D viewer supports it. Viewers encountering unfamiliar media types can relay them to an external Web browser.

Note that X3D url strings are actually ordered lists. This permits more than one address to be given for a specific resource, greatly improving reliability. Browsers try each url value in order until a successful retrieval occurs. This flexibility also allows interesting techniques such as preferential loading of local or online resources.

Relevant X3D components include 7 Core, 9 Networking

Requirement 31: Accuracy

  • Formal Requirement. The interrogation of measurements from the visualisation model should deliver the same results as interrogation from the original CAD model, within a known tolerance.
  • Survey Description. Stored data supports the interrogation of measurements from the visualization model which deliver the same results as interrogation from the original CAD model, within a known tolerance.
  • X3D response.

Such data is stored in strongly typed metadata nodes as received and is returned in the same form. Supported metadata types are String, Integer, single-precision Float, double-precision Double and MetadataSet collections.

Relevant X3D components include 7 Core

Requirement 32: Kinematics

  • Formal Requirement. Support the kinematics of assemblies.
  • Survey Description. Format supports storage of data which allows implementers to provide kinematics motion with assemblies.
  • X3D response.

Connected physical systems can be represented by animated transformations, follower nodes or Rigid Body Physics nodes. Geometric sub parts can be linked between each other with transforms. X3D can define animations and interpolations as scene-graph modifications and thus permits:

    • Definition of timeline
    • Scalar value interpolation
    • Color value interpolation
    • Position interpolation
    • Orientation Interpolation
    • Normal Interpolation

Kinematics can also be implemented using the Script node or the Follower nodes.

Additionally the IEEE DIS component EspduTransform includes networked distribution of first-order kinematics and second-order dynamics terms among multiple participating scenes.

Relevant X3D components include 7 Core, 8 Time, 19 Interpolation

Requirement 33: Rendering Modes

  • Formal Requirement. Support different rendering styles of the model based on the original properties held in the CAD system, noting the various technologies available.
  • Survey Description. Format provides support for different rendering styles of the model based on the original properties held in the CAD system.
  • X3D response.

Rendering style can be set at application level. Wireframe, points cloud rendering of geometry is a special feature offered by some browsers and cannot be set by an X3D author.

On the other hand, rendering can be altered within the 3D scene definition by loading custom GPU code fragments, known as shaders. The 31 Programmable shaders somponent defines procedural shaders in X3D. They can define both appearance and light sources relative to the objects.


Bump mapping and other shader effects are available using the Shader component. The following example is shown using the BSContact browser:

http://web3d.org/membership/login/groups/CAD/WikiImages/bump.JPG

A wide variety of rendering capabilities are thus pssible, including (but not necessarily limited to) lighting effects, LineProperty/FillProperty highlighting, point/wireframe/shaded rendering, etc. Special techniques such as nonphotorealistic rendering and raytracing are also possible but typically are application specific.

Relevant X3D components include 7 Core, 31 Programmable shaders, browser-specific methods.

Requirement 34: Lighting Control

  • Formal Requirement. Change and control the number and types of lights and environment illuminating the scene.
  • Survey Description. Format supports the storage of data which enables the change and control of the number and types of lights and the environment illuminating the scene.
  • X3D response.

In X3D, the 17 Lighting component delivers ways to define light sources. Light sources interact with geometry nodes ([http://www.web3d.org/x3d/specifications/ISO-IEC-FDIS-19775-1.2-X3D-AbstractSpecification/Part01/components/shape.html#Shape 12.4.5 Shape nodes). Shape nodes are illuminated by the sum of all of the lights in the world that affect them. A minimum of eight lights must be supported. See reference for further information about X3D illumination model. The following node types are light source nodes:

  • DirectionalLight
  • PointLight
  • SpotLight

The characteristics of these nodes are specified in the 17 Lighting component. Both local and global scope are allowed for optimizing performance. Lights can easily be animated on/off. Full control is available for intensity, ambient contributions, etc.

http://libx3d.sourceforge.net/tree/classX3D_1_1X3DLightNode__inherit__graph.png

Relevant X3D components include 17 Lighting, 18 Texturing, 31 Programmable shaders

Requirement 35: Data Format Footprint

  • Formal Requirement. The format should be significantly smaller than the original CAD data. This will enable the data to be used on smaller office automation computers instead of engineering workstations.
  • Survey Description. The format should be significantly smaller than the original CAD data. This will enable the data to be used on smaller office automation computers instead of engineering workstations.
  • X3D response.

In X3D, this is achieved by supporting file compression using the ISO/IEC 19776-3:2007 X3D Compressed binary encoding, which allows 3D scenes to be more easily exchanged.

This part of ISO/IEC 19776 uses Fast InfoSet to serialize and compress an X3D document. It uses several techniques that reduce the size of an X3D document and that increase the speed of creating and processing such documents. These techniques are based on the use of vocabulary tables that allow small (typically) integer values (i.e. vocabulary table indexes) to be used instead of character strings.

http://nb.vse.cz/~zelenyj/it442/eseje/xzmej02/fast-infoset.gif

Geometric compression techniques using the Deering algorithms are also defined and supported for use with X3D compressed binary encoding.


Requirement 36: Persistence of Visualization Information

  • Formal Requirement. The format should support the capability to save the current state of the visualization, including annotation, transformations, viewing parameters and rendering applied by the visualization tool.
  • Survey Description. The format should support the capability for implementers to save the current state of the visualization, including annotation, transformations, viewing parameters and rendering applied by the visualization tool.
  • X3D response.

In X3D, viewing parameters can be save within the scene as either a 23.4.6 Viewpoint node or a 23.4.5 OrthoViewpoint, that will be stacked in the browser's list of accessible viewing parameters. 

Viewpoint: X3DViewpointNode { 
 SFBool     [in]     set_bind
 SFVec3f    [in,out] centerOfRotation  0 0 0   (-8,8)
 SFString   [in,out] description       ""
 SFFloat    [in,out] fieldOfView       p/4     (0,p)
 SFBool     [in,out] jump              TRUE
 SFNode     [in,out] metadata          NULL    [X3DMetadataObject]
 SFRotation [in,out] orientation       0 0 1 0 [-1,1],(-8,8)
 SFVec3f    [in,out] position          0 0 10  (-8,8)
 SFBool     [in,out] retainUserOffsets FALSE
 SFTime     [out]    bindTime
 SFBool     [out]    isBound
}

The Viewpoint node defines a viewpoint that provides a perspective view of the scene. A perspective view is one in which all projectors coalesce at position.

The fieldOfView field specifies a preferred minimum viewing angle from this viewpoint in radians. A small field of view roughly corresponds to a telephoto lens; a large field of view roughly corresponds to a wide-angle lens. The field of view shall be greater than zero and smaller than π. The value of fieldOfView represents the minimum viewing angle in any direction axis perpendicular to the view.

It is important to note that such an approach is easily generalized. X3D is an expressive langauage and all user-defined parameters created in the player might be saved as accompanying X3D markup. Nevertheless some state information in a live scene is transient, often depending on preceding user interactions, and thus cannot be persistently saved.

Relevant X3D components include 23 Navigation, 29 Scripting and the Scene access interface (SAI)

Additional considerations

This section lists additional X3D merits relevant to CAD visualization.

Standardization

X3D is already a widely adopted set of ISO/IEC standards. The standards include:

  • the abstract specification of the X3D scene graph semantics,
  • programmable access via the scene access interface,
  • three scene graph encodings (XML, Classic VRML, and Compressed binary), and
  • two language bindings to support scripting and external scene access (ECMAScript and Java).

X3D also has maintained complete backwards compatibility with the Virtual Reality Modeling Language (VRML97), International Standard ISO/IEC 14772-1:1997.

Additional X3D encodings and language bindings can be developed as needed, either for local or standardized use.

The Web3D Consortium also has formal liaison relationships with the following standards organizations. Maintaining Web interoperability is a charter goal for X3D.

Each year Web3D partners with ACM Special Interest Group on Graphics (SIGGRAPH) to cosponsor the annual Web3D Symposium series.

Of particular note to TC184 Visualization Requirements for CAD is that the Web3D Consortium intends to continue our collaboration with Khronos to maximize potential suitability for these capabilities when using Collada and X3D in combination.

Multiple Implementations

Open-source as well as private commercial implementations are available for X3D. Known implementations include

  • Xj3D, Yumetech
  • BSContact, BitManagement
  • Flux Player, Media Machines
  • Vivaty Player, Vivaty
  • Heilan X3D Browser
  • nexus3d
  • instantreality, Fraunhofer
  • FreeWRL, Communications Research Centre – Canada
  • Octaga Player, Octaga
  • X3DToolKit, INRIA
  • libX3D

Numerous Resources

Several thousand X3D example scenes are available on the X3D Resources page, offered under an open-source license.

Excellent books are available for learning X3D and VRML, including online chapters regarding X3D Technical Introduction and X3D Metadata.

Twice each year the Web3D Consortium issues an X3D Showcase DVD for outreach to members and interested individuals.

A continuing list of case studies and announcements demonstrate steadily growing support for X3D.

Intellectual Property Rights (IPR) Considerations

The Web3D Intellectual Property Rights (IPR) Policy is similar to those for many other Web standards, and includes the following key strengths.

  • Royalty Free (RF)
  • Well-defined and rigorous with multiple implementations and numerous example scenes
  • Well-established and proven Web3D Consortium working group process. Membership is required for contributing to the X3D Specification.
  • Working group recommendations are first approved by Web3D members, then sent to ISO for final review.
  • At least two independent implementations are required for each capability
  • Patented IPR can be considered, but only if declared in advance and only if the contributor agrees to offer the patented capability for royalty-free X3D use if accepted

Web3D Consortium membership is unrestricted and open to companies, government agencies, educational institutions.

X3D CAD Component Revision in Progress

The X3D CAD Working Group is adding several significant new capabilities to the X3D CAD Component.

  • BREPS
  • NURBS-based implicit surfaces

Expected timeline:

  • Second-round draft under review, accessible to Web3D Consortium members
  • Penultimate draft working group review and initial implementation at Web3D 2009 Symposium in June 2009
  • Final draft submitted to Web3D Consortium members at SIGGRAPH 2009
  • Upon approval, submission to ISO/IEC JTC 1 SC24

W3C Efficient XML Interchange (EXI)

Web3D Consortium is participating in the Efficient XML Interchange (EXI) working group of the World Wide Web Consortium (W3C). EXI provides near-optimum compression and improved decompression performance of XML.

EXI is in Last Call Working Draft status. The X3D group expects to utilize EXI as an improved future version of the X3D Compressed Binary Encoding. Such a transition will consist of a simple replacement of the currently used ISO Fast Infoset (FI) standard with EXI, with forward compatibility guaranteed via conversion to/from XML.

Acknowledgement

The X3D CAD Working Group is grateful for this opportunity to contribute and will continue to progress. Thanks for all review comments and feedback.

Retrieved from "https://web3d.org./wiki/index.php?title=TC184_Visualization_Requirements_for_X3D_CAD&oldid=4726"