[X3D-Public] [Cad] CAD conference call Tuesday; revising CADInterchange profile
brutzman at nps.edu
Tue Aug 14 09:57:10 PDT 2012
Attendees: Hyokwang Lee, Vince Marchetti, Dick Puk, Don Brutzman.
We called France but the entire country is taking the month off.
On 8/13/2012 9:49 PM, Don Brutzman wrote:
> Since it does not look like there is a Declarative 3D call Tuesday,
> Hyo and I are hoping to have a CAD group call 8-9 pacific at the
> regular time on the regular Web3D phone line. Dick can attend too.
> Vince and Marc, can you join us?
> 1. First topic will be to briefly review a number of discussion points
> from SIGGRAPH. All issues are showing forward progress. I can send a
> scan of meeting notes to teleconference participants, we will get the
> details online later. No doubt these will deserve deeper treatment
> on future calls.
Lots of interest by others to follow up on
> 2. Second topic will be to review recent changes to X3D DTD and Schema:
> 14 August 2012, brutzman, Hyokwang Lee
> - CAD nodes not allowed to include Switch (since events not provided by CADInterchange profile)
> or StaticGroup (since reaarrangement/removal of children nodes can break CAD product structure).
> Neither of these nodes are listed in CADInterchange profile.
Guideline should be the both the node signatures (e.g. X3DGroupingNode)
for each CAD node as filtered by (i.e. matching) the component levels
in the CADInterchange profile.
> 11 August 2012, Hyokwang Lee, brutzman
> - CADAssembly is not allowed to include CADFace as an immediate child since that does not match
> CAD product structure as defined in X3D specification clause 32.4.1
> 10 August 2012, Hyokwang Lee, brutzman
> - CADAssembly: allow grouping nodes that make sense for CAD, adding Anchor and Inline to match allowed DTD children
Future work: review whether the CAD component prose needs to be
further clarified and improved.
> 3. Third topic: there are a number of issues with the current
> CADInterchange profile: some valuable/essential nodes are missing,
> and some questionable nodes are included.
> As discussed in recent CAD working group meetings, we are hoping to
> build the list of what nodes/components each browser should implement
> well to support the forthcoming conversion of many CAD models into X3D.
> - Anchor, Inline
- Anchor needed for description and Viewpoint selection
- Anchor needed for linking to other resources
- Inline needed for re-use of CAD files
Related future specification change:
Any node children created by Inline, ProtoInstance or Script (createX3D)
need to follow the CAD product structure defined by their parent nodes.
> - FillProperties
Definitely needed for proper display to distinguish different parts or
selected parts. Related to definition of component levels in the profile.
> - OrthoViewpoint
The primary purpose of OrthoViewpoint is to support common use cases for
CAD model viewing. (This node was probably added after CAD profile.)
> - NURBS component
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. 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 B-REPS as well.
> - Geometry2D component
Also primitive geometry 3D 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 is questionable, it is used for presentation not CAD modeling.
A common use case is labeling dimensions.
Future work: CAD group will work with Medical group to finish the
Annotation component. That is probably the right time to decide
whether to include the Text node or not.
> Not needed (or at least very questionable):
> - Shader nodes (not portable)
Because shaders are not cross-platform, they do not add
consistent value. Scripting techniques, animation and
events do not appear elsewhere in this profile. Level
of abstraction and provided functionality 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 (is there a common use case?)
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.
> Other nodes?
Adds more flexibility to authoring/exporting. No negatives noted.
- Extrusion ?
No, controversial, can produce illegal geometry and adds computation cost.
- ElevationGrid ?
No, ambiguous quadrilateral geometry, not really adding value.
Needs to be added to list for consistency.
Subject to everyone's comments, it looks like we have a significant
set of profile changes here.
> 4. Fourth topic: These proposed changes to CADInterchange Profile
> look to be quite important, so much so that it doesn't make sense to
> recommend the existing CADInterchange Profile to authors or players.
> I expect that we are likely to agree that these changes fix some
> fundamental errors. It will be good to learn from Dick what our
> options are at the upcoming ISO specification review meeting in
> Belgium next week.
It would appear that we are close to achieving Web3D Consortium
consensus on the value and completeness of these profile changes.
If we avoid making changes to X3D v3.1 and v3.2, then we are not
disabling any previously existing X3D content.
Options for version 3.3:
- Might be too late to change Draft International Specification (DIS)
- Not apparent if there is significant v3.3 content using CADInterchange
profile, if so then it would compatible with v3.2
- The changes listed are a significant improvement, while past profile
remains workable/viable for CAD export albeit with limitations
- There are no notions of "level" in a profile, so whatever is defined
as a profile within an X3D version is fixed/final.
- Although shaders are not needed for CAD interchange, their inclusion
is not necessarily harmful.
-- Dick thinks that the use of shader component in the CAD profile has
the potential of interfering with the use of programmable shaders
-- Don thinks that discouraging or eliminating the inclusion of shaders
as part of the CAD profile might be a graceful long-term way to
distance CAD EXPORT from these unneeded nodes.
- Addition to, or revision of, X3D v3.3 DIS does not appear to be possible
at this late date due to ISO procedures.
- We can consider creation of an amendment to version 3.3, which might
become basis of a version 3.4
- We do not want to link this to a major new version 4.0 effort, since
that will be lengthy the improvements could have immediate value
- Dual-tracking next step efforts as an incremental v3.4 and a major v4.0
is a possible strategy.
- New work item proposals (NWIP) can be submitted at any time.
We will think about these possibilities further and discuss them next week
in Belgium with ISO SC24 colleagues.
In the meantime, all Web3D feedback on these technical changes is welcome.
> That is a lot for one hour, but if we review points 1 & 2 quickly
> we should be able to do it.
Elapsed time: 1 hour 57 minutes.
Lots of great discussions during this meeting. Thanks everyone.
all the best, Don
Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu
Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman
More information about the X3D-Public