Difference between revisions of "X3D v4.0 CAD Improvements"
m (→Profile renaming or addition?) |
(link http://www.web3d.org/wiki/index.php/X3D_version_4.0_Development) |
||
(24 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
− | This draft document lists proposed changes for a future X3D | + | This draft document lists proposed changes for a [http://www.web3d.org/wiki/index.php/X3D_version_4.0_Development future X3D v4.0 capabilities], undergoing regular 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 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. | ||
Line 9: | Line 9: | ||
=== Child-node relationships more explicit === | === Child-node relationships more explicit === | ||
− | * Many parent-child node relationships are vague, leading to difficulty deciding which children are allowed. | + | * Many parent-child node relationships are vague, leading to difficulty deciding which children are allowed. For example, [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/group.html#X3DGroupingNode X3DGroupingNode] is implemented by many candidate nodes. |
− | * These relationships are strictly captured in the [http://www.web3d.org/specifications/X3dDoctypeDocumentation3.3.html X3D DTD] and [http://www.web3d.org/specifications/X3dSchemaDocumentation3.3/x3d-3.3.html X3D Schema] | + | * These relationships are strictly captured in the [http://www.web3d.org/specifications/X3dDoctypeDocumentation3.3.html X3D DTD] and [http://www.web3d.org/specifications/X3dSchemaDocumentation3.3/x3d-3.3.html X3D Schema] with further support in [http://www.web3d.org/x3d/tools/schematron/X3dSchematron.html X3D Schematron] |
− | * In order to best support model export and interoperability, the child nodes are limited to those listed in the proposed CADInterchange Profile | + | * 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: | + | Proposed specification prose: needed. |
− | === | + | === Tessellation consistency === |
* Exporters can significantly reduce file size using primitive-geometry nodes (e.g. Cylinder, Disk2D, etc.) | * 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 ([[:Image:Identical_Tessellation_HyoBrutzman_20120807.pdf|diagram]]) |
− | * All CAD geometry appears inside a CADPart node, typically one-by-one within child CADFace nodes | + | * Thus some form of association between shapes is needed (similar to that provided by the [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/nurbs.html#NurbsSet NURBSet] node) |
− | * CADPart is a natural node for this functionality. | + | * All CAD geometry appears inside a CADPart node, typically one-by-one within child CADFace nodes. |
+ | * [http://www.web3d.org/files/specifications/19775-1/V3.2/Part01/components/CADGeometry.html#CADPart CADPart] is a natural node for this functionality. Node semantics can be improved to include this constraint. | ||
− | Proposed specification prose: | + | Proposed specification prose: needed. |
+ | |||
+ | === Node refinements === | ||
+ | |||
+ | There are some CAD-related specification bugs and improvements in the [http://www.web3d.org/membership/login/mantis/my_view_page.php Mantis issue tracker]. | ||
+ | * [http://www.web3d.org/membership/login/mantis/view.php?id=528 CADPart child changes] | ||
== X3D CADInterchange or CADInteractive Profile? == | == X3D CADInterchange or CADInteractive Profile? == | ||
The existing CADInterchange profile definition was designed to be as minimal as possible to exchange geometry between systems. | The existing CADInterchange profile definition was designed to be as minimal as possible to exchange geometry between systems. | ||
− | * Existing specification: | + | * Existing specification: [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/CADInterchange.html X3D v3.3 CADInterchange profile] |
Improvements and additions are possible to match the evolved understanding and improved practices of CAD to X3D export. | Improvements and additions are possible to match the evolved understanding and improved practices of CAD to X3D export. | ||
− | * Primary discussion: [http://web3d.org/mailman/private/cad_web3d.org/2012-August/000191.html revising CADInterchange profile] email thread | + | * Primary discussion: [http://web3d.org/mailman/private/cad_web3d.org/2012-August/000191.html 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. | + | 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. | Planned improvements to a CAD profile require a number of changes to the list of supported nodes. | ||
Line 43: | Line 50: | ||
[http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/shape.html#FillProperties FillProperties] | [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/shape.html#FillProperties FillProperties] | ||
− | * | + | * 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. | ||
− | [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/geometry2D.html#t-Topics Geometry2D component] nodes | + | [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/geometry2D.html#t-Topics Geometry2D component] nodes and [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/geometry2D.html#t-Topics Geometry3D component] primitive nodes: Box Cone Cylinder Sphere. |
− | and | + | * Low complexity. Circular nodes require simple run-time tessellation, other 2D/3D primitive nodes are trivial to implement. |
− | [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/geometry2D.html#t-Topics Geometry3D component] primitive nodes: | + | * Addition of these nodes facilitates many common CADPart/CADFace constructs found in CAD models. |
− | * Addition of these nodes facilitates many common CADPart/CADFace | + | * Significant reduction in output file size. |
− | constructs | + | |
* No significant computational cost to browsers. | * 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) | ||
[http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/geometry3D.html#IndexedFaceSet IndexedFaceSet] | [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/geometry3D.html#IndexedFaceSet IndexedFaceSet] | ||
Line 57: | Line 65: | ||
* Might be considered more complex than triangle nodes, but IndexedFaceSet is already present in X3D Interchange Profile. | * Might be considered more complex than triangle nodes, but IndexedFaceSet is already present in X3D Interchange Profile. | ||
− | [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/nurbs.html#t-Topics NURBS component | + | [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/nurbs.html#t-Topics NURBS component nodes] |
* These nodes both support the thorough export of CAD models to X3D without requiring fixed-resolution polygonal tessellation. | * These nodes both support the thorough export of CAD models to X3D without requiring fixed-resolution polygonal tessellation. | ||
* File size is significantly reduced. | * File size is significantly reduced. | ||
− | * Parametric surfaces are exact and much much terser than polygons. | + | * 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. | * Current practice building exporters has shown that availability of NURBS is sufficient to handle the expressiveness of CAD B-REPS as well. | ||
− | * TODO: | + | * TODO: determine reasonableness of computational cost on small devices utilizing graphics acceleration. |
=== Nodes to add for improved CAD interactivity === | === 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. | |
− | the | + | * Interaction capabilities should take advantage of inherent structure and support common CAD usages. |
+ | * Some of the functionality in the [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/interactive.html X3D Interactive Profile] might be needed. | ||
+ | * Is the right design target creation of a CAD Interactive Profile? | ||
+ | * We are tracking these specification possibilities via [http://www.web3d.org/membership/login/mantis/view.php?id=529 Mantis issue 529, CADInterchange profile improvements]. | ||
− | [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/networking.html#Anchor Anchor | + | The following list provides potential node additions and rationales. |
+ | |||
+ | [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/networking.html#Anchor Anchor] | ||
* Needed for description and Viewpoint selection (level 1) | * Needed for description and Viewpoint selection (level 1) | ||
* Also needed for linking to other networked resources (level 2) | * Also needed for linking to other networked resources (level 2) | ||
+ | |||
+ | [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/rendering.html#ClipPlane ClipPlane] | ||
+ | * The ClipPlane node lets authors and tools define [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/rendering.html#ClipPlanes Clip planes] for viewing internal sections of models | ||
+ | * This is a common use-case requirement for CAD (documented in our [http://web3d.org/x3d/wiki/index.php/TC184_Visualization_Requirements_for_X3D_CAD#Requirement_12:_Sectioning TC184 report]) | ||
+ | * This capability was first proposed and accepted during the original phase of CAD Working Group design | ||
[http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/networking.html#Inline Inline] | [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/networking.html#Inline Inline] | ||
− | * Needed for modular re-use of CAD-model files | + | * Needed for modular re-use of CAD-model files. |
− | * Concern: | + | * 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. | |
− | + | ||
− | + | ||
[http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/navigation.html#OrthoViewpoint OrthoViewpoint] | [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/navigation.html#OrthoViewpoint OrthoViewpoint] | ||
Line 90: | Line 105: | ||
[http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/navigation.html#ViewpointGroup ViewpointGroup] | [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/navigation.html#ViewpointGroup ViewpointGroup] | ||
− | * Allows nesting of Viewpoints within models without exploding or overloading the Viewpoint list | + | * 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. | * 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. | * Viewpoint is included in CADInterchange Profile, so failure to include ViewpointGroup enables those problems to occur. | ||
− | TODO: | + | TODO: Annotation Component. |
=== Nodes to remove === | === Nodes to remove === | ||
Line 101: | Line 116: | ||
[http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/shaders.html#t-Topics Shader component] | [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/shaders.html#t-Topics Shader component] | ||
− | * Because shaders are specific to individual GPU languages and not portable across | + | * 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. | * 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. | * The level of abstraction and functionality provided by shaders are completely different from other CAD export. | ||
* Not a common use case. | * Not a common use case. | ||
− | Conclusion: | + | Conclusion: take it out. Authors that want it can add shaders via a <component> statement for deliberate use on compatible players. |
− | shaders via a <component> statement for deliberate use | + | |
− | on compatible players. | + | |
[http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/texturing.html#MultiTexture Multitexture nodes] | [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/texturing.html#MultiTexture Multitexture nodes] | ||
Line 116: | Line 129: | ||
* Cost of implementation is not great since this capability is commonplace on graphics cards, and multiple X3D players already support it satisfactorily. | * 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. | * Important for high-quality presentation so that CAD export was considered valuable. | ||
− | * Considered a sufficiently common use case to warrant inclusion. | + | * Considered a sufficiently common use case to warrant inclusion. Conclusion: keep it in. |
=== Nodes considered for inclusion but not accepted === | === Nodes considered for inclusion but not accepted === | ||
[http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] | [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] | ||
− | * No | + | * 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? | ||
[http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/geometry3D.html#ElevationGrid ElevationGrid] | [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/geometry3D.html#ElevationGrid ElevationGrid] | ||
− | * Produces often-ambiguous quadrilateral geometry | + | * Produces often-ambiguous quadrilateral geometry. |
− | * No common use case, does not add | + | * No common use case, does not add significant value. |
[http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/text.html#Text Text] | [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/text.html#Text Text] | ||
Line 133: | Line 148: | ||
=== Profile renaming or addition? === | === Profile renaming or addition? === | ||
− | Extensive changes to this profile may make backwards compatibility difficult. | + | Extensive changes to this profile may make backwards compatibility difficult. X3D profiles do not support a concept of ''level'' as components do. |
− | X3D profiles do not support a concept of ''level'' as components do. | + | |
* Should the profile be renamed for clarity, maintaining the old profile separately? | * Should the profile be renamed for clarity, maintaining the old profile separately? | ||
* Alternatively should the old profile be deprecated? | * Alternatively should the old profile be deprecated? | ||
− | * Is there a better way to express this evolution, simply noting that the | + | * Is there a better way to express this evolution, simply noting that the v4.0 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? | * Consider broader community of CAD tools and CAD designers wanting to export... which of these profile options makes sense for them? |
Latest revision as of 22:45, 17 June 2016
This draft document lists proposed changes for a future X3D v4.0 capabilities, undergoing regular 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)
- The ClipPlane node lets authors and tools define Clip planes for 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 v4.0 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?