Subject:
|
Re: Line in the Sand
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Sun, 5 Dec 1999 01:02:13 GMT
|
Viewed:
|
2212 times
|
| |
|
|
Sorry this is so long. I've tried to err on the side of quoting too much of
Lars' message, rather than too little. Also, I've tried to be thourough in my
replies.
In related news, I've added a 'Current Issues' section at the top of the v4
document. During development of the BFC standard, the issues section will be
maintained to list all known issues (as of the time a version of the document is
published). Before publishing the standard, the Current Issues section must be
empty. So all issues must either be resolved, or the standard must be written
to accomodate both sides.
In the case of a *completely* irreconcilable issue, we may to write the issue
into the standard, and allow it to be resolved by the first rendering engine
that supports BFC clipping. This would be a Very Bad Thing, but not As Bad as
not publishing a standard.
I use names in the Current Issues section so that readers will know who is
taking a stand on what. And to help me keep things straight. I don't want to
take discussions onto any personal levels, and I will try to write the Current
Issues in an impersonal, unbiased voice.
Basically, in any situation where someone (other than me) says, "things should
be done this way", and I say "no, they shouldn't" or "I don't have an opinion on
that", I'll add that to the Current Issues.
In lugnet.cad.dev, Lars C. Hassing wrote:
> Steve Bliss wrote...
> > Still discussing:
> > <http://www.geocities.com/partsref/bfcspec.txt>
> > and now
> > <http://www.geocities.com/partsref/bfcspecv4.txt>
>
> I prefer the newer with only one new meta-statement. This easily
> identifies commands related to BFC.
> However, the syntactical change doesn't solve the discussion about
> the CERTIFY option, see later.
True, the single-statement approach doesn't solve the problem with CERTIFY. I
was hoping it would at least skirt the issue, and allow us to go on.
By de-emphasizing CERTIFY, and not requiring it, but still keeping it in the
standard, we could agree to allow some redundancy for the sake of getting a
standard published. And give authors some leeway to choose their approach.
It's not an ideal approach to a solution, but better than wrangling over
non-functional details forever.
> I have some suggestions for bfcspecv4.txt:
> > 3 Certified. A DAT file is certified if it complies with the specifications
> > 3 in this document, and includes a 0 CERTIFY BFC statement.
> "0 CERTIFY BFC" should be "0 BFC CERTIFY"
OK. I changed it to:
3 Certified. A DAT file is certified if it complies with the specifications
6 in this document, includes a 0 BFC statement before the first operational
6 command, and does not contain a no 0 BFC NOCERTIFY statement.
> > 4 Control of the compliance/non-compliance state will only affect the current
> > 4 file. Subfiles will be affected indirectly, because it is not possible to
> > 4 clip subfiles of non-BFC files, but the compliancy of the subfiles will not
> > 4 be affected.
> You could add: "i.e. it is not possible to clip a BFC subfile when
> it is referenced by a non-BFC superfile, but the same BFC subfile
> may be clipped when referenced from a BFC superfile"
OK. I've added your suggestion, and I will work on a new section, specifically
to discuss when clippability vs. non-clippability vs. certification vs.
everything else. Hopefully including Rui's branching (C-C-C, C-N-C, etc.)
discussion.
> > 4 CERTIFY
> > 4 This tag indicates the DAT file is compatible with the
> > 4 backface-culling extension. Every DAT file must be clearly labeled if it is
> > 4 compliant. One way to accomplish is to place 0 BFC CERTIFY at the beginning
> > 4 of the file, before the first operational command-line.
> > 4
> > 4 A second way to specify a file as compliant is to use any option, except for
> > 4 the NOCERTIFY option, on a 0 BFC meta-statement, before the first operational
> > 4 command-line. This is an acceptable alternative, but the 0 BFC CERTIFY
> > 4 method is recommended and prefered.
>
> and on November 17th you wrote likewise in
> http://www.lugnet.com/news/display.cgi?lugnet.cad.dev:3247
> > Any use of the 0 BFC command would indicate that the file is certified, except
> > for 0 BFC NOCERTIFY. So, strictly speaking, CERTIFY is redundant. Placing a 0
> > BFC CLIP or 0 BFC CW at the start of a file would be sufficient to certify that
> > file.
>
> The pseudo-code doesn't reflect this. It always requires a 0 BFC CERTIFY.
OK, to improve the pseudo-code, I made several modifications.
I changed Certified to a trivalue type:
6 Certified trivalue(TRUE, FALSE, UNKNOWN) Initial UNKNOWN
added logic to set Certified on any type of BFC statement (other than 0 BFC
NOCERTIFY):
4 Case Command.LineType
5 BFC
6 If Certified is UNKNOWN and no Option in Command is NOCERTIFY Then
6 Certified = TRUE
6 End If
in the loop to process the BFC options, I added tests to make sure that there's
no attempt to change certification after it is set:
5 Case Option
5 CERTIFY
6 Assert Certified != FALSE
6 // Triggers error if file has been NOCERTIFY'ed
6 Certified = TRUE
5 NOCERTIFY
6 Assert Certified != TRUE
6 // Triggers error if file has been CERTIFY'ed
5 Certified = FALSE
and, in the sections to process real commands (linetypes 1 through 5), I added
logic to force Certified to false if no 0 BFC statement is encountered:
5 SUBFILE
6 If Certified is UNKNOWN Then
6 Certified = FALSE
...
4 LINE, CONDITIONAL_LINE
6 If Certified is UNKNOWN Then
6 Certified = FALSE
...
4 TRIANGLE, QUAD
6 If Certified is UNKNOWN Then
6 Certified = FALSE
> The pseudo-code doesn't reflect this. It always requires a 0 BFC CERTIFY.
> And this implies 0 BFC CLIP and 0 BFC CCW. (which should be added)
The p-code already specifies default values for LocalClip and Winding. I
altered the verbiage (changed = to Initial) to make this a bit more clear:
4 Declare
6 LocalClip boolean Initial TRUE
6 Winding trivalue(CCW, CW, UNKNOWN) Initial CCW
6 Certified trivalue(TRUE, FALSE, UNKNOWN) Initial UNKNOWN
6 InvertNext boolean Initial FALSE
If a file is uncertified, the values of LocalClip and Winding don't matter.
> When glancing at a BFC file I think it would be nice to see the winding-
> state stated explicitly, rather than having to remember the default.
I can understand that. But, I don't agree especially. And I think this is an
issue that shouldn't be allowed to block our progress.
> So my suggestion is these simple rules:
> *0 BFC CCW|CW|NOWIND
> *This defines the winding of the following polygons and also means that
> *the file is "certified", i.e. "has been inspected", and therefore
> *cliping is enabled, both for local polygons and subfiles.
> *Winding-state can be changed any time by a new 0 BFC CCW|CW|NOWIND.
> *
> *In the (probably) rare cases of double-sided sections, the part-author
> *can temporarily use 0 BFC NOCLIP and then 0 BFC CLIP. Both local
> *polygons and subfiles in that section are not clipped.
Double-sided sections won't be very rare. They'll be needed for all decorated
parts.
> *If you want to turn a subfile inside-out, add a 0 BFC INVERTNEXT just
> *before the subfile reference.
>
> See also http://www.lugnet.com/news/display.cgi?lugnet.cad.dev:3220
> and http://www.lugnet.com/news/display.cgi?lugnet.cad.dev:3234
>
> Can you rewrite the pseudo-code to accommodate both uses
> or must we choose?
I'm not sure what you mean by "both uses". Could you clarify?
My intention is that any BFC statement, other than NOCERTIFY, placed before the
first operational command-line, is sufficient to certify the file, default to
(local) clipping to enabled, and default winding to CCW. Of course, that
initial command can override either of these defaults.
> > 4 NOWIND
> > 4 This option sets the winding-state to indicate that following polygons may be
> > 4 wound in either clockwise or counter-clockwise, or may not be correctly wound
> > 4 at all.
> You should add the word "unknown" which has been used earlier in the
> document, for example:
> NOWIND
> This option sets the winding-state to unknown indicating that following
> polygons may be wound in either clockwise or counter-clockwise, or may
> not be correctly wound at all.
OK. It now reads:
4 NOWIND
6 This option sets the winding-state to unknown, indicating that following
6 polygons may be wound clockwise or counter-clockwise, or may not be
6 correctly wound at all.
> > 4 There may be any number of WINDING
> > 4 statements in a file, although it is recommended that changes to WINDING
> > 4 be kept to a minimum.
> It's not WINDING anymore...
Right. Updated to:
6 There may be any number of changes to the winding direction
6 in a file, although it is recommended that changes to winding
4 be kept to a minimum.
> > 4 INVERTNEXT
> > 4 This option is used directly before a subfile command (linetype 1). It is
> > 4 a flag, indicating to the renderer that the following subfile reference should
> > 4 have its orientation inverted, i.e. the inside/outside definition should be
> > 4 swapped. Inverted subfiles must be preceeded by an 0 INVERTNEXT statement,
> > 4 and the 0 INVERTNEXT statement may not appear anywhere else in a file.
> Change "0 INVERTNEXT" to "0 BFC INVERTNEXT"
OK.
> > 4 {deleted invalid paragraph about assuming part-files are always right-side-out}
> Hey, what did you do that for?
> I think it is perfectly alright to assume that files in the ldraw\parts
> directory are right-side out, (and therefore clippable) even though
> not all superfiles are certified.
It *is* reasonable to assume that ldraw\parts files are right-side out. But
there is no simple way for the rendering engine to exploit this assumption.
Some problems:
1. Winding = NOWIND for the part-file. Both because quads could be bowtied, and
because there's way to know (for sure) which polygons face which direction. So
no local BFC clipping can be performed.
2. There's no flagging of inversion for subfiles, so it's not possible to allow
BFC clipping of subfiles.
Those two limitations severly limit any advantages of knowing that part-files
are always right-side out.
> > 4 Recursive Procedure RenderFile
> > 4 Parameters:
> > 4 ModelFile string // File to render
> > 4 AccumClip boolean // global clipping value yes/no
> > 4 AccumInvert boolean // current inversion odd/even or normal/inverted
> TransformMatrix matrix // current transformation
>
> > 4 RenderFile Command.Subfile,
> > 4 (AccumClip and LocalClip and Certified),
> > 4 (AccumInvert xor InvertNext)
> TransformMatrix * Command.TransformMatrix
>
> TransformMatrix could be renamed to AccumTransformMatrix like the other
> parameters to RenderFile.
OK.
> BTW, "CERTIFY" - shouldn't it be "CERTIFIED" ?
I can go either way on this. The document is currently consistent, it only uses
CERTIFY, not a mix of the two, and the other options are all present tense: CLIP
NOCLIP NOWIND INVERTNEXT. So I'm not going to change CERTIFIED to CERTIFY right
now, but if it becomes an issue, I will.
> > Maybe we can get this finalized before the end of the year. Well, a guy can
> > dream, right? ;)
>
> Yes, it would be nice (and necessary) to get opinions/approval/consent
> from more part authors and programmers.
Yes. Especially the programmers. Michael has pinged me once or twice about
this. When we get a fairly final document, I'll ping Michael back.
Steve
|
|
Message has 2 Replies:
 | | Re: Line in the Sand
|
| (...) Seems Geocities is having some trouble, and the shortcut URLs won't work. Try these instead: (2 URLs) Steve (25 years ago, 6-Dec-99, to lugnet.cad.dev)
| | | Re: Line in the Sand
|
| Steve Bliss wrote... (...) OK. The pseudo-code reflects this now. (...) I meant "The fact that 0 BFC CERTIFY implies 0 BFC CLIP and 0 BFC CCW should be stated explicitly in the CERTIFY section in Language Extensions". The code was clear enough. (...) (25 years ago, 6-Dec-99, to lugnet.cad.dev)
|
Message is in Reply To:
| | Re: Line in the Sand
|
| Steve Bliss wrote... (...) I prefer the newer with only one new meta-statement. This easily identifies commands related to BFC. However, the syntactical change doesn't solve the discussion about the CERTIFY option, see later. I have some suggestions (...) (25 years ago, 4-Dec-99, to lugnet.cad.dev)
|
85 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
|
|
|
|
