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

From Web3D.org
Jump to: navigation, search
m (Child-node relationships more explicit)
(link http://www.web3d.org/wiki/index.php/X3D_version_4.0_Development)
 
(36 intermediate revisions by 2 users not shown)
Line 1: Line 1:
These are proposed changes for a future X3D v3.4 Specification under consideration 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 CAD Component ==
 
== X3D CAD Component ==
Line 7: 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. 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.
  
== X3D CADInterchange Profile ==
+
=== Node refinements ===
  
The existing definition of this profile no longer meets the evolved understanding and improved practices of CAD to X3D export.
+
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]
  
* Existing specification:  [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/CADInterchange.html X3D v3.3 CADInterchange profile]
+
== X3D CADInterchange or CADInteractive Profile? ==
* Primary discussion: [http://web3d.org/mailman/private/cad_web3d.org/2012-August/000191.html revising CADInterchange profile] email thread
+
  
'''X3D browser companies are strongly encouraged to adopt these changes in order to support X3D models produced by CAD exporters.'''
+
The existing CADInterchange profile definition was designed to be as minimal as possible to exchange geometry between systems.
 +
* Existing specification: [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/CADInterchange.html X3D v3.3 CADInterchange profile]
  
Planned improvements to this profile require a number of changes to the list of supported nodes.
+
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.
  
=== Nodes to add ===
+
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.
  
[http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/networking.html#Anchor Anchor]]
+
Planned improvements to a CAD profile require a number of changes to the list of supported nodes.
* Needed for description and Viewpoint selection (level 1)
+
* Also needed for linking to other networked resources (level 2)
+
  
[http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/networking.html#Inline Inline]
+
=== Nodes to add for improved CAD geometry support ===
* 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
+
[http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/core.html#MetadataBoolean MetadataBoolean]
  (via a createX3D method ) need to produce a scene graph that
+
* Needs to be added to list for consistency with other metadata nodes.
  follows allowed CAD product structure as defined in this component.
+
  
 
[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]
* Definitely needed for proper display to distinguish different parts or selected parts. Related to definition of component levels in the profile.
+
* 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 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.
 +
* 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)
  
 
[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]
 
* Commonly used node, adds more flexibility to authoring/exporting.
 
* Commonly used node, adds more flexibility to authoring/exporting.
* No negatives noted.
+
* 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/core.html#MetadataBoolean MetadataBoolean]
+
[http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/nurbs.html#t-Topics NURBS component nodes]
* Needs to be added to list for consistency with other metadata nodes.
+
 
+
[http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/navigation.html#OrthoViewpoint 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.)
+
 
+
[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.
* Parametric surfaces are exact and much much terser than polygons. This is analogous to vector graphics versus pixel graphics.
+
* 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.
 
* 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.
  
[http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/geometry2D.html#t-Topics Geometry2D component] nodes
+
=== Nodes to add for improved CAD interactivity ===
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.
+
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.
* Addition of these nodes facilitates many common CADPart/CADFace
+
 
constructs, also resulting in smaller X3D file exports.
+
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.
* No significant computational cost to browsers.
+
* Interaction capabilities should take advantage of inherent structure and support common CAD usages.
* Although the circular nodes require run-time tessellation, these 2D/3D primitive nodes are all simple to implement.
+
* 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].
 +
 
 +
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)
 +
* 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]
 +
* 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.
 +
 
 +
[http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/navigation.html#OrthoViewpoint 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.
  
 
[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, which is an essential tool for user navigation.
+
* 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 ===
 
=== Nodes to remove ===
Line 82: 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 different platforms, they do not add consistent value.
+
* 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: 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 97: 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. Conclusion: keep it in.
+
* 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, controversial, can produce ill-defined geometry and adds computation 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.
 +
* 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 real value.
+
* 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 114: 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?

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?