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

Revision as of 15:12, 17 August 2012

These are proposed changes for a future X3D v3.4 Specification under consideration by the X3D CAD Working Group.

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 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 adjactent geometry, some form of association is needed (similar to the NURBSet node)
• CADPart semantics can be improved to include this constraint

Proposed specification prose: needed.

X3D CADInterchange Profile

The existing definition of this profile no longer meets the evolved understanding and improved practices of CAD to X3D export.

• Existing specification: X3D v3.3 CADInterchange profile
• Primary discussion: 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.

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

Nodes to add

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.

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.
• Text node inclusion is questionable, since it is used for presentation rather than 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.

ViewpointGroup

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

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.

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 profile is different?