[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

*Subject*: **FW: [cgmo-webcgm] problems with NUBS**

*From*:**"Cruikshank, David W" <david.w.cruikshank@boeing.com>***To*: "CGM Open WebCGM TC" <cgmo-webcgm@lists.oasis-open.org>*Date*: Thu, 1 Sep 2005 10:17:28 -0700

I think Dick was not able to send to the list...we'll get him registered. Here are his comments on the NURS/NURBS issues Thx...Dave -----Original Message----- From: Fuhr, Richard D Sent: Thursday, September 01, 2005 9:55 AM To: Cruikshank, David W; 'cgmo-webcgm@lists.oasis-open.org'; lofton@rockynet.com Subject: RE: [cgmo-webcgm] problems with NUBS Here are my thoughts on the issues below. *. While NUBS and NURBS are certainly not required for WebCGM 2.0, they offer the following benefits. A - Since a cubic NUBS curve can be exactly represented by a Polybezier element, the appearance of such a curve would be the same, whether one is using a cubic NUBS or its Polybezier equivalent. However, the behavior under subsequent editing would be different under the two representations. With a NUBS curve, the level of derivative continuity where two polynomial components join together is enforced by the multiplicity of the corresponding knot. With a Polybezier representation, it would be more difficult to enforce this attribute. B - NURBS curves that have varying weights can not be exactly represented by Polybezier elements. While they could be approximated by other elements (or represented exactly as piecewise conics, if that's what they are), these approximations would still not behave the same under editing as would the original NURBS curves. So, one question to ask in regard to the above is: should WebCGM be able to accurately represent editing behavior as well as appearance? If so, then there is a useful role for NUBS and NURBS. 1. The ATA and WebCGM profiles should require clamped splines, since the Model Profile does. 2. We did indeed submit a defect report but it somehow did not get incorporated into the spec. 3. In section 6.6.10.1.12 of ISO/IEC 8632-1 Second Edition 1999-12-15, the recursive definition of B-splines uses the half-open interval T[i] <= t < T[i+k] and I believe this is correct. Regarding the interval over which the basis functions evaluate to non-zero, it would be better to describe the property a bit differently. Let J be the CLOSED interval = {t : T[i] <= t <= T[i+k]}. Then the B-spline basis function B[i,k] is zero OUTSIDE this interval, it is positive in the OPEN interval K = {t : T[i] < t < T[i+k]} and it may be either 0 or positive at the end points of the closed interval J (this depends upon the particular basis function and the particular knot sequence). Informally speaking, for those B-spline basis functions whose graphs look like bell-shaped curves, the values of the basis functions are zero at each end of the closed interval J. However, the first and last basis functions defined over a clamped knot sequence (i.e., one having knot multiplicity equal to degree+1 at the start and end of the sequence) attain values of 1.0 at, respectively, the first and last point of the interval J. Regards, Richard Fuhr P.S. At the moment, I do not think I am on the mailing list 'cgmo-webcgm@lists.oasis-open.org', so if you have questions or comments, could you please send them to richard.d.fuhr@boeing.com or reply to this e-mail message. -----Original Message----- From: Cruikshank, David W Sent: Wednesday, August 31, 2005 3:49 PM To: Fuhr, Richard D Cc: 'cgmo-webcgm@lists.oasis-open.org' Subject: RE: [cgmo-webcgm] problems with NUBS Dick, Here's the email thread on NUBS/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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]