[LSC] Ambiguities in the draft BFC spec

[Travis Cobbs]

Sorry, I mis-read your other message.  I'll repost my response here (with
some slight changes).

Thanks for bringing the first part up.  I had forgotten about that.  I
believe that LDView is the only tool that spits out warnings when 0 BFC
CERTIFY is used as the start text for every single BFC command.  You are
correct that there is some ambiguity in this, and I'll admit that when I
added that warning to LDView, I wasn't intending it as a way to influence
the allowed behavior in the parts tracker.  I certainly wasn't aware that
MLCad changed all BFC statements to that format, or I probably would have
forgone producing that warning.

I believe we should state in the spec that at least one option is required.
I believe that a "0 BFC" line all by itself counts as a no-op in the current
spec.  (When it talks about CERTIFY being the default when other BFC
commands exist, it specifically requires that the other commands have
options specified.)

The spec already requires that the first BFC command be before the first
operational command in the file.  While it encourages the use of CERTIFY
near the top of the file to accomplish this, it specifically doesn't require
it.  We definitely want to leave the spec like this so that compliant
renderers will continue to have to support this behavior, even if it's not
allowed by parts in the parts library going forward.

I personally think that we shouldn't care about winding changes at all.
LDView performs the swap at load-time, which prevents there from being any
performance hit.  In fact, LDView performs the swap any time it encounters
polygons that are wound in the oposite direction to what it wants.  All
polygons are drawn with the same winding.  This is a fairly trivial thing to
implement in a renderer.  I think it's a whole lot easier then having a
renderer that actually renders polygons with both windings, and switches its
culling behavior between groups.  It might be a good idea to mention in the
spec that the best way for a renderer to handle multiple windings is to swap
the winding at load time for all the polygons that don't match its expected
winding.

--Travis

On 10/12/06, William Howard <william at howard-family.fsworld.co.uk> wrote:
>
> I'm using the term ambiguity to mean a difference in interpretation of the
> spec amoung 2 or more people.
>
> The following two ambiguities *HAVE* occured in the Parts Library, either
> by
> authors using them or tools used by authors adding them.  The difference
> in
> interpretation has been flagged by Reviewers holding the files.
>
> 1) The draft specification gives the syntax of the BFC meta-command as
>     0 BFC [CERTIFY|NOCERTIFY] [CLIP|NOCLIP] [CW|CCW] [INVERTNEXT]
> and there is an ambiguity here in that the syntax *permits* the construct
>     0 BFC CERTIFY INVERTNEXT
> but this is generally considered wrong (albeit not by one tool author)
>
> 2) While the draft specification permits the winding to change direction
> through the file
>     "There may be any number of changes to the winding direction in a
> file,
>      although it is recommended that changes to winding be kept to a
> minimum."
> there have been parts on the tracker held for this reason.
>
>
> To address point 1, I would like to see the syntax definition changed to
>     0 BFC NOCERTIFY
>     0 BFC CERTIFY [CW|{CCW}]
>     0 BFC [CLIP|NOCLIP] [CW|CCW] [INVERTNEXT]
> where [] indicates an optional item and {} the default value
>
>
> This makes the set of valid BFC meta-commands as follows (ignoring order
> of
> options)
>   0 BFC NOCERTIFY
>   0 BFC CERTIFY
>   0 BFC CERTIFY CW
>   0 BFC CERTIFY CCW
>
>   0 BFC
>   0 BFC INVERTNEXT
>   0 BFC CW
>   0 BFC CW INVERTNEXT
>   0 BFC CCW
>   0 BFC CCW INVERTNEXT
>
>   0 BFC CLIP
>   0 BFC CLIP INVERTNEXT
>   0 BFC CLIP CW
>   0 BFC CLIP CW INVERTNEXT
>   0 BFC CLIP CCW
>   0 BFC CLIP CCW INVERTNEXT
>
>   0 BFC NOCLIP
>   0 BFC NOCLIP INVERTNEXT
>   0 BFC NOCLIP CW
>   0 BFC NOCLIP CW INVERTNEXT
>   0 BFC NOCLIP CCW
>   0 BFC NOCLIP CCW INVERTNEXT
>
> So, are all of these variations necessary/desirable?
>
> What does "0 BFC" mean (it's valid syntax, so it must mean something)?
>
> Do we need to explicity state that the CERTIFY/NOCERTIFY variants of the
> BFC
> meta-commands  must occur before any "Operational Command-Lines"?
>
> And what to do about point 2?  If rendering tools can cope with changes in
> winding within a file should we care if parts are singularly wound?
>
> William
>
>
> _______________________________________________
> LSC mailing list
> LSC at ldraw.org
> http://five.pairlist.net/mailman/listinfo/lsc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://five.pairlist.net/pipermail/lsc/attachments/20061012/a9725225/attachment-0001.html