OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cgmo-webcgm message

[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]