RE: [cgmo-webcgm] problems with NUBS

["Cruikshank, David W" <david.w.cruikshank@boeing.com>]

 Dick,

Here's the email thread on HUBS/NURBS, so you can add your input and reply to all.

Thx...Dave

-----Original Message-----
From: Lofton Henderson [mailto:lofton@rockynet.com] 
Sent: Tuesday, August 30, 2005 9:21 AM
To: cgmo-webcgm@lists.oasis-open.org
Subject: RE: [cgmo-webcgm] problems with NUBS

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.