[Source] minutes for CAD meeting, 11 JAN 2012: BREP-NURBS, X3D spec, instant reality, Xj3D, examples

[Don Brutzman]

1.  Happy polygonal or parametric New Year, as you prefer.  8)

2.  Attendees:  Hyokwang Lee, Vince Marchetti, Dick Puk, William
Glascoe, Don Brutzman.

Names used in vain:  Yvonne Jung, Alan Hudson, Justin Couch, and
Terry Norbraten.

Time-zone regrets but still paying attention:  Marc Petit and
Christophe Mouton.

Also cc:  source at web3d.org since some Xj3D bugs are discussed here.

3.  Biggest point, which has a major potential impact for this group
and Web3D, was made by Vince.  Summary:
- it appears that X3D NURBS and trimmed NURBS nodes provide everything
	needed for rendering B-REP nodes.  In some cases, polygonal
	nodes (triangles, quadrilaterals, perhaps even Extrusion) is
	possible.
- it also appears that unambiguous mappings from B-REP nodes to NURBS
	(or polygonal nodes) is possible
- if multiple NURBS surfaces are used to render a single B-REP then
	NurbSet node can be used to ensure correction tessellation
	(and hopefully smooth rendering of adjacent surface edges.
- any additional data found in a B-REP node (or a STEP definition)
	not related to rendering might nevertheless be optionally
	retained in an X3D scene through use of Metadata nodes.
	However this is probably just a notional or debugging
	capability for development tools, since the results can be
	so voluminous.

Not yet agreed upon:  is the common tessellation of adjacent surfaces
sufficient to get consistent smooth rendering across the edge of the
two surfaces.  We might need to add prose to 27.4.9 NurbSet about
that...  Or maybe it is taken care of by the underlying rendering
mode of the graphics card, or even taken care of by the browser
thanks to the unambiguous parametric definition of the surfaces.

This is pretty important.  B-REP is a close match for most ISO STEP
files.  It therefore appears that we will not need to represent B-REP
in X3D.  More thinking and examination will follow.  Vince will be
posting more details about his thinking as a followup.
[Also see last entry in these minutes.]

The already-approved NURBS component is a much smaller implementation
footprint than B-REP.  NURBS also might be possible on mobile devices...
but it is certainly possible to write NURBS-to-triangle converters that
can render satisfactorily on mobile devices (computation size versus
file size tradoff).


4.  Instant Reality problems.  Today we are discussing Vince's white paper

	X3D Rendering of NURBS surfaces:
	Example models and browser support

	http://kshell.com/pages/nurbs_surface_demo

He has found some inconsistencies/problems with the InstantReality
implementation of NurbsPatchSurface and NurbsTrimmedSurface,
the (u,v) coordinates appear transposed.  He has compared these
against 3 other implementations and analyzed the spec in detail.

X3D specification for NURBS, which describes (u,v) coordinates:
http://www.web3d.org/files/specifications/19775-1/V3.2/Part01/components/nurbs.html

X3D specification for textures, which describes (s,t) coordinates:
http://www.web3d.org/files/specifications/19775-1/V3.2/Part01/components/texturing.html#Texturecoordinates

Possibly (u,v) coordinates aren't mapped correctly to (s,t) coordinates.
Another (maybe remote) possibility is that there is "twist in the knickers"
from the implementation of the solid="true" field.

cc: Dr. Yvonne Jung said that Fraunhofer has looked at this before...
can you please discuss with us?  if your approach is correct, then
can you help us identify the clause in the specification that might
be considered ambiguous and handled differently by other implementations?


5.  Wondering who has the source for the figures in the NURBS component?
Alan or Justin?  We need them, in X3D or whatever format.  Example image:
http://www.web3d.org/files/specifications/19775-1/V3.2/Part01/components/nurbs.html#f-NurbsSwungSurface

Spec issues:
- the red, green, blue axes are likely X Y Z, as shown in Figure 27.4
- Figure 27.1 — NurbsCurve, Figure 27.4 — NurbsSwungSurface missing X Y Z
- Figure 27.3 — NurbsSweptSurface is missing "x" label

- Figure 27.3 — NurbsSweptSurface is a very complicated example and hard to
	visualize.  The image does not show the resultant surface, only showing the
	following curves and not distiguishing which curve is which.
  SFNode [in,out] crossSectionCurve []   [X3DNurbsControlCurveNode]
  SFNode [in,out] trajectoryCurve   []   [NurbsCurve]

- Similarly Figure 27.4 — NurbsSwungSurface is a very complicated example and hard to
	visualize.  The image does not show the resultant surface, only showing the
	following curves and not distiguishing which curve is which.

  SFNode [in,out] profileCurve      []   [X3DNurbsControlCurveNode]
  SFNode [in,out] trajectoryCurve   []   [X3DNurbsControlCurveNode]

- All of these examples (or something with similar node coverage) probably
	need to go in the informative Examples annexes of each of the
	encodings (.x3d .x3dv .x3db).

- Some discussion about "soup sandwich" followed...   8)
	http://www.urbandictionary.com/define.php?term=soup%20sandwich


6.  Here are the existing Web3D NURBS examples:
http://www.web3d.org/x3d/content/examples/Basic/NURBS/

Vince also has some interesting examples.  will add Vince's examples
to this archive, with full credit and normalized naming and license.
This will be a good opportunity to further check X3D-Edit support for
NURBS nodes is correct.

i suggest we should all test & decide which NURBS scenes are correct,
fix where appropriate, and then advertise them to the browsers to
start achieving common conformance.  That will also help to resolve
which browser approaches are agreed upon as correct.

Please note that autogenerated Xj3D screen snapshots of each scene
viewpoint are (supposed to be) presented as a slideshow.  Unfortunately
all the viewpoint images there are either black or empty, indicating
that Xj3D isn't rendering them properly.
http://www.web3d.org/x3d/content/examples/Basic/NURBS/viewpointSlideshow.html

Vince reports that the NURBS code is disabled in the Xj3D branch
maintained by NPS...  didn't know that.  Alan, Justin, Terry,
can we turn those back on?  Or at least document bugs?


7.  Other work on X3D binary implementations reported separately.
Regardless of how the MPA/STEP/B-REP analysis comes out and resolves,
it remains imperative that we do all of the housekeeping necessary
to ensure that our examples, compression and model interoperability
are all working properly.


8. Future teleconference topic:  comparing Macro Parametric Approach
and Constructive Solid Geometry (CSG) to ISO STEP and B-REPs.  We
are optimistic that this might fill in the final gaps as we work
to verify the overall Web3D CAD Working Group strategy for X3D.


9.  Hyo reports that there will be a workshop on MPA at KAIST iCad
lab in Daejeong Korea on 31 January.  He hopes to discuss these
points there.  It will be great to get their consideration and
feedback pro/con/otherwise.


10.  Thanks Vince, Hyo and everyone for the continued huge progress.
We are nudging big boulders, achieving slow-but-steady forward motion.
Happy Year of the Dragon!

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