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


Proposal:  I will send Defect Report Number 8632:1999-1/001 to Dick Puk and 
ask him to expedite it through SC24.

This should close the topic of NUBS/NURBS defect processing.  According to 
Dick, best case will be 1 month for SC24 completion, worst case will be 3 
months.

I suggest that tomorrow (Wed.) telecon is the drop-dead for objections to 
this proposal to finish the defect correction.

Regards,
-Lofton.


At 01:14 PM 9/6/2005 -0600, Fuhr, Richard D wrote:
>[...Forwarding for Richard, who can't write to the TC list yet...]
>
>To answer your questions below.
>
>1.  The proposed "better description" that I sent out last week (copied
>below) was intended to merely be informatative and non-technical for the
>purpose of communicating to the people on this mailing list, and would
>not need to be incorporated into future versions of the CGM
>specification itself. If someone had implemented B-splines per "CGM:1999
>plus def1999_1-001", the proposed "better description" would not require
>changes to implementation (viewer, authoring tool, etc)?
>
>2.  The Defect Report Number 8632:1999-1/001 (a.k.a def1999_1-001) does
>need to be incorporated in future versions of the CGM specification.
>
>Regards,
>
>Richard Fuhr
>
>-----Original Message-----
>From: Lofton Henderson [mailto:lofton@rockynet.com]
>Sent: Sunday, September 04, 2005 11:33 AM
>To: Fuhr, Richard D; cgmo-webcgm@lists.oasis-open.org
>Subject: RE: [cgmo-webcgm] problems with NUBS
>
>We're close on nailing the defect resolution(s).  One final question for
>Richard.
>
>At 09:55 AM 9/1/2005 -0700, Fuhr, Richard D wrote:
> >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. [...cut...]
>
>I'm limiting this message to Defect correction.  We can handle
>keep-remove decision separately.
>
> >[...]
> >1.  The ATA and WebCGM profiles should require clamped splines, since
> >the Model Profile does.
>
>Everyone seems to agree here.
>
>Although there is a transcription error in the MP column of the PPF, the
>ATA profile (which allows nurbs) normatively specifies that the MP
>values are per CGM:1999 Annex I (and the MP column of the ATA profile is
>informative).  Same with WebCGM 1.0 (which didn't allow NURBS), and
>WebCGM 2.0 2nd CD draft (which presently does allow them).
>
>Plus, everyone *wants* clamped.
>
>
> >2.  We did indeed submit a defect report but it somehow did not get
> >incorporated into the spec.
>
>Right.  I have attached a copy.  Dick Puk (SC24/WG6) says it will take
>1-3 months to expedite this through SC24.
>
> >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.
>
>Okay, so considering only Rob's original comment about the divergence
>between this current CGM:1999 text and the old defect report (1-065,
>against the previous CGM:1992 text) ... strictly speaking, nothing needs
>changing in CGM:1999 text, for accuracy and correctness.
>
>Is that right?
>
> >     Regarding the interval over which the basis functions evaluate to
> > non-zero, it would be better to describe the property a bit
>differently.
>
>To clarify, is the proposed better description (see below):
>
>1.) informative and non-technical?  [Editorial clarification]
>
>2.) normative and technical?  [Technical defect fix.]
>
>I.e., if someone had implemented B-splines per "CGM:1999 plus
>def1999_1-001", would the proposed "better description" require changes
>to implementation (viewer, authoring tool, etc)?
>
>
> >     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).
>
>Can you phrase this as exact wording for a defect correction?  I.e.,
>looking at CGM:1999, 6.6.10.1.2, it looks to me like you're addressing
>the
>4 equations that recursively define the basis functions B[i,k] (bottom
>of
>p.49 in my ISO edition of CGM:1999).
>
>What, exactly, would change in those current basis function definitions?
>
> >     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,
>-Lofton.
>
>




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