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

From Web3D.org
Jump to: navigation, search
(avoid monospaced font)
(link http://www.web3d.org/wiki/index.php/X3D_version_4.0_Development)
 
(16 intermediate revisions by 2 users not shown)
Line 1: Line 1:
This draft document lists proposed changes for a future X3D v3.4 Specification, undergoing consideration and discussion by the [[X3D CAD]] Working Group.
+
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 10: Line 10:
  
 
* 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.
 
* 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], with further support in [http://www.web3d.org/x3d/tools/schematron/X3dSchematron.html X3D Schematron]
+
* 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: needed.
 
Proposed specification prose: needed.
  
=== Tesselation consistency ===
+
=== 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.)
* Tesselation quality is not strictly defined in X3D
+
* Tessellation 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)
+
* 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. Node semantics can be improved to include this constraint.
+
* 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: needed.
 
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? ==
Line 31: Line 37:
  
 
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. Construction of exporters is a good estimate of complexity for those efforts.
 
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.
Line 46: Line 53:
 
* TODO (throughout) Related to definition of component levels in the profile.
 
* 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
+
[http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/geometry2D.html#t-Topics 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.
 
* 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
+
* Addition of these nodes facilitates many common CADPart/CADFace constructs found in CAD models.
* Significant reduction in output file size
+
* Significant reduction in output file size.
 
* 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
+
* Allows automation of geometry alignment and identification of collinearity constraints within a CADPart to avoid cracks/gaps.
 
* Does not include Text node (addressed below)
 
* Does not include Text node (addressed below)
  
Line 60: 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] nodes
+
[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. This is analogous to vector graphics versus pixel graphics.
 
* 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: determine reasonableness of computational cost on small devices utilizing graphics acceleration
+
* 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 ===
  
Tools can take advantage of the semantics provide by the CAD product structure to provide
+
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.
many interaction techniques that do not require author scripting.
+
* Such advantages indicate that the wide variety of functionality in the [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/interactive.html X3D Interactive Profile] may (or may not) be needed
+
  
A variety of use cases exist for Web publication of CAD models, such as viewing or maintenance or checking availability or ordering.
+
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 working group probably needs to explore them in further detail.
+
* 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: possibility of short-circuiting CAD product structure within an extended file. Related future specification change:
 
* Concern: possibility of short-circuiting CAD product structure within an extended file. Related future specification change:
  
Line 92: 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: Annotation Component
+
TODO: Annotation Component.
  
 
=== Nodes to remove ===
 
=== Nodes to remove ===
Line 108: Line 121:
 
* Not a common use case.
 
* Not a common use case.
  
Conclusion: take it out. Authors that want it can add
+
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 124: Line 135:
 
[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 (or not yet at least) since somewhat controversial, can produce ill-defined geometry, adds some minor computational cost.
 
* 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
+
* 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?
 
* 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 significant value.
 
* No common use case, does not add significant value.
  
Line 137: 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 v3.4 version of the CADInterchange profile is different?
+
* 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

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.

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

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

MetadataBoolean

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

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.

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)

IndexedFaceSet

  • 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.

NURBS component nodes

  • 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.

The following list provides potential node additions and rationales.

Anchor

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

ClipPlane

  • 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

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 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.

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; otherwise left out to reduce profile size.)
  • Viewpoint is included in CADInterchange Profile, so addition of OrthoViewpoint isn't significantly more complex.

ViewpointGroup

  • 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).

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 (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?

ElevationGrid

  • Produces often-ambiguous quadrilateral geometry.
  • No common use case, does not add significant 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 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?