Subject:
|
Re: BFC: LITS 2
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Sun, 2 Apr 2000 23:12:22 GMT
|
Reply-To:
|
rui.martins@link.pt&Spamless&
|
Viewed:
|
1557 times
|
| |
|
|
> Second in a series, collect them all...
>
> Hmm. I don't think there was much more discussion about whether every
> file should have an explicit 0 BFC CCW CLIP statement, or not. The
> current proposal provides for default values.
I agree with the default from the start, I proposed them, somewhere !
> At the least, the standard should say, "the BFC options must be
> explicitly declared in each file. If a file has an invalid declaration,
> the rendering engine should assume X and Y."
Agreed! but that's NOT currently written that way, is it ?
> In <http://www.lugnet.com/cad/dev/?n=3195>, Rui wrote:
>
> > check the following two statements:
> > ---------------------------------------------------------------------------
> > > To make this standard useful and effective, the LDraw parts library
> > > must be updated to follow the new standard. Since it would be difficult to
> > > rewrite the entire library in one update, the standard will allow for a
> > > mix of extended and unextended files in one rendering.
> >
> > ---------------------------------------------------------------------------
> > > 2 Allowable Clipping. A subfile can only have clipping applied when the
> > > 2 following conditions apply:
> > > - All superfiles are certified.
> > > - The current file is certified.
> > > 2 - No superfile has disabled clipping prior to referencing this
> > > 2 subfile.
> >
> > ---------------------------------------------------------------------------
> >
> > Allows a mix of extended and unextended files in one rendering, but
> > to allow clipping, all files, have to be certified !?!?
>
> This is an issue of language in the document. The second quoted passage
> was updated to read:
NO it is NOT ! read on.
>
> |4 Clipping. It must be possible for a file to enable and disable clipping. But
> |4 even when clipping is enabled locally, it may not be possible to perform
> |4 clipping on the file in some circumstances. Any file will have clipping
> |4 applied only when the following conditions apply:
> |4 - All superfiles (in the current reference branch) are certified.
> |4 - The current file is certified.
> |4 - No superfile has disabled clipping prior to referencing this
> |4 subfile.
> |4 Unless all of these conditions are met at the time a subfile is rendered,
> |4 no clipping is possible.
I know that the branch only would be required, but I don't agree with
this, it's too restrictive, withou need for it.
> > > In some cases, it may be desirable to assume that a file is
> > > right-sideout, (and therefore clippable) even though not all superfiles
> > > are certified. One obvious example is files in the ldraw\parts
> > > directory.
> >
> > This paragraph is another one, sorry to say this, but IMHO
> > this paragraph it's a mess. (Could someone explain better !?)
>
> This section was rewritten as:
>
> |7 Assumed inversions. Generally, it is not possible to assume that a subfile
> |7 is inverted or normal (which is the reason for the 0 BFC INVERTNEXT meta-
> |7 statement). One important special case is this: model files do not invert
> |7 part files. Parts are complex files which would be essentially useless if
> |8 they were inverted. Assuming part files are never inverted allows
> |9 the rendering engine to apply BFC-processing on these parts (assuming the
> |9 parts are certified), even if the calling files aren't certified.
> |7
> |7 No assumptions can be made about models which make direct use of primitives
> |7 or polygon commands, so a rendering engine should not simply treat uncertified
> |7 model files as certified.
More processing clutter ! Undesirable
> > In my opinion the language extensions should be written with curly
> > braces '{' '}' instead of '[' ']', because the later means optional
> > parameter and the previous means compulsory parameter with possible
> > options if the pipe '|' is used.
>
> The syntax-spec is currently written as:
>
> |4 Syntax:
> |4 0 BFC [CERTIFY|NOCERTIFY] [CLIP|NOCLIP] [CW|CCW|NOWIND] [INVERTNEXT]
>
> Each of the parameters is optional. There are no required parameters.
> If a BFC meta-statement carried no parameters, then it would have no
> effect.
I obviously agree.
> > > UNKNOWN = winding direction is unknown or variable. This setting will
> > > disable clipping, until the winding is reset.
> >
> > Using someones expression, the UNKNOWN is 'syntatic sugar', because this
> > will be implemented internally as CLIPPING OFF.
> > If the user want's to inform that the 'winding' is not known,
> > then he can make a regular comment, and use CLIPPING OFF
>
> In <http://www.lugnet.com/cad/dev/?n=3196>, Jacob responded to this
> point:
>
> > This sounds correct, but do we want to eliminate this
> > syntactic sugar?
>
> And, in <http://www.lugnet.com/cad/dev/?n=3208>, I also provided:
>
> > Yes. WINDING UNKNOWN allows a DAT author to specify what is happening in the
> > file more precisely than CLIPPING OFF. Adding WINDING DOUBLE-SIDED would allow
> > even more author-precision, but there is no practical difference between
> > DOUBLE-SIDED and UNKNOWN, AFAIK.
> >
> > There is a slight practical difference between WINDING UNKNOWN and CLIPPNG OFF
> > -- WINDING is a file-specific setting; the file's author can assume that they
> > always know the current WINDING setting. CLIPPING is passed down the reference
> > branch, and the current file should make *as few* assumptions about the CLIPPING
> > setting as possible.
First, Use comments, instead of clutering the BFC extension, and
disable CLIP in the section.
Second if the "All branch must have cliping on to BFC" was NOT used, ideia
which I'm in favour, then no cliping info would be passed to references.
> In <http://www.lugnet.com/cad/dev/?n=3211>, Lars wrote:
>
> > Also there should be some words about using 0 CLIPPING OFF for a
> > double-sided
> > section of a file.
Use comments, not Meta-commands, they will inder performance if use when
NOT absolutly required.
> This is an open issue. It's noted at the end of the document. That
> should be moved to the top.
BIG Open Issue ! wouldn't you say ?
It affects the entire way of processing files!
see ya
Rui Martins
|
|
Message has 1 Reply:
 | | Re: BFC: LITS 2
|
| (...) No, it isn't. BUT, there is very little functional difference between what is currently written and the suggestion above. As far as the function of a rendering engine is concerned, there is no difference -- if a file doesn't specify the (...) (24 years ago, 3-Apr-00, to lugnet.cad.dev)
|
Message is in Reply To:
| | Re: BFC: LITS 2
|
| Second in a series, collect them all... (...) I believe the language around the 'defaults' has been cleared up sufficiently. (...) Hmm. I don't think there was much more discussion about whether every file should have an explicit 0 BFC CCW CLIP (...) (24 years ago, 31-Mar-00, to lugnet.cad.dev)
|
24 Messages in This Thread:
  
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
