[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cgmo-webcgm] problems with NUBS
Rob, excellent summary. 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? Regards, Dieter > -----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. > > 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. > > I'm reluctant to spend any more time on this until these > issues are resolved. > > Regards, > > Rob >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]