| | | | | See <http://www.geocities.com/partsref/bfcspec.txt>
There is a serious weakness in this document, 'certification' is not clearly
defined. This definitely needs to be addressed.
Currently, the only definition of certification is:
> 1 Certified. In this document, a DAT file is certified if it complies
... which is a bit of a typo.
My definition of certified follows.
A file is certified when:
1. The file includes a 0 CERTIFY BFC statement in the header comments.
2. The file complies with the specifications of the language extension, and
does not include syntax or commands which conflict with the extension.
a. The winding of polygons matches any occurrences of the 0 WINDING
statement.
b. The clipping setting is changed to mark sections which must always be
rendered, either because they are double-sided or not compliant.
c. All subfiles which should be rendered as inverted are marked with a 0
INVERT statement. No other 0 INVERT statements appear in the file.
Does this sound OK?
Steve
| | | | | | | | | | | | |
| |
| I think we should drop the CERTIFY as it is superfluous and
apparently adds more confusion than it clarifies!
Why not settle for:
0 WINDING (CCW|CW|UNKNOWN)
This defines the winding of the following polygons and means that
the file is "certified", i.e. "has been inspected" and therefore
cliping is enabled, both for local polygons and subfiles. [1]
In the (probably) rare cases of double-sided sections, the part-author
can temporarily use CLIPPING OFF and then CLIPPING ON. Both local
polygons and subfiles in that section are not clipped. [2]
If you want to turn a subfile inside-out, add an INVERT just
before the subfile reference.
Done.
/Lars
[1] The WINDING also means certified - why would you bother adding
a WINDING if you have not inspected/certified the file.
The WINDING also means clipping on - why would you bother adding
a WINDING if you don't wan't clipping.
If you e.g. have only checked the subfile references, but not the
winding of the polygons yet, simply use WINDING UNKNOWN.
If you e.g. have only checked the winding of the polygons, but not
the subfile references yet, simply use WINDING CCW|CW and enclose
subfile references with CLIPPING OFF/CLIPPING ON.
[2] CLIPPING OFF disregards the winding state, i.e. you don't
have to also specify a WINDING UNKNOWN.
| | | | | | | | | | | | | | | | | |
| |
| In lugnet.cad.dev, Lars C. Hassing wrote:
> I think we should drop the CERTIFY as it is superfluous and
> apparently adds more confusion than it clarifies!
I'd like to hear from other people about this before deciding to keep it or drop
it. I'll give my reasons to keep CERTIFY below. But first ...
> Why not settle for:
>
> 0 WINDING (CCW|CW|UNKNOWN)
Why not use:
0 CLIPPING (YES|NO)
CLIPPING addresses the core issue (can the current file be BFC'ed or not?) more
directly than WINDING.
OK. Here are my reasons to proposing the CERTIFY statement:
- CLIPPING and WINDING are both operational commands. They can be used multiple
times in a single file, to change the setting of a rendering option/variable.
The compliance-state of the file does not change with each occurance of the
CLIPPING or WINDING statements. So, IMO, it makes sense to have a
compliance-statement which is used only once per file.
- WINDING (and to a lesser degree, CLIPPING) address one part of BFC-compliance,
but does not explicitly include all parts of compliance. So, IMO, it makes
sense to have a statement which clearly indicates whether the file is compliant
or not.
- I think it is entirely possible that other language extensions will be
developed over time, and these extensions can 'reuse' the CERTIFY statement to
make their own assertations.
Steve
| | | | | | | | | | | | | | | | | | | | | Steve:
> In lugnet.cad.dev, Lars C. Hassing wrote:
>
> > I think we should drop the CERTIFY as it is superfluous and
> > apparently adds more confusion than it clarifies!
>
> I'd like to hear from other people about this before
> deciding to keep it or drop it. I'll give my reasons to
> keep CERTIFY below. But first ...
I _don't_ think CERTIFY should be dropped, but we might want
to change it to "EXTENSIONS", since it is intended for
listing which extensions to the LDraw language the file
contains.
> - I think it is entirely possible that other language
> extensions will be developed over time, and these
> extensions can 'reuse' the CERTIFY statement to make their
> own assertations.
Yes.
Play well,
Jacob
------------------------------------------------
-- E-mail: sparre@cats.nbi.dk --
-- Web...: <URL:http://www.ldraw.org/FAQ/> --
------------------------------------------------
| | | | | | | | | | | | | | | | | | | | |
| |
| Steve Bliss wrote...
> In lugnet.cad.dev, Lars C. Hassing wrote:
>
> > I think we should drop the CERTIFY as it is superfluous and
> > apparently adds more confusion than it clarifies!
>
> I'd like to hear from other people about this before deciding to keep it or drop
> it. I'll give my reasons to keep CERTIFY below. But first ...
>
> > Why not settle for:
> >
> > 0 WINDING (CCW|CW|UNKNOWN)
>
> Why not use:
>
> 0 CLIPPING (YES|NO)
>
> CLIPPING addresses the core issue (can the current file be BFC'ed or not?) more
> directly than WINDING.
>
> OK. Here are my reasons to proposing the CERTIFY statement:
>
> - CLIPPING and WINDING are both operational commands. They can be used multiple
> times in a single file, to change the setting of a rendering option/variable.
> The compliance-state of the file does not change with each occurance of the
> CLIPPING or WINDING statements. So, IMO, it makes sense to have a
> compliance-statement which is used only once per file.
But it's not used!
> - WINDING (and to a lesser degree, CLIPPING) address one part of BFC-compliance,
> but does not explicitly include all parts of compliance. So, IMO, it makes
> sense to have a statement which clearly indicates whether the file is compliant
> or not.
But it's not used!
> - I think it is entirely possible that other language extensions will be
> developed over time, and these extensions can 'reuse' the CERTIFY statement to
> make their own assertations.
But it's not used! Why would future extensions use the CERTIFY statement
if we don't have a use for it today?
I agree WINDING may not directly make you think about BFC, but I think
I argued why WINDING is enough - please comment:
http://www.lugnet.com/news/display.cgi?lugnet.cad.dev:3220
/Lars
| | | | | | | | | | | | | | | | | | | | In lugnet.cad.dev, Lars C. Hassing wrote:
> I agree WINDING may not directly make you think about BFC, but I think
> I argued why WINDING is enough - please comment:
> http://www.lugnet.com/news/display.cgi?lugnet.cad.dev:3220
Is there a reason you prefer
0 WINDING (CW|CCW)
as the 'certify statement', rather than
0 CLIPPING ON
?
Winding is local.
Certification is sort-of local -- only the local file is certified, but the
local setting affects whether subfiles (in the same reference branch) are
clippable or not.
Clipping accumulates downward on the reference branch.
CLIPPING seems more like a 'certify statement' than WINDING. IMO.
Steve
| | | | | | | | | | | | | | | | | | | |
| |
| Steve Bliss wrote in message ...
> In lugnet.cad.dev, Lars C. Hassing wrote:
>
> > I agree WINDING may not directly make you think about BFC, but I think
> > I argued why WINDING is enough - please comment:
> > http://www.lugnet.com/news/display.cgi?lugnet.cad.dev:3220
>
> Is there a reason you prefer
> 0 WINDING (CW|CCW)
> as the 'certify statement', rather than
> 0 CLIPPING ON
> ?
>
> Winding is local.
> Certification is sort-of local -- only the local file is certified, but the
> local setting affects whether subfiles (in the same reference branch) are
> clippable or not.
> Clipping accumulates downward on the reference branch.
>
> CLIPPING seems more like a 'certify statement' than WINDING. IMO.
I think it is nice to have the winding state expressed explicitly.
IMO part authors should be allowed to whatever winding they find
most natural to work with (though you say CCW is desirable).
It is perfectly legal to use CW, we should put no constraints
on part authors, and not at all on a matter that a program
can easily swap for you.
Winding is the most functional of the commands. The CCW or CW
is interesting. Clipping is obvious.
Once stating the winding, it is natural that you want clipping and
that you have inspected the file. So you don't need to say more.
CERTIFY implies WINDING CCW, which you have to remember.
I expect CLIPPING to be used very seldom: only for double-sided
sections (can be counted on one hand?) and for parts which you
only want to check the winding but not the subfiles (most likely you
will check both at the same time).
/Lars
PS. A few parts can be made of subfiles alone (i.e. only linetype 1).
I admit a WINDING can seem strange in such a file, so perhaps
presence CLIPPING ON should also mean "certification"
(of subfiles, the winding state is unknown). See also last part of
http://www.lugnet.com/news/display.cgi?lugnet.cad.dev:3110
| | | | | | | | | | | | | | | | | | | | Actually, I was thinking of CERTIFY, like a enable of the specific
new metacommands.
Example:
If you have a
0 CERTIFY BFC
would mean Enable or take into account the GFC related commands. besides
the fact that it certifies that file has beeing checked for point
order (bowties) and winding.
So the certify statement is a little bit more powerfull than just stating
that it complies to the some fact.
And following this, I am in favor of replacing CERTIFY with EXTENSIONS,
since it makes alot more sence, with this reasoning.
Besides this could be a great help for DEBUG, just remove (or comment) the
CERTIFY/EXTENSION line (or remove the particular extension, when you have
more than one) and all the extension MetaCommands are ignored, without
having to comment them all.
Rui Martins
| | | | | | | | | | | | | | | | | | | |
| |
| On Tue, 16 Nov 1999, Rui Martins wrote:
> Actually, I was thinking of CERTIFY, like a enable of the specific
> new metacommands.
>
> Example:
> If you have a
> 0 CERTIFY BFC
>
> would mean Enable or take into account the GFC related commands. besides
> the fact that it certifies that file has beeing checked for point
> order (bowties) and winding.
>
> So the certify statement is a little bit more powerfull than just stating
> that it complies to the some fact.
>
> And following this, I am in favor of replacing CERTIFY with EXTENSIONS,
> since it makes alot more sence, with this reasoning.
>
> Besides this could be a great help for DEBUG, just remove (or comment) the
> CERTIFY/EXTENSION line (or remove the particular extension, when you have
> more than one) and all the extension MetaCommands are ignored, without
> having to comment them all.
>
> Rui Martins
I forgot to add that you can have a file that is 'certified', but due
to its nature (the lego part/sub-part) no clipping is applicable, but it
can have correct point order (no bowties) and a defined winding (the
default, or some expecifically insert in the file '0 WINDING CW').
And also that EXTENSION (or CERTIFY) is strictly local, does not affect
other files in the rendering tree.
Rui Martins
| | | | | | | | | | | | | | | |
| |
| Steve:
> See <http://www.geocities.com/partsref/bfcspec.txt>
>
> There is a serious weakness in this document, 'certification' is not clearly
> defined. This definitely needs to be addressed.
[...]
> My definition of certified follows.
>
> A file is certified when:
> 1. The file includes a 0 CERTIFY BFC statement in the header comments.
> 2. The file complies with the specifications of the language extension, and
> does not include syntax or commands which conflict with the extension.
> a. The winding of polygons matches any occurrences of the 0 WINDING
> statement.
> b. The clipping setting is changed to mark sections which must always be
> rendered, either because they are double-sided or not compliant.
...with the inversion status.
> c. All subfiles which should be rendered as inverted are marked with a 0
> INVERT statement. No other 0 INVERT statements appear in the file.
>
> Does this sound OK?
Yes. You might want to change "INVERT" to "INVERTNEXT".
Play well,
Jacob
------------------------------------------------
-- E-mail: sparre@cats.nbi.dk --
-- Web...: <URL:http://www.ldraw.org/FAQ/> --
------------------------------------------------
| | | | | | |