RE: [cgmo-webcgm] problems with NUBS

[Lofton Henderson <lofton@rockynet.com>]

At 07:53 AM 8/30/2005 +0200, Dieter  Weidenbrück wrote:
>[...]excellent summary.

Yes, thanks Rob!

>To make a long story short:
>
> > question: "Are NUBS and NURBS absolutely required for WebCGM
> > 2.0?"
>No, no, and no.
>
>And I strongly suggest to eliminate them in front of this situation.
>This does not mean that we don't have to resolve the issues with
>CGM:1999, however, this won't happen before WebCGM 2.0.
>
>Does anybody object to removing the NUBS/NURBS from the CD?

[Dave, I think this wants to be on next Agenda.
All -- please circulate opinions by email, prior to telecon.]

I don't feel strongly -- it's more or less a user call.  Having said that, 
if the defects mean that implementations are all over the map and won't 
interoperate, then deferring NUBS & NURBS is probably sensible.  It is hard 
to tell, how long it will take to sort this out.

More embedded...

> > -----Original Message-----
> > From: Robert Orosz [mailto:roboro@AUTO-TROL.com]
> > Sent: Tuesday, August 30, 2005 2:13 AM
> > To: 'cgmo-webcgm@lists.oasis-open.org'
> > Subject: [cgmo-webcgm] problems with NUBS
> >
> > All,
> >
> > I've spent the better part of the past two days trying to
> > fulfill one of my action items, namely, generate a CGM file
> > with NUBS in it for the test suite.  Along the way, I've
> > encountered a number of problems which lead me to ask the
> > question: "Are NUBS and NURBS absolutely required for WebCGM
> > 2.0?"  If the answer is yes, then there are some problems
> > which need to be worked out.  I'll describe the issues below
> > in the order that I encountered them.
> >
> > 1) Profile should require clamped splines.  This one is easy
> > and appears to be resolved; the Model Profile as specified in
> > the WebCGM 2.0 draft profile PPF does not specify that
> > splines should be clamped.  This is apparently a
> > transcription error and will be corrected.  Interestingly,
> > the ATA made the exact same error.
> >
> > 2) The parameter end value parameter.  I had a recollection
> > that the NUBS specification in CGM92 had a defect, namely,
> > that the parameter end value was incorrectly specified to be
> > less than the n-th knot value.  Since CGM99 was supposed to
> > have all of the defect corrections in place, I looked at the
> > NUBS specification in CGM99.  I was dismayed to discover that
> > it was unchanged with respect to the parameter end value
> > parameter of NUBS and NURBS.  I then went searching for that
> > defect report (8632-1/065).  This was frustrating at first
> > until I discovered that Lofton is an excellent document
> > repository!  He sent me a copy of that report.  I read it and
> > was dismayed to discover that it too was unchanged with
> > respect to the parameter end value parameter of NUBS and
> > NURBS.  So, that probably explains why CGM99 had no changes
> > for parameter end value.  Other changes from 8632-1/065 are
> > incorporated into CGM99.
> >
> > Lofton then sent me another defect report (8632:1999-1/001)
> > which addresses the issue of the parameter value.  It states
> > that the end value shall be less than or equal to the (n+1)st
> > knot value.  However, he does not know the status of this
> > defect report.

Right.  This is another case where our liaison w/ SC24 failed in the years 
around 1999.  (I won't name names!  Okay ... actually, I must share the 
responsibility with our former SC24 Liaison officer.)

With SC24, I'm now trying to actively sort out the Registry problem.  I 
will follow up with this one -- we apparently prepared a defect report, but 
possibly it didn't go anywhere.

> >
> > 3) Interval over which the higher order basis functions are
> > non-zero.  I noticed this discrepancy while reading
> > 8632-1/065.  It states that the interval over which the
> > higher order (k > 1) basis functions evaluate to non-zero is
> > T[i] <= t <= T[i+k].  However, CGM99 gives the interval as
> > T[i] <= t < T[i+k].  So, B[i,k](t) = 0 when t = T[i+k}
> > according to CGM99.  It does not equal 0 according to the
> > 8632-1/065 defect report, and you must evaluate the two terms
> > in the basis function to obtain the value.
> >
> > The 8632-1/065 defect report states: "The CGM defects editor
> > has convened an ad hoc committee of NURBS and CGM experts.
> > ...", so that tends to make me believe it over CGM99.
> > However, I'm not a NURBS expert myself, so I have no idea
> > which is correct.  It's possible that the numerators of the
> > two terms in the basis function evaluate to 0 when t = T[i+k]
> > in which case there is no discrepancy.  I haven't checked
> > this possibility.  Like I said, I'm not a NURBS expert.

This sounds familiar.  Dave, is this the issue that we worked out with 
Richard Fuhr?  Or was that worked out earlier and incorporated into 
CGM:1999 (8632-1/065), and then visited again (8632:1999-1/001)?

Long story short, Dave, do you have access to a NURBS expert who can answer 
these questions for us?  (I guess the only real question is #3, as #1 seems 
agreed [clamped], and #2 appears to be a bona-fide erratum whose processing 
got derailed.)

Regards,
-Lofton.