X3D v4.0 CAD Improvements
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.
Tessellation consistency
- Exporters can significantly reduce file size using primitive-geometry nodes (e.g. Cylinder, Disk2D, etc.)
- Tessellation quality is not strictly defined in X3D.
- Polygonal tessellation must be strictly matched to avoid gaps and "cracks" between adjacent geometry (diagram)
- Thus some form of association between shapes is needed (similar to that provided by 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.
Node refinements
There are some CAD-related specification bugs and improvements in the Mantis issue tracker.
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 for improved CAD geometry support
- Needs to be added to list for consistency with other metadata nodes.
- Fundamental for effective presentation and proper display to distinguish different parts (or selected parts).
- TODO (throughout) Related to definition of component levels in the profile.
Geometry2D component nodes and Geometry3D component primitive nodes: Box Cone Cylinder Sphere.
- Low complexity. Circular nodes require simple run-time tessellation, other 2D/3D primitive nodes are trivial to implement.
- Addition of these nodes facilitates many common CADPart/CADFace constructs found in CAD models.
- Significant reduction in output file size.
- No significant computational cost to browsers.
- Allows automation of geometry alignment and identification of collinearity constraints within a CADPart to avoid cracks/gaps.
- Does not include Text node (addressed below)
- Commonly used node, adds more flexibility to authoring/exporting.
- Might be considered more complex than triangle nodes, but IndexedFaceSet is already present in X3D Interchange Profile.
- These nodes both support the thorough export of CAD models to X3D without requiring fixed-resolution polygonal tessellation.
- File size is significantly reduced.
- 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.
- TODO: determine reasonableness of computational cost on small devices utilizing graphics acceleration.
Nodes to add for improved CAD interactivity
A variety of use cases exist for Web publication of CAD models, such as viewing or maintenance or checking availability or ordering. The working group probably needs to explore and define them in further detail.
Players and tools can take advantage of the semantics provide by the CAD product structure to provide many interaction techniques that do not require author scripting.
- Interaction capabilities should take advantage of inherent structure and support common CAD usages.
- Some of the functionality in the X3D Interactive Profile might be needed.
- Is the right design target creation of a CAD Interactive Profile?
- We are tracking these specification possibilities via Mantis issue 529, CADInterchange profile improvements.
The following list provides potential node additions and rationales.
- Needed for description and Viewpoint selection (level 1)
- Also needed for linking to other networked resources (level 2)
- Supports viewing internal sections of models
- This is a common use-case requirement for CAD (documented in our TC184 report)
- This capability was first proposed and accepted during the original phase of CAD Working Group design
- 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 node, ProtoInstance node, or Script (via a createX3D method) needs to produce a resulting scene graph that follows allowed CAD product structure as defined in this component.
- 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; otherwise left out to reduce profile size.)
- Viewpoint is included in CADInterchange Profile, so addition of OrthoViewpoint isn't significantly more complex.
- Allows nesting of Viewpoints within models without exploding or overloading the Viewpoint list.
- This is an essential feature for effective user navigation and selection in large models.
- Viewpoint is included in CADInterchange Profile, so failure to include ViewpointGroup enables those problems to occur.
TODO: Annotation Component.
Nodes to remove
The following nodes no longer appear to be needed (or at least very questionable).
- 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.
- 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
- No (or not yet at least) since somewhat controversial, can produce ill-defined geometry, adds some minor computational cost.
- Can be a very concise way to define geometry, but might be superfluous if NURBS are available.
- Perhaps adding some constraints (e.g. no self-intersecting geometry) might soften bad-geometry issues?
- Produces often-ambiguous quadrilateral geometry.
- No common use case, does not add significant value.
- 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?
- Consider broader community of CAD tools and CAD designers wanting to export... which of these profile options makes sense for them?
