Difference between revisions of "X3D v4.0 CAD Improvements"

Revision as of 18:06, 18 August 2012

This draft document lists proposed changes for a future X3D v3.4 Specification, undergoing consideration and discussion by the X3D CAD Working Group.

X3D browser companies are encouraged to prepare for implementing these changes, in order to take advantage of the many X3D models expected to be produced by CAD exporters.

X3D CAD Component

• Existing specification: X3D v3.3 CAD Geometry Component

Child-node relationships more explicit

• Many parent-child node relationships are vague, leading to difficulty deciding which children are allowed. For example, X3DGroupingNode is implemented by many candidate nodes.
• These relationships are strictly captured in the X3D DTD and X3D Schema, with further support in X3D Schematron
• In order to best support model export and interoperability, the child nodes are limited to those listed in the proposed CADInterchange Profile

Proposed specification prose: needed.

Tesselation consistency

• Exporters can significantly reduce file size using primitive-geometry nodes (e.g. Cylinder, Disk2D, etc.)
• Tesselation quality is not strictly defined in X3D
• In order to match polygonal tessellation strictly and avoid "cracks" between adjacent geometry, some form of association is needed (similar to the NURBSet node)
• All CAD geometry appears inside a CADPart node, typically one-by-one within child CADFace nodes
• CADPart is a natural node for this functionality. Node semantics can be improved to include this constraint.

Proposed specification prose: needed.

X3D CADInterchange or CADInteractive Profile?

The existing CADInterchange profile definition was designed to be as minimal as possible to exchange geometry between systems.

• Existing specification: X3D v3.3 CADInterchange profile

Improvements and additions are possible to match the evolved understanding and improved practices of CAD to X3D export.

• Primary discussion: revising CADInterchange profile email thread

We also want to be sensitive to the possible addition of X3D export within CAD tools, making that implementation step practical for them. Construction of exporters is a good estimate of complexity for those efforts.

Planned improvements to a CAD profile require a number of changes to the list of supported nodes.

Nodes to add CAD geometry support

FillProperties

• Definitely needed for proper display to distinguish different parts or selected parts. Related to definition of component levels in the profile.

IndexedFaceSet

• Commonly used node, adds more flexibility to authoring/exporting.
• No negatives noted.

MetadataBoolean

• Needs to be added to list for consistency with other metadata nodes.

OrthoViewpoint

• The primary purpose of OrthoViewpoint is to support common use cases for CAD model viewing. (This node was probably added after the initial CAD profile.)

NURBS component nodes

• These nodes both support the thorough export of CAD models to X3D without requiring fixed-resolution polygonal tessellation.
• Parametric surfaces are exact and much much terser than polygons. This is analogous to vector graphics versus pixel graphics.
• Current practice building exporters has shown that availability of NURBS is sufficient to handle the expressiveness of CAD B-REPS as well.

Geometry2D component nodes and Geometry3D component primitive nodes: Box Cone Cylinder Sphere.

• Addition of these nodes facilitates many common CADPart/CADFace

constructs, also resulting in smaller X3D file exports.

• No significant computational cost to browsers.
• Although the circular nodes require run-time tessellation, these 2D/3D primitive nodes are all simple to implement.

ViewpointGroup

• Allows nesting of Viewpoints within models without exploding or overloading the Viewpoint list, which is an essential tool for user navigation.

Nodes to add CAD interactivity

Tools can take advantage of the semantics provide by the CAD product structure to provide many interaction techniques that do not require author scripting. Because a variety of use cases exist, such as viewing or maintenance or checking availability or ordering, the working group may want to explore them in further detail.

Anchor]

• Needed for description and Viewpoint selection (level 1)
• Also needed for linking to other networked resources (level 2)

Inline

• Needed for modular re-use of CAD-model files
• Concern: possibility of short-circuiting CAD product structure within an extended file. Related future specification change:

 Any node children created by Inline, ProtoInstance or Script
 (via a createX3D method ) need to produce a scene graph that
 follows allowed CAD product structure as defined in this component.

Nodes to remove

The following nodes no longer appear to be needed (or at least very questionable).

Shader component

• Because shaders are specific to individual GPU languages and not portable across different platforms, they do not add consistent value.
• A related factor is that Script techniques, animation and events do not appear elsewhere in this profile.
• The level of abstraction and functionality provided by shaders are completely different from other CAD export.
• Not a common use case.

Conclusion: take it out. Authors that want it can add shaders via a <component> statement for deliberate use on compatible players.

Multitexture nodes

• Are there common use cases for multitexture with CAD nodes?
• Many models considered to have multiple textures, allows more concise storage and selection.
• Environmental maps allow reflection.
• Cost of implementation is not great since this capability is commonplace on graphics cards, and multiple X3D players already support it satisfactorily.
• Important for high-quality presentation so that CAD export was considered valuable.
• Considered a sufficiently common use case to warrant inclusion. Conclusion: keep it in.

Nodes considered for inclusion but not accepted

Extrusion

• No, controversial, can produce ill-defined geometry and adds computation cost.

ElevationGrid

• Produces often-ambiguous quadrilateral geometry
• No common use case, does not add real value.

Text

• This is a primitive geometry node but inclusion is questionable, since it is used for presentation rather than for CAD modeling.
• A common use case is labeling dimensions, which will likely be better served by implementing the Annotation Component together with the X3D Medical Working Group.

Profile renaming or addition?

Extensive changes to this profile may make backwards compatibility difficult. X3D profiles do not support a concept of level as components do.

• Should the profile be renamed for clarity, maintaining the old profile separately?
• Alternatively should the old profile be deprecated?
• Is there a better way to express this evolution, simply noting that the v3.4 version of the CADInterchange profile is different?