 | | | | | | |
| |
|
OK, we've been discussing how to best extend the LDraw language to
allow rendering engines to do backface-culling. We've got a pretty
good agreement on most of what is needed. I think it would be
productive, at this point, to work from a complete statement. That
way, we all have a firm understanding of the disagreements. ;)
So I've written such a document. I've included it in this message,
and I will also be maintaining it at
<http://www.geocities.com/partsref/bfcspec.txt>, for now. If we
ever decide that the spec is good to go, I'll turn it over to Tim
and Jacob, to be incorporated into www.ldraw.org.
I wouldn't describe the document as a formal specification. An
informal spec, maybe. I'm sure there are points I missed, and pieces
that could be better written. And there are one or two points of
contention to be found, as well.
This is a serious request for feedback, suggestions, criticisms,
additions, and arguments. We are very close on this, let's finish it up!
Steve
--------------------------------------------------------------------------------
LDraw Language Extension for Clipping
1999.10.20
author: L-CAD list on www.lugnet.com/cad/dev/
--------------------------------------------------------------------------------
Purpose: Establish a standard for backface-culling (ie, clipping) processing
in LDraw-compatible rendering programs. This standard will include language
extensions, definitions and expected processing effects.
The standard must allow cross-compatible DAT files. That is, LDraw-compatible
rendering programs must render clipping-enabled DAT files correctly, and
renderers which include the BFC extensions must render non-clippable DAT
files correctly.
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.
--------------------------------------------------------------------------------
Definitions
--------------------------------------------------------------------------------
Subfile. A DAT file referenced from another file, via a linetype 1 command.
Or any file which is lower in the file-reference tree than the current file.
Superfile. The file which referenced the current file. More generally, any
file which is higher in the file-reference tree than the current file.
Polygon. A 2D surface created by LDraw's linetype 3 (triangle) or 4
(quadrilateral) command.
--------------------------------------------------------------------------------
Rendering Engine Requirements
--------------------------------------------------------------------------------
There will be a few requirements placed on the design of rendering programs,
in order to achieve correct renderings. Any program should may violate
these requirements, if there is another way to acheive a valid rendering.
Matrix Inversions. Rendering engines will need to correct for transformation
matrices which inadvertently invert the current file. They will also need to
allow for situations in which the matrix is deliberately inverted.
Allowable Clipping. A file can only have clipping applied when the following
conditions apply:
- All superfiles are certified.
- The current file is certified.
- No superfile has disabled clipping.
In some cases, it may be desirable to assume that a file is right-side out,
(and therefore clippable) even though not all superfiles are certified. One
obvious example is files in the ldraw\parts directory.
--------------------------------------------------------------------------------
Language extensions
--------------------------------------------------------------------------------
0 CERTIFY [BFC|NOBFC]
default: NOBFC
This meta-statement indicates whether a DAT file is compatible with the
backface-culling extension (or not). Every clippable file must include
exactly one CERTIFY meta-statement, and it must appear before the first
operational command-line in the file.
This statement could be extended in the future to include information about
other language extensions. Rendering programs should expect to find multiple
tags on the CERTIFY meta-statement.
The settings on a CERTIFY line apply only to the file containing the CERTIFY
statement. There is no concept of a global or persistent "certify state",
affecting multiple files in a rendering.
--------------------------------------------------------------------------------
0 WINDING [ CW | CCW | UNKNOWN ]
default: CCW
Sets the current winding direction for polygons in the current file. The
order of vertices in each polygon command must follow this winding, as
viewed from the front of the polygon. There may be any number of WINDING
statements in a file, although it is recommended that changes to WINDING
be kept to a minimum.
CW = Clockwise
CCW = counter-clockwise (same as anti-clockwise)
UNKNOWN = winding direction is unknown or variable. This setting will disable
clipping, until the winding is reset.
The WINDING setting is a local setting, it applies only to the file in which
the WINDING meta-statement appears.
--------------------------------------------------------------------------------
0 CLIPPING [ ON | OFF ]
default: renderer-dependent
Enables or disables clipping for the rendering. Any number of CLIPPING
statements may appear in a file. The current clip-setting is passed down to
subfiles when they are referenced, giving superfiles some influence over the
processing of subfiles. However, the clip-setting is *not* passed back up
from the subfile to the superfile.
--------------------------------------------------------------------------------
0 INVERT
The INVERT meta-statement is a flag, indicating to the renderer that the
following subfile reference has been intentionally inverted. If the next
command-line is not a subfile reference, the INVERT is ignored.
The INVERT flag is required in addition to the actual inversion, which
occurs within the subfile command's transformation matrix.
--------------------------------------------------------------------------------
end of document
--------------------------------------------------------------------------------
| | | | | | | | | | | | | | | |
Steve Bliss wrote:
> I wouldn't describe the document as a formal specification.
I would. This is WAY better than most of the crap requirements I have to
rationalize into some semblance of something to keep paying customers
happy.
Very nice work, Steve. Written in a way that made it understandable to
someone that doesn't really know matrix math or rendering engine
internals (like me)...
I just have one suggestion...
> And there are one or two points of
> contention to be found, as well.
could you elaborate or identify these?
--
Larry Pieniazek larryp@novera.com http://my.voyager.net/lar
- - - Web Application Integration! http://www.novera.com
fund Lugnet(tm): http://www.ebates.com/ ref: lar, 1/2 $$ to lugnet.
NOTE: Soon to be lpieniazek@tsisoft.com :-)
| | | | | | | | | | | | | | | | | | | | | |
| |
|
On Wed, 20 Oct 1999 20:56:06 GMT, Larry Pieniazek <lar@voyager.net> wrote:
> Steve Bliss wrote:
>
> > I wouldn't describe the document as a formal specification.
>
> I would. This is WAY better than most of the crap requirements I have to
> rationalize into some semblance of something to keep paying customers
> happy.
Thanks. (blushing)
Can that be translated into paying work?
> Very nice work, Steve. Written in a way that made it understandable to
> someone that doesn't really know matrix math or rendering engine
> internals (like me)...
That's because it's written by someone who keeps the matrix-math reference
material very close at hand whenever he's got to actually go under the hood.
> I just have one suggestion...
>
> > And there are one or two points of
> > contention to be found, as well.
>
> could you elaborate or identify these?
Issue 1: should the CLIPPING setting be strictly local to each file, or should
it be persistent between files, especially be pushed downward in the recursive
subfile-referencing process?
Issue 2: What is this CERTIFY statement? That one came out of left field.
Issue 3: Do all files (in the root-file to current-file referencing chain) need
to be certified to allow clipping, or not?
Issue 4: Do we need a WINDING UNKNOWN statement?
Issue 5: Can a superfile disable clipping, overriding a subfile's CLIPPING ON
command?
Those are the ones that jump out at me, I believe Lars and Gary have already
found some others, and I'm counting on Rui to dig out some others. There's at
least a half-dozen regulars reading this who know more the subject than I do,
I'm hoping they'll post either their comments or agreement.
Steve
"Never trust anything that can think for itself, if you can't see where it keeps its brain."
| | | | | | | | | | | | | | | | | | | | | | |
Steve Bliss wrote:
>
> On Wed, 20 Oct 1999 20:56:06 GMT, Larry Pieniazek <lar@voyager.net> wrote:
>
> > Steve Bliss wrote:
> >
> > > I wouldn't describe the document as a formal specification.
> >
> > I would. This is WAY better than most of the crap requirements I have to
> > rationalize into some semblance of something to keep paying customers
> > happy.
>
> Thanks. (blushing)
>
> Can that be translated into paying work?
Yes. How are you on travel? :-)
--
Larry Pieniazek larryp@novera.com http://my.voyager.net/lar
- - - Web Application Integration! http://www.novera.com
fund Lugnet(tm): http://www.ebates.com/ ref: lar, 1/2 $$ to lugnet.
NOTE: Soon to be lpieniazek@tsisoft.com :-)
| | | | | | | | | | | | | | | | | | | | | | |
On Thu, 21 Oct 1999 08:36:21 GMT, Larry Pieniazek <lar@voyager.net> wrote:
> Steve Bliss wrote:
> >
> > On Wed, 20 Oct 1999 20:56:06 GMT, Larry Pieniazek <lar@voyager.net> wrote:
> >
> > > Steve Bliss wrote:
> > >
> > > > I wouldn't describe the document as a formal specification.
> > >
> > > I would. This is WAY better than most of the crap requirements I have to
> > > rationalize into some semblance of something to keep paying customers
> > > happy.
> >
> > Thanks. (blushing)
> >
> > Can that be translated into paying work?
>
> Yes. How are you on travel? :-)
Much better than I used to be.
Steve
"Never trust anything that can think for itself, if you can't see where it keeps its brain."
| | | | | | | | | | | | | | | | | | | |
| |
|
Steve Bliss wrote...
> OK, we've been discussing how to best extend the LDraw language to
> allow rendering engines to do backface-culling. We've got a pretty
> good agreement on most of what is needed. I think it would be
> productive, at this point, to work from a complete statement. That
> way, we all have a firm understanding of the disagreements. ;)
Good idea, it's hard to discuss in so many threads.
> So I've written such a document.
Thank you for the well-written summary. Well-written because I agree with
99% of it ;)
> This is a serious request for feedback, suggestions, criticisms,
> additions, and arguments. We are very close on this, let's finish it up!
Yes, too bad I'm off for an Internet-free :( 4-day week-end at the sea :)
> Matrix Inversions. Rendering engines will need to correct for • transformation
> matrices which inadvertently invert the current file. They will also need • to
> allow for situations in which the matrix is deliberately inverted.
"the current file" should be "a subfile"
> 0 CERTIFY [BFC|NOBFC]
> default: NOBFC
I think you should make it clear what "default" means:
1) absence of "0 CERTIFY", or
2) "0 CERTIFY" with no (or other) tags
Is the CERTIFY really necessary?
Presence of a CLIPPING ON should be enough.
Too many rules and required meta-commands increase the risk of forgetting
some.
> 0 WINDING [ CW | CCW | UNKNOWN ]
> default: CCW
I don't think there should be a default. You should always specify either
CW, CCW or UNKNOWN.
So DOUBLESIDED should be accomplished by CLIPPING OFF?
> The WINDING setting is a local setting, it applies only to the file in • which
> the WINDING meta-statement appears.
Or:
The WINDING setting is a local setting, it applies only to the polygons in
the file in which the WINDING meta-statement appears.
> 0 CLIPPING [ ON | OFF ]
> default: renderer-dependent
Again I am uncertain what you mean by "default"...
You should always specify either ON or OFF.
> Enables or disables clipping for the rendering. Any number of CLIPPING
> statements may appear in a file. The current clip-setting is passed down • to
> subfiles when they are referenced, giving superfiles some influence over • the
> processing of subfiles. However, the clip-setting is *not* passed back up
> from the subfile to the superfile.
Also, you could stress that, CLIPPING ON in a file has no effect if
clipping is currently off.
> The INVERT meta-statement is a flag, indicating to the renderer that the
> following subfile reference has been intentionally inverted. If the next
> command-line is not a subfile reference, the INVERT is ignored.
>
> The INVERT flag is required in addition to the actual inversion, which
> occurs within the subfile command's transformation matrix.
Or:
The INVERT meta-statement is a flag, indicating to the renderer that the
following subfile reference should have its orientaion inverted, i.e. the
inside/outside definition should be swapped.
If the next command-line is not a subfile reference, the INVERT is ignored.
/Lars
| | | | | | | | | | | | | | | | | | | | | |
| |
|
On Thu, 21 Oct 1999 00:10:02 GMT, "Lars C. Hassing" <lch@ccieurope.com> wrote:
> Yes, too bad I'm off for an Internet-free :( 4-day week-end at the sea :)
Sometimes, life just sucks. ;) Have a great weekend!
> > Matrix Inversions. Rendering engines will need to correct for transformation
> > matrices which inadvertently invert the current file. They will also need to
> > allow for situations in which the matrix is deliberately inverted.
>
> "the current file" should be "a subfile"
OK.
> > 0 CERTIFY [BFC|NOBFC]
> > default: NOBFC
>
> I think you should make it clear what "default" means:
> 1) absence of "0 CERTIFY", or
> 2) "0 CERTIFY" with no (or other) tags
Both of these. (0 CERTIFY with no tags would be a syntax error, IMO.)
> Is the CERTIFY really necessary?
Define necessary. ;) CERTIFY is not absolutely required, but it is logical and
useful. The other meta-statements can *imply* certification, but they don't
state it directly.
Eventually, 90% of the files in the parts library will have exactly one extended
statement in them. This will be whatever statement is needed to flag the file
as being certified for backface culling.
> Presence of a CLIPPING ON should be enough.
The document specifies that clipping state is passed into subfiles. Having a
CLIPPING ON statement in every file would be counter-productive. So change your
statement to:
Presence of a WINDING CCW should be enough.
At which point I shrug, refer you to my comments above, and point out that it is
conceivable that someone could take an existing part-file, clean up all the
subfile references, but not touch the polygons. Then they could certify the
file with:
0 CERTIFY BFC
0 WINDING UNKNOWN
> Too many rules and required meta-commands increase the risk of forgetting
> some.
True, but the statement that flags a file as being certified will not be easily
forgotten. It will appear at the top of 99%+ of the part files.
> > 0 WINDING [ CW | CCW | UNKNOWN ]
> > default: CCW
>
> I don't think there should be a default. You should always specify either
> CW, CCW or UNKNOWN.
If people really don't like the 0 CERTIFY flag, I'll agree with you on this one.
the WINDING statement would certify the file.
> So DOUBLESIDED should be accomplished by CLIPPING OFF?
Yes. Since the winding setting is strictly local, the desired effect of
DOUBLESIDED is more thouroughly accomplished by controlling the CLIPPING
setting. It's too bad, I liked the idea of WINDING DOUBLESIDED. :(
Should this use of CLIPPING OFF be stated more plainly, perhaps in a section for
DAT file authors?
> > The WINDING setting is a local setting, it applies only to the file in which
> > the WINDING meta-statement appears.
> Or:
> The WINDING setting is a local setting, it applies only to the polygons in
> the file in which the WINDING meta-statement appears.
OK.
> > 0 CLIPPING [ ON | OFF ]
> > default: renderer-dependent
>
> Again I am uncertain what you mean by "default"...
> You should always specify either ON or OFF.
You're right. Since the clipping state is passed down from superfiles, there is
no need to have a file-level default. But there is a need for a
start-of-processing default. The rendering program can assign that default, I
don't see a reason to specify it in the standard.
I removed the 'default: renderer-dependent' line, and added a Clipping State
paragraph to the Rendering Engine section.
> > Enables or disables clipping for the rendering. Any number of CLIPPING
> > statements may appear in a file. The current clip-setting is passed down to
> > subfiles when they are referenced, giving superfiles some influence over the
> > processing of subfiles. However, the clip-setting is *not* passed back up
> > from the subfile to the superfile.
>
> Also, you could stress that, CLIPPING ON in a file has no effect if
> clipping is currently off.
OK.
> > The INVERT meta-statement is a flag, indicating to the renderer that the
> > following subfile reference has been intentionally inverted. If the next
> > command-line is not a subfile reference, the INVERT is ignored.
> >
> > The INVERT flag is required in addition to the actual inversion, which
> > occurs within the subfile command's transformation matrix.
>
> Or:
> The INVERT meta-statement is a flag, indicating to the renderer that the
> following subfile reference should have its orientaion inverted, i.e. the
> inside/outside definition should be swapped.
OK.
Steve
"Never trust anything that can think for itself, if you can't see where it keeps its brain."
| | | | | | | | | | | | | | | | | | |
Steve Bliss wrote in message <380e2b8e.12563517@lugnet.com>...
> 0 INVERT
>
> The INVERT meta-statement is a flag, indicating to the renderer that the
> following subfile reference has been intentionally inverted. If the next
> command-line is not a subfile reference, the INVERT is ignored.
>
> The INVERT flag is required in addition to the actual inversion, which
> occurs within the subfile command's transformation matrix.
An orientation matrix doesn't contain enough information to invert an
asymmetrical part; if you assume it does, this would result in a part with a
mirrored shape.
I propose that (1) INVERT be explicitly used instead of relying on negative
determinants, and (2) no matrix should ever have a negative determinant.
I don't know how many asymmetrical subparts there are, if any, so I don't
know if this is a relevant point or not.
-Gary
| | | | | | | | | | | | | | | | | | | | | |
| |
|
Gary Williams wrote in message ...
> An orientation matrix doesn't contain enough information to invert an
> asymmetrical part; if you assume it does, this would result in a part with • a
> mirrored shape.
>
> I propose that (1) INVERT be explicitly used instead of relying on negative
> determinants, and (2) no matrix should ever have a negative determinant.
>
> I don't know how many asymmetrical subparts there are, if any, so I don't
> know if this is a relevant point or not.
Well, what I meant to say is:
Matrices with negative determinants may be used for mirroring a part, BUT
the matrix should never be assumed to perform the actual inversion.
If a matrix has a negative determinant, the rendering program should reverse
the order that it processes that subfile's (and that subfile's subfiles')
vertices.
If an INVERT is encountered, then the rendering program should reverse the
vertex order again.
I apologize if this isn't making any sense, but to me it appears to be a
valid issue.
-Gary
| | | | | | | | | | | | | | | | | | | | | | |
On Thu, 21 Oct 1999 01:07:30 GMT, "Gary Williams" <graywolf@pcpros.net> wrote:
[clipped good stuff]
> I apologize if this isn't making any sense, but to me it appears to be a
> valid issue.
You are making sense, it is a valid issue, I've been missing the boat on
inversion for awhile now, and I'll update the document.
Should there be an explicit statement about mirroring in the document, perhaps
in a DAT file authors section? (Am I repeating myself between messages?)
Steve
"Never trust anything that can think for itself, if you can't see where it keeps its brain."
| | | | | | | | | | | | | | | | | | |
The proposal has been updated, with changes from Lars and Gary, some additional
definitions, and a new section of parts guidelines.
See it at <http://www.geocities.com/partsref/bfcspec.txt>.
The revision marks (along the left margin) will be maintained until we've got a
final document, then they'll be wiped out (becuase they really mess up
word-wrap). If someone has a suggestion for permanent revision marking, let's
hear it.
Steve
"Never trust anything that can think for itself, if you can't see where it keeps its brain."
| | | | | | | | | | | | | | | | | | | | |
Steve:
> The proposal has been updated, with changes from Lars and
> Gary, some additional definitions, and a new section of
> parts guidelines.
>
> See it at <http://www.geocities.com/partsref/bfcspec.txt>.
Good work.
I have one comment/clarification/question:
> Allowable Clipping. A file can only have clipping applied when the following
> conditions apply:
> - All superfiles are certified.
> - The current file is certified.
> - No superfile has disabled clipping.
has disabled clipping at the "calling point" for this
subfile.
The current wording _could_ be interpreted as "somewhere in
the file".
Play well,
Jacob
------------------------------------------------
-- E-mail: sparre@cats.nbi.dk --
-- Web...: <URL:http://www.ldraw.org/FAQ/> --
------------------------------------------------
| | | | | | | | | | | | | | | | | | | | | | |
On Fri, 22 Oct 1999 14:38:36 GMT, sparre@sys-323.risoe.dk (Jacob Sparre
Andersen) wrote:
> Steve:
> > Allowable Clipping. A file can only have clipping applied when the following
> > conditions apply:
> > - All superfiles are certified.
> > - The current file is certified.
> > - No superfile has disabled clipping.
> has disabled clipping at the "calling point" for this
> subfile.
>
> The current wording _could_ be interpreted as "somewhere in
> the file".
Good catch. I've been wondering how to describe/differentiate the "calling
point" or "current environment" idea. I'll put your update in the doc.
Steve
"Never trust anything that can think for itself, if you can't see where it keeps its brain."
| | | | | | | | | | | | | | | | | | |
On Wed, 20 Oct 1999 21:16:14 GMT, blisses@worldnet.att.net (Steve Bliss) wrote:
> <http://www.geocities.com/partsref/bfcspec.txt>
There hasn't been any discussion on this in almost two weeks. Does everyone
like this spec? Any issues? Are you programmers willing to implement this? Is
it ready to go to press?
Steve
| | | | | | | | | | | | | | | | | | | | | |
> On Wed, 20 Oct 1999 21:16:14 GMT, blisses@worldnet.att.net (Steve Bliss) wrote:
>
> > <http://www.geocities.com/partsref/bfcspec.txt>
>
> There hasn't been any discussion on this in almost two weeks. Does everyone
> like this spec? Any issues? Are you programmers willing to implement this? Is
I haven't had time to reply, hope to have soon.
> it ready to go to press?
NO !
It's not quite done iet ! 8)
> Steve
Rui Martins
| | | | | | | | | | | | | | | | | | | | | | |
Steve:
> > <http://www.geocities.com/partsref/bfcspec.txt>
>
> There hasn't been any discussion on this in almost two
> weeks. Does everyone like this spec? Any issues? Are
> you programmers willing to implement this? Is it ready to
> go to press?
I think it is ready, but I will print out a copy, and check
it tonight.
Play well,
Jacob
------------------------------------------------
-- E-mail: sparre@cats.nbi.dk --
-- Web...: <URL:http://www.ldraw.org/FAQ/> --
------------------------------------------------
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
> Steve:
>
> > > <http://www.geocities.com/partsref/bfcspec.txt>
> >
> > There hasn't been any discussion on this in almost two
> > weeks. Does everyone like this spec? Any issues? Are
> > you programmers willing to implement this? Is it ready to
> > go to press?
>
> I think it is ready, but I will print out a copy, and check
> it tonight.
>
> Play well,
>
> Jacob
As I said it is not ready iet.
The questions (options) that where up in the air, are still there,
no one as discussed them, after this spec file was created.
I don't have much time now, but here are several problems.
Examples:
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 basicly resumes to:
- You won't benefit from the changes, UNLESS ALL the files you use
are certified.
- Every already made (Old) model, won't ever benefit unless it is
redited.
This fact is a direct consequence of one of those questions (still in the
air) that is the fact if Clipping should be local or global.
This problem reflects appears because the proposed context is global.
Which I am against !
> 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 !?)
So now we can bend some of the rules, depending on path or something
else (which is not defined). How is this supposed to be implemented ?
And what about the suggestion that someone supplied, that the default
context should be clarified ?
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.
So IMHO it should be like this:
-----------------------
0 CERTIFY { BFC | NOBFC }
default: NOBFC
-----------------------
0 WINDING { CW | CCW | UNKNOWN }
default: CCW
> 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
-----------------------
0 CLIPPING { ON | OFF }
default: clipping off
----------------------------------------------------------------------
And by 'default' I mean, if the command is not given, that will be the
initial default state.
And some more things that I don't have time to write rightnow.
NOTE: Remember all the issues that Steve raised, when asked about them.
they haven't been discussed iet.
I which I had more time !
(I have a daughter now, 2 months old).
-------------
Rui Martins
| | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
Steve:
I have a small linguistic correction, but except for that,
I consider the document finished:
There will be a few requirements placed on the design of rendering programs,
in order to achieve correct renderings. Any program should may violate
^^^^^^^^^^
Wouldn't "may" be sufficient?
these requirements, if there is another way to acheive a valid rendering.
Rui:
> > > > <http://www.geocities.com/partsref/bfcspec.txt>
> I don't have much time now, but here are several problems.
>
> Examples:
>
> 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 !?!?
All the files in the relevant _branch_ of the rendering
tree.
If you certify your model, then every certified primitive
will be drawn with back-face-culling when it is used for a
certified part.
You can't get it any better!
As soon as all the primitives are certified and people start
to insert certification flags in their models, all certified
parts will be drawn with back-face-culling.
I repeat: You can't get it any better!
> This basicly resumes to:
> - You won't benefit from the changes, UNLESS ALL the files you use
> are certified.
Wrong.
> - Every already made (Old) model, won't ever benefit unless it is
> redited.
Yes, but if it only refers to ordinary parts, that is just a
matter of inserting a "0 CERTIFY BFC" line in the file.
I presume that the modelling programs (such as MLCAD) will
insert the "0 CERTIFY BFC" line automatically in all models
built in the "builder mode" (but not in "parts author
mode").
> > 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 !?)
It means that there could be an option in the renderer that
tells it that some files assume that their supermodels are
certified, even if they (the supermodels) don't contain a
"0 CERTIFY BFC" line.
This is just an _option_ for the renderers, which can make
them use back-face-culling on old models without a
"0 CERTIFY BFC" line.
> So now we can bend some of the rules, depending on path or something
> else (which is not defined). How is this supposed to be implemented ?
The renderers are allowed to give the user the _option_ of
bending the rules slightly.
> And what about the suggestion that someone supplied, that the default
> context should be clarified ?
> 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.
> So IMHO it should be like this:
> -----------------------
> 0 CERTIFY { BFC | NOBFC }
> default: NOBFC
No, but you could write it like this:
{ 0 CERTIFY [ BFC | NOBFC ] }
The default value is for the case where the statement is
omitted completely.
> -----------------------
> 0 WINDING { CW | CCW | UNKNOWN }
> default: CCW
No, but you could write it like this:
{ 0 WINDING [ CW | CCW | UNKNOWN ] }
Again, the default value is for the case where the statement
is omitted completely.
> > 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
This sounds correct, but do we want to eliminate this
syntactic sugar?
> -----------------------
> 0 CLIPPING { ON | OFF }
> default: clipping off
No, but you could write it like this:
{ 0 CLIPPING [ ON | OFF ] }
Play well,
Jacob
------------------------------------------------
-- E-mail: sparre@cats.nbi.dk --
-- Web...: <URL:http://www.ldraw.org/FAQ/> --
------------------------------------------------
| | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
> Steve:
>
> I have a small linguistic correction, but except for that,
> I consider the document finished:
>
> There will be a few requirements placed on the design of rendering programs,
> in order to achieve correct renderings. Any program should may violate
> ^^^^^^^^^^
> Wouldn't "may" be sufficient?
>
> these requirements, if there is another way to acheive a valid rendering.
Agreed, it's logical. Should is too strong ! not like must, but strong
anyway.
> Rui:
>
> > > > > <http://www.geocities.com/partsref/bfcspec.txt>
>
> > I don't have much time now, but here are several problems.
> >
> > Examples:
> >
> > 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 !?!?
>
> All the files in the relevant _branch_ of the rendering
> tree.
of course, but all files start on one root, if that is no BFC certified,
than no acceleration.
> If you certify your model, then every certified primitive
> will be drawn with back-face-culling when it is used for a
> certified part.
but a certified part can have sub parts not certified ! hence another
no-go.
> You can't get it any better!
Yes you can !
Every file (primitive / subpart / part / model) once certified, will
benefit for it
self, as long as CLIPPING is LOCAL.
There is only one problem, and that is the builder friendly INVERT
command context.
Example:
If some builder in the past made a file which enherently uses the
primitive/subpart inside-out, then when this primitive/subpart is
certified, all files that used it inside-out will have erroneously clipped
polygons.
I am shure that all you guys can figure out a solution for this, taking
into account the benefits of this option.
Some suggestion (haven't thought much one these iet):
- Only certify these error prune primitives after checking
all the already made subparts/parts that use them are certified.
Future subparts/parts should take the invert command into account.
OR
- supply the inside-out versions of these primitives, for compatibility
with older files.
OR
- Impose your rule (all tree branches must be certified) ONLY for
primitives (because they are the ones which are used inside-out
sometimes), but not to the whole tree branch.
OR
- Create a New file extension '*.dtc', for *.dat files which ware clipping
certified.
Do you have any more suggestions / constructive criticism.
> As soon as all the primitives are certified and people start
> to insert certification flags in their models, all certified
> parts will be drawn with back-face-culling.
That will take a lot of time. we should see progress (acceleration)
as soon as we start implementing it.
One major acceleration will be the 'stud.dat' file, because, AFAIK
no one uses it inside-out.
> I repeat: You can't get it any better!
see above.
> > This basicly resumes to:
> > - You won't benefit from the changes, UNLESS ALL the files you use
> > are certified.
>
> Wrong.
In branches, obviously, try to be constructive ;).
> > - Every already made (Old) model, won't ever benefit unless it is
> > redited.
>
> Yes, but if it only refers to ordinary parts, that is just a
> matter of inserting a "0 CERTIFY BFC" line in the file.
NO, all your *.dat files in every tree branch born on the top level
*.dat file (the model).
> I presume that the modelling programs (such as MLCAD) will
> insert the "0 CERTIFY BFC" line automatically in all models
> built in the "builder mode" (but not in "parts author
> mode").
Good suggestion !
> > > 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 !?)
>
> It means that there could be an option in the renderer that
> tells it that some files assume that their supermodels are
> certified, even if they (the supermodels) don't contain a
> "0 CERTIFY BFC" line.
>
> This is just an _option_ for the renderers, which can make
> them use back-face-culling on old models without a
> "0 CERTIFY BFC" line.
>
> > So now we can bend some of the rules, depending on path or something
> > else (which is not defined). How is this supposed to be implemented ?
>
> The renderers are allowed to give the user the _option_ of
> bending the rules slightly.
These things makes me remember the word 'hacking', until you get your
code running.
> > And what about the suggestion that someone supplied, that the default
> > context should be clarified ?
>
> > 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.
>
> > So IMHO it should be like this:
> > -----------------------
> > 0 CERTIFY { BFC | NOBFC }
> > default: NOBFC
>
> No, but you could write it like this:
>
> { 0 CERTIFY [ BFC | NOBFC ] }
Resuming the above, and all the other examples which were after this last
example:
If you read the paragraph with the '{','}' ... etc (go read it again
please).
What it means is that with a rule like this:
0 CERTIFY [ BFC | NOBFC ]
you can come up with the following line:
0 CERTIFY
which is what should NOT be allowed ! Expecially in this case, if you
want this Meta-Command to be usefull/compatible for other certifications
in the future.
something like this:
{ 0 CERTIFY [ BFC | NOBFC ] }
is even worse, because it does not allow you to ommited the command
entirelly, this syntax as no logic at all. Maybe you swapped the context
of the '{' with the one of the '['.
But in any case, the whole command does not need to surrounded by
anything.
> The default value is for the case where the statement is
> omitted completely.
The same ideia here, Agreed.
> <SNIP>...
>
> > > 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
>
> This sounds correct, but do we want to eliminate this
> syntactic sugar?
why not ?
Could you give a good reason !
See ya,
-----------
Rui Martins
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
[ Still discussing http://www.geocities.com/partsref/bfcspec.txt ]
Rui:
> > > Allows a mix of extended and unextended files in one rendering, but
> > > to allow clipping, all files, have to be certified !?!?
> >
> > All the files in the relevant _branch_ of the rendering
> > tree.
>
> of course, but all files start on one root, if that is no BFC certified,
> then no acceleration.
Yes, but generally it is no big deal to certify a model file
- and there is the suggested option for the renderers
mentioned further down for the lazy.
> > If you certify your model, then every certified primitive
> > will be drawn with back-face-culling when it is used for a
> > certified part.
> but a certified part can have sub parts not certified ! hence another
> no-go.
Yes, but we aren't all that stupid. We will of cause start
certifying the primitives and critical sub-parts.
> > As soon as all the primitives are certified and people start
> > to insert certification flags in their models, all certified
> > parts will be drawn with back-face-culling.
>
> That will take a lot of time. we should see progress (acceleration)
> as soon as we start implementing it.
You can't eat a cake before you've baked it!
[...]
> > The renderers are allowed to give the user the _option_ of
> > bending the rules slightly.
>
> These things makes me remember the word 'hacking', until you get your
> code running.
It is an indirect way of accepting the files in the PARTS
directory as something special. Some of us feel that it is
important that all DAT files are equal (even though it, at
the moment, is practical that some are more equal than
others).
> > > 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.
I got it wrong first time.
I remember to have learnt that
( ... ) - means one copy of "...". This is just used to
group alternatives.
[ ... ] - means zero or one copy of "...".
{ ... } - means zero or more copies of "...".
According to that grammar, the production rules should be
written:
certification = "0" "CERTIFY" ( "BFC" | "NOBFC" ) { certification_flag }
winding = "0" "WINDING" ( "CW" | "CCW" | "UNKNOWN" )
clipping = "0" "CLIPPING" ( "ON" | "OFF" )
invert = "0" "INVERT"
> > This sounds correct, but do we want to eliminate this
> > syntactic sugar?
>
> why not ?
I like it.
Play well,
Jacob
------------------------------------------------
-- E-mail: sparre@cats.nbi.dk --
-- Web...: <URL:http://www.ldraw.org/FAQ/> --
------------------------------------------------
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
On Tue, 9 Nov 1999 11:17:47 GMT, sparre@sys-323.risoe.dk (Jacob Sparre Andersen)
wrote:
> [ Still discussing http://www.geocities.com/partsref/bfcspec.txt ]
> certification = "0" "CERTIFY" ( "BFC" | "NOBFC" ) { certification_flag }
> winding = "0" "WINDING" ( "CW" | "CCW" | "UNKNOWN" )
> clipping = "0" "CLIPPING" ( "ON" | "OFF" )
> invert = "0" "INVERT"
You'll pardon me if I use an abbreviated notation, and skip the " characters.
> > > This sounds correct, but do we want to eliminate this
> > > syntactic sugar?
> >
> > why not ?
>
> I like it.
It's hard to argue with that.
Steve
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Steve:
> > [ Still discussing http://www.geocities.com/partsref/bfcspec.txt ]
> > certification = "0" "CERTIFY" ( "BFC" | "NOBFC" ) { certification_flag }
> > winding = "0" "WINDING" ( "CW" | "CCW" | "UNKNOWN" )
> > clipping = "0" "CLIPPING" ( "ON" | "OFF" )
> > invert = "0" "INVERT"
>
> You'll pardon me if I use an abbreviated notation, and skip the "
> characters.
Yes.
> > > > This sounds correct, but do we want to eliminate this
> > > > syntactic sugar?
> > >
> > > why not ?
> >
> > I like it.
>
> It's hard to argue with that.
The argument against should be that it complicates the
rendering significantly, but I don't think it does.
Play well,
Jacob
------------------------------------------------
-- E-mail: sparre@cats.nbi.dk --
-- Web...: <URL:http://www.ldraw.org/FAQ/> --
------------------------------------------------
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
> <SNIP> ...
> > but a certified part can have sub parts not certified ! hence another
> > no-go.
>
> Yes, but we aren't all that stupid. We will of cause start • -------------------------
> certifying the primitives and critical sub-parts.
Don't take this so personally, it's not worth it.
I am only trying to contribute to a worthy cause (LEGO).
Everyone can have different opinions.
I don't need to jump on the other guys traught.
Anyway, I apologise if I have offended anyone,
but I think I haven't.
> > > As soon as all the primitives are certified and people start
> > > to insert certification flags in their models, all certified
> > > parts will be drawn with back-face-culling.
> >
> > That will take a lot of time. we should see progress (acceleration)
> > as soon as we start implementing it.
>
> You can't eat a cake before you've baked it!
I was thinking more on the lines of, a table full of cakes (parts), but
until you fill the table you can start eating the cakes which are already
there. 8-P
-----------
Rui Martins
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
On Wed, 10 Nov 1999 12:53:51 GMT, Rui Martins <Rui.Martins@link.pt> wrote:
> > You can't eat a cake before you've baked it!
>
> I was thinking more on the lines of, a table full of cakes (parts), but
> until you fill the table you can start eating the cakes which are already
> there. 8-P
In our case, it makes sense to make a single trip to the store for ingredients
(primitives). Once we've got the ingredients on-hand, we can start baking the
cakes.
Steve
No, this didn't really add to the discussion. I just liked the analogy.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
On Mon, 8 Nov 1999 16:38:50 GMT, Rui Martins <Rui.Martins@link.pt> wrote:
> > > > 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
> >
> > This sounds correct, but do we want to eliminate this
> > syntactic sugar?
>
> why not ?
> Could you give a good reason !
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.
Steve
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
Steve Bliss wrote...
> 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.
Good point!
Jacob Sparre Andersen wrote:
> [ Still discussing http://www.geocities.com/partsref/bfcspec.txt ]
> certification = "0" "CERTIFY" ( "BFC" | "NOBFC" ) { certification_flag }
> winding = "0" "WINDING" ( "CW" | "CCW" | "UNKNOWN" )
> clipping = "0" "CLIPPING" ( "ON" | "OFF" )
> invert = "0" "INVERT"
Or you could write:
0 CERTIFY BFC | 0 CERTIFY NOBFC
0 WINDING CW | 0 WINDING CCW | 0 WINDING UNKNOWN
(I don't think "0 WINDING" alone makes much sense)
0 CLIPPING ON | 0 CLIPPING OFF
0 INVERT
(or maybe "0 INVERTNEXT" to stress that it is only the following
line, which must be of type 1, that is turned inside-out)
Still discussing http://www.geocities.com/partsref/bfcspec.txt :
The CERTIFY section:
> operational command-line in the file. No other statements are required • for
> backface culling to be applied to a file.
Then please add:
0 CERTIFY BFC implies 0 CLIPPING ON and 0 WINDING CCW.
The WINDING section:
> 0 WINDING [ CW | CCW | UNKNOWN ]
> default: CCW
As "0 WINDING" alone doesn't make much sense, the "default: CCW" should
be deleted. The default value should not refer to what 0 CERTIFY BFC
implies - you don't have a default for CLIPPING.
> UNKNOWN = winding direction is unknown or variable. This setting will • disable
> clipping, until the winding is reset.
>
> The WINDING setting is a local setting, it applies only to the polygons in
> the file in which the WINDING meta-statement appears.
"...This setting will disable clipping..." - I hope readers do not confuse
this with CLIPPING OFF. Although the next sentence says WINDING is local,
it should be made clear that clipping is not turned off for subfiles.
Can you think of a better wording of the two sentences?
Also there should be some words about using 0 CLIPPING OFF for a
double-sided
section of a file.
Well, we could start working right now by updating the primitives reference
http://www.ldraw.org/memorial/archive/FAQ/Primitives_Reference
by adding newer primitives and stating the orientation.
If we "invent" another meta command, like
0 ORIENTATIONARROW x1 y1 z1 x2 y2 z2
rendering programs could optionally draw an arrow and you could save
a nice bitmap for the primitives reference.
/Lars
PS. Jean-Pierre PARIS, how are you doing?
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
On Wed, 10 Nov 1999 00:44:17 GMT, "Lars C. Hassing" <lch@ccieurope.com> wrote:
Still discussing <http://www.geocities.com/partsref/bfcspec.txt>
> Jacob Sparre Andersen wrote:
> > [ Still discussing http://www.geocities.com/partsref/bfcspec.txt ]
> > certification = "0" "CERTIFY" ( "BFC" | "NOBFC" ) { certification_flag }
> > winding = "0" "WINDING" ( "CW" | "CCW" | "UNKNOWN" )
> > clipping = "0" "CLIPPING" ( "ON" | "OFF" )
> > invert = "0" "INVERT"
>
> Or you could write:
> 0 CERTIFY BFC | 0 CERTIFY NOBFC
Yes, but the 0 CERTIFY ( BFC | NOBFC ) format is more common. And it emphasizes
that is one statement with various parameters. And it's less typing.
> 0 WINDING CW | 0 WINDING CCW | 0 WINDING UNKNOWN
> (I don't think "0 WINDING" alone makes much sense)
True. Using the parantheses ( ) to group the parameters indicates that one of
the options *must* be used. The square brackets [ ], that I used originally,
indicated that the parameters were optional. Which was definitely *not* the
intention.
> 0 INVERT
> (or maybe "0 INVERTNEXT" to stress that it is only the following
> line, which must be of type 1, that is turned inside-out)
Hmm. Interesting thought. I like it. Anyone else want to ( yay | nay ) this?
> The CERTIFY section:
> > operational command-line in the file. No other statements are required • for
> > backface culling to be applied to a file.
>
> Then please add:
> 0 CERTIFY BFC implies 0 CLIPPING ON and 0 WINDING CCW.
CERTIFY BFC doesn't imply CLIPPING ON -- the clipping mode/setting comes from
the superfile (for the main model-file, clipping is set by the rendering engine
or an explicit CLIPPING ON statement).
WINDING CCW is the default for files, as stated in the section for WINDING.
CERTIFY doesn't imply CCW winding at all--if a file started with these two
lines:
0 WINDING CW
0 CERTIFY BFC
... the winding should be CW, right?
If the CERTIFY statement 'implied' the winding, then this example would not be
clear (at least to the human reader) if the winding for this file is CW or CCW.
Does CERTIFY override the earlier WINDING or not?
That's why the WINDING setting has a default value, and CERTIFY doesn't affect
the WINDING setting in any way.
BUT, I'll see what I can do with the verbiage, to make thing more clear.
> The WINDING section:
> > 0 WINDING [ CW | CCW | UNKNOWN ]
> > default: CCW
> As "0 WINDING" alone doesn't make much sense, the "default: CCW" should
> be deleted. The default value should not refer to what 0 CERTIFY BFC
> implies - you don't have a default for CLIPPING.
WINDING is a file-specific setting, and it is appropriate to have a default
value for it. The default value applies before the first (if any) WINDING
statement. It is not valid to specify 0 WINDING with no parameter.
CLIPPING doesn't need a default, because it is passed down from the superfile.
It is up to the rendering engine to provide the initial value of CLIPPING.
> > UNKNOWN = winding direction is unknown or variable. This setting will • disable
> > clipping, until the winding is reset.
> >
> > The WINDING setting is a local setting, it applies only to the polygons in
> > the file in which the WINDING meta-statement appears.
>
> "...This setting will disable clipping..." - I hope readers do not confuse
> this with CLIPPING OFF. Although the next sentence says WINDING is local,
> it should be made clear that clipping is not turned off for subfiles.
> Can you think of a better wording of the two sentences?
> Also there should be some words about using 0 CLIPPING OFF for a
> double-sided section of a file.
Ergh. Thank you for pointing this out. I had not thought through all the
implications of the WINDING UNKNOWN (maybe WINDING NONE?) setting.
My intention was that WINDING UNKNOWN *would* disable clipping for subfiles, but
that is obviously *not* the way the document is written, and making things work
that way would be non-elegant. Then again, it seems counter-productive to
require part-authors to use both WINDING UNKNOWN and CLIPPING OFF when they make
use of subfiles in a non-compliant or double-sided section.
Maybe it would be better to drop WINDING UNKNOWN and specify that the default
value for CLIPPING is ON. File authors would use CLIPPING OFF for double-sided
or non-compliant sections of code. Note that the CLIPPING default would really
only effect the main file in a rendering, because superfiles would pass down
their clip-setting to subfiles.
Curent_Clip = Local_Clip and Super_File_Clip
Making this change would bring us closer to a consensus, it would simplify the
spec and keep it clean, and would eliminate overlapping and potentially
confusing functions.
> Well, we could start working right now by updating the primitives reference
> http://www.ldraw.org/memorial/archive/FAQ/Primitives_Reference
> by adding newer primitives and stating the orientation.
Good idea. That should be another thread, shouldn't it?
> If we "invent" another meta command, like
> 0 ORIENTATIONARROW x1 y1 z1 x2 y2 z2
> rendering programs could optionally draw an arrow and you could save
> a nice bitmap for the primitives reference.
Nice idea. You need a scale factor as well. Primitives are drawn in a variety
of scales (well, two scales: full size and -1-to-+1). For a reference document,
you'd need to be able to *see* all the primitives.
Considering how frequently some primitives are referenced in a rendered scene,
I'd rather minimize the excess data in the primitive files. I realize that
optimized renderers will only read and parse each file once, but why throw in
something that isn't necessary to the process of rendering.
We could just make a file which steps through each of the primitives, including
an orientation vectors. Something like (the first arrow is not right):
0 Primitive Reference
0 Name: PRIMREF.DAT
0 WRITE 1-4CON1.DAT 1/4 Cone Section 1:2 Radius, Scale: 10x
1 16 0 0 0 10 0 0 0 10 0 0 0 10 1-4con1.dat
2 24 -10 5 0 -30 5 0
3 24 -30 5 0 -25 5 2.5 -25 5 -2.5
0 STEP
0 CLEAR
0 WRITE 4-4DISC.DAT Full Disc, (X,Z)= (-1 to 1, -1 to 1), Scale: 10x
1 16 0 0 0 10 0 0 0 10 0 0 0 10 4-4disc.dat
2 24 0 0 0 0 -30 0
3 24 0 -30 0 -2.5 -25 0 2.5 -25 0
0 etc, etc
Then we could just add new primitives as they appear. Kind of awkward to view,
but it could be a way to proceed.
Steve
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
Steve Bliss wrote...
> On Wed, 10 Nov 1999 00:44:17 GMT, "Lars C. Hassing" <lch@ccieurope.com> wrote:
> > The CERTIFY section:
> > > operational command-line in the file. No other statements are required for
> > > backface culling to be applied to a file.
> >
> > Then please add:
> > 0 CERTIFY BFC implies 0 CLIPPING ON and 0 WINDING CCW.
>
> CERTIFY BFC doesn't imply CLIPPING ON -- the clipping mode/setting comes from
> the superfile (for the main model-file, clipping is set by the rendering engine
> or an explicit CLIPPING ON statement).
But it *does* imply CLIPPING ON. Otherwise clipping would be off.
Remember, CLIPPING ON cannot turn clipping on if turned off in a
superfile.
If you render the part alone (just to view the single part) the CERTIFY
should enable clipping just like an explicit CLIPPING ON statement,
which you mentioned yourself above.
> WINDING CCW is the default for files, as stated in the section for WINDING.
> CERTIFY doesn't imply CCW winding at all--if a file started with these two
> lines:
>
> 0 WINDING CW
> 0 CERTIFY BFC
>
> ... the winding should be CW, right?
Well, it depends on what you mean by "operational command-line" in
"Every clippable file must include exactly one CERTIFY meta-statement,
and it must appear before the first operational command-line in the file."
It could also be an error if the CERTIFY is not first!
> > > UNKNOWN = winding direction is unknown or variable. This setting will
> > > disable clipping, until the winding is reset.
> > >
> > > The WINDING setting is a local setting, it applies only to the polygons in
> > > the file in which the WINDING meta-statement appears.
> >
> > "...This setting will disable clipping..." - I hope readers do not confuse
> > this with CLIPPING OFF. Although the next sentence says WINDING is local,
> > it should be made clear that clipping is not turned off for subfiles.
> > Can you think of a better wording of the two sentences?
> > Also there should be some words about using 0 CLIPPING OFF for a
> > double-sided section of a file.
>
> Ergh. Thank you for pointing this out. I had not thought through all the
> implications of the WINDING UNKNOWN (maybe WINDING NONE?) setting.
>
> My intention was that WINDING UNKNOWN *would* disable clipping for subfiles, but
> that is obviously *not* the way the document is written, and making things work
> that way would be non-elegant. Then again, it seems counter-productive to
> require part-authors to use both WINDING UNKNOWN and CLIPPING OFF when they make
> use of subfiles in a non-compliant or double-sided section.
Part-authors only have to use CLIPPING OFF, as it turns off clipping
for both local polygons (i.e. WINDING UNKNOWN is not needed) as well
as polygons in subfiles.
> Maybe it would be better to drop WINDING UNKNOWN and specify that the default
> value for CLIPPING is ON. File authors would use CLIPPING OFF for double-sided
> or non-compliant sections of code. Note that the CLIPPING default would really
> only effect the main file in a rendering, because superfiles would pass down
> their clip-setting to subfiles.
>
> Curent_Clip = Local_Clip and Super_File_Clip
>
> Making this change would bring us closer to a consensus, it would simplify the
> spec and keep it clean, and would eliminate overlapping and potentially
> confusing functions.
Yes.
> We could just make a file which steps through each of the primitives, including
> an orientation vectors. Something like (the first arrow is not right):
>
> 0 Primitive Reference
> 0 Name: PRIMREF.DAT
> 0 WRITE 1-4CON1.DAT 1/4 Cone Section 1:2 Radius, Scale: 10x
> 1 16 0 0 0 10 0 0 0 10 0 0 0 10 1-4con1.dat
> 2 24 -10 5 0 -30 5 0
> 3 24 -30 5 0 -25 5 2.5 -25 5 -2.5
> 0 STEP
> 0 CLEAR
> 0 WRITE 4-4DISC.DAT Full Disc, (X,Z)= (-1 to 1, -1 to 1), Scale: 10x
> 1 16 0 0 0 10 0 0 0 10 0 0 0 10 4-4disc.dat
> 2 24 0 0 0 0 -30 0
> 3 24 0 -30 0 -2.5 -25 0 2.5 -25 0
> 0 etc, etc
>
> Then we could just add new primitives as they appear. Kind of awkward to view,
> but it could be a way to proceed.
Though I think it is always better to place the information where it
belongs, your PRIMREF.DAT is a brilliant idea - scaling fixed too!
It looks good (nice arrows) and uses the tools we already have.
/Lars
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
[ Still discussing http://www.geocities.com/partsref/bfcspec.txt ]
Steve:
> On Wed, 10 Nov 1999 00:44:17 GMT, "Lars C. Hassing"
> <lch@ccieurope.com> wrote:
[...]
> > 0 INVERT
> > (or maybe "0 INVERTNEXT" to stress that it is only the
> > following line, which must be of type 1, that is turned
> > inside-out)
>
> Hmm. Interesting thought. I like it. Anyone else want
> to ( yay | nay ) this?
"INVERTNEXT" is good. It makes the effect much more clear.
> > The CERTIFY section:
> > > operational command-line in the file. No other
> > > statements are required for backface culling to be
> > > applied to a file.
> >
> > Then please add:
> > 0 CERTIFY BFC implies 0 CLIPPING ON and 0 WINDING CCW.
>
> CERTIFY BFC doesn't imply CLIPPING ON -- the clipping
> mode/setting comes from the superfile (for the main
> model-file, clipping is set by the rendering engine or an
> explicit CLIPPING ON statement).
It gets much too messy when you mix the states of a
parameter and the setting of that parameter.
CERTIFY BFC does imply CLIPPING ON, but it will not
necessarily mean that any clipping will be done, because
that depends on the super-file as well.
When processing a LDraw file you have three _local_
variables:
- "bfc-certified" is initialised to false and should at
most be changed once by a LDraw file.
- "winding" is initialised to "ccw".
- "clipping" is initialised to "on".
The statement "0 CERTIFIED ( BFC | NOBFC )" will modify the
variable "bfc-certified", the statement "0 WINDING ( CW |
CCW | UNKNOWN )" will modify the variable "winding", and the
statement "0 CLIPPING ( ON | OFF )" will modify the variable
"clipping".
Two parameters are passed to the processing routine:
- "accumulated_clipping" is true when processing the root
file, and will otherwise only be true if both
"accumulated_clipping" and "clipping" were true in the
super file at the calling point.
- "inverted" is false when processing the root file, and
will otherwise depend on whether the calling statement
was preceded by a "0 INVERTNEXT" line. If it was, the
value of "inverted" will be the opposite of that in the
super file. If it wasn't tha value will be the same as
that in the super file.
Back-face-culling will only be applied if all of the
following apply:
- "bfc-certified" is true
- "accumulated_clipping" is true
- "clipping" is true
- "winding" is "cw" or "ccw"
The winding used for back-face-culling will be that of the
variable "winding", if "inverted" is false. Otherwise it
will be the opposite ("unknown" being neutral).
> 0 WINDING CW
> 0 CERTIFY BFC
>
> ... the winding should be CW, right?
Maybe. It depends on the definition of "operational
command-line".
I understand why you sometimes use specialised "programming"
languages for writing specifications.
> If the CERTIFY statement 'implied' the winding, then this
> example would not be clear (at least to the human reader)
> if the winding for this file is CW or CCW.
> Does CERTIFY override the earlier WINDING or not?
If "0 WINDING CW" is an operational command-line, it doesn't
matter. Otherwise the result is somewhat unclear. I would
prefer that that sequence wasn't allowed.
There isn't much point in allowing the use of BFC
meta-commands before you have notified the renderer that you
intend to follow the rules for BFC meta-commands.
> That's why the WINDING setting has a default value, and
> CERTIFY doesn't affect the WINDING setting in any way.
>
> BUT, I'll see what I can do with the verbiage, to make
> things more clear.
> > The WINDING section:
> > > 0 WINDING [ CW | CCW | UNKNOWN ]
> > > default: CCW
The default value is not for the WINDING _statement_, but
for the "winding" variable.
> CLIPPING doesn't need a default, because it is passed down
> from the superfile. It is up to the rendering engine to
> provide the initial value of CLIPPING.
The "clipping" variable does need to have a default value.
Otherwise you would be unable to distinguish between the
local setting and the clipping _status_ passed from the
super file (or you would break the clipping rules).
> Maybe it would be better to drop WINDING UNKNOWN and
> specify that the default value for CLIPPING is ON.
I don't think so. If you could translate my explanation
above to proper English, then the problem should be solved,
with the effect I understand you intended.
Play well,
Jacob
------------------------------------------------
-- E-mail: sparre@cats.nbi.dk --
-- Web...: <URL:http://www.ldraw.org/FAQ/> --
------------------------------------------------
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev, Jacob Sparre Andersen wrote:
> [ Still discussing http://www.geocities.com/partsref/bfcspec.txt ]
>
> Steve:
>
> > On Wed, 10 Nov 1999 00:44:17 GMT, "Lars C. Hassing"
> > <lch@ccieurope.com> wrote:
> > > 0 INVERT
> > > (or maybe "0 INVERTNEXT" to stress that it is only the
> > > following line, which must be of type 1, that is turned
> > > inside-out)
> >
> > Hmm. Interesting thought. I like it. Anyone else want
> > to ( yay | nay ) this?
>
> "INVERTNEXT" is good. It makes the effect much more clear.
OK, I'll change this in the document. Changes from the last few days will be
uploaded to GeoCities in the next hour or so.
Steve
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev, Jacob Sparre Andersen wrote:
> [ Still discussing http://www.geocities.com/partsref/bfcspec.txt ]
> > 0 WINDING CW
> > 0 CERTIFY BFC
> >
> > ... the winding should be CW, right?
>
> Maybe. It depends on the definition of "operational
> command-line".
>
> I understand why you sometimes use specialised "programming"
> languages for writing specifications.
Did you mean you=Steve or you=anyone?
> > If the CERTIFY statement 'implied' the winding, then this
> > example would not be clear (at least to the human reader)
> > if the winding for this file is CW or CCW.
> > Does CERTIFY override the earlier WINDING or not?
>
> If "0 WINDING CW" is an operational command-line, it doesn't
> matter. Otherwise the result is somewhat unclear. I would
> prefer that that sequence wasn't allowed.
I agree, the sequence should be illegal.
My point was, does CERTIFY BFC change the value of the internal local_clipping
variable, or not? My intention was that it does not. From a practical
viewpoint, it might as well, but it is not necessary for it to do so.
> The default value is not for the WINDING _statement_, but
> for the "winding" variable.
Good point. I will incorporate this into the document.
> I don't think so. If you could translate my explanation
> above to proper English, then the problem should be solved,
> with the effect I understand you intended.
How about some pseudo-code? Skipping a few beside-the-point details:
Recursive Procedure RenderFile
Parameters:
ModelFile string // File to render
AccumClip boolean // global clipping value yes/no
AccumInvert boolean // current inversion odd/even or normal/inverted
Declare
LocalClip boolean = TRUE
Winding trivalue(CCW, CW, UNKNOWN) = CCW
Certified boolean = FALSE
InvertNext boolean = FALSE
OpenFile(ModelFile)
Do Until EOF(ModelFile)
Get Next Command
Case Command.LineType
CERTIFY
Certified = (Command.Option = "BFC")
CLIPPING
LocalClip = (Command.Option = "ON")
WINDING_CCW
If AccumInvert Then
Winding = CW
Else
Winding = CCW
WINDING_CW
If AccumInvert Then
Winding = CCW
Else
Winding = CW
WINDING_UNKNOWN
Winding = UNKNOWN
INVERTNEXT
InvertNext = True
SUBFILE
RenderFile Command.Subfile,
(AccumClip and LocalClip),
(AccumInvert xor InvertNext)
LINE, CONDITIONAL_LINE
Deal with primitive command
TRIANGLE, QUAD
If AccumClip and LocalClip Then
If BFC(Command, TransformMatrix, Winding) Then
Render Command
Else
Don't render Command
Else
Render Command
End If
End Case
If Command.LineType != INVERTNEXT Then
InvertNext = FALSE
End If
Loop
End Procedure
Ick. Longer than I thought. Maybe I'll go back to plain English.
Steve
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
[ Still discussing http://www.geocities.com/partsref/bfcspec.txt ]
Steve:
> In lugnet.cad.dev, Jacob Sparre Andersen wrote:
> > I understand why you sometimes use specialised "programming"
> > languages for writing specifications.
>
> Did you mean you=Steve or you=anyone?
You=anyone (kind of - English is a very imprecise language - "on"
in French, "man" in Danish, ...)
> My point was, does CERTIFY BFC change the value of the
> internal local_clipping variable, or not? My intention
> was that it does not. From a practical viewpoint, it
> might as well, but it is not necessary for it to do so.
That depends on how the program is written. You could
imagine that the variable "local_clipping" isn't defined
until it is verified that it is relevant.
> > I don't think so. If you could translate my explanation
> > above to proper English, then the problem should be solved,
> > with the effect I understand you intended.
>
> How about some pseudo-code? Skipping a few beside-the-point details:
[...]
Good. I think this clarifies a lot.
> Ick. Longer than I thought. Maybe I'll go back to plain English.
I don't think you can make it shorter as plain English, but
I will not complain if you attempt.
Play well,
Jacob
------------------------------------------------
-- E-mail: sparre@cats.nbi.dk --
-- Web...: <URL:http://www.ldraw.org/FAQ/> --
------------------------------------------------
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Steve Bliss wrote ...
> How about some pseudo-code
I think your pseudo-code delivers a fine evidence why the CERTIFY
is unnecessary ;-)
/Lars
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Oops! Forget a few important details in the psuedo-code!
In lugnet.cad.dev, Steve Bliss writes:
> ModelFile string // File to render
> AccumClip boolean // global clipping value yes/no
> AccumInvert boolean // current inversion odd/even or normal/inverted
>
> Declare
> LocalClip boolean = TRUE
> Winding trivalue(CCW, CW, UNKNOWN) = CCW
> Certified boolean = FALSE
> InvertNext boolean = FALSE
>
> SUBFILE
> RenderFile Command.Subfile,
> (AccumClip and LocalClip),
The last line above should be:
(AccumClip and LocalClip and
(Winding != UNKNOWN) and Certified),
> (AccumInvert xor InvertNext)
> LINE, CONDITIONAL_LINE
> Deal with primitive command
> TRIANGLE, QUAD
> If AccumClip and LocalClip Then
And the line above should be:
If AccumClip and LocalClip
And Certified Then
> If BFC(Command, TransformMatrix, Winding) Then
> Render Command
> Else
> Don't render Command
> Else
> Render Command
> End If
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Steve Bliss wrote in message ...
> Oops! Forget a few important details in the psuedo-code!
>
> In lugnet.cad.dev, Steve Bliss writes:
>
> > ModelFile string // File to render
> > AccumClip boolean // global clipping value yes/no
> > AccumInvert boolean // current inversion odd/even or normal/inverted
> >
> > Declare
> > LocalClip boolean = TRUE
> > Winding trivalue(CCW, CW, UNKNOWN) = CCW
> > Certified boolean = FALSE
> > InvertNext boolean = FALSE
> >
> > SUBFILE
> > RenderFile Command.Subfile,
> > (AccumClip and LocalClip),
>
> The last line above should be:
> (AccumClip and LocalClip and
> (Winding != UNKNOWN) and Certified),
No, WINDING is local! It does not affect subfiles, this is the very reason
why we have invented the CLIPPING command.
/Lars
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev, Lars C. Hassing wrote:
> No, WINDING is local! It does not affect subfiles, this is the very reason
> why we have invented the CLIPPING command.
Argh. You are correct, sir. Serves me right, trying to post quickly.
Here's a correction:
> > > SUBFILE
> > > RenderFile Command.Subfile,
> > > (AccumClip and LocalClip),
> >
> > The last line above should be:
> > (AccumClip and LocalClip and Certified),
Steve
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
On Mon, 8 Nov 1999 16:38:50 GMT, Rui Martins <Rui.Martins@link.pt> wrote:
> of course, but all files start on one root, if that is no BFC certified,
> than no acceleration.
As Jacob said, this is why the specification suggests that rendering programs
allow the user to select the option of defaulting CLIPPING to on or off.
> but a certified part can have sub parts not certified ! hence another
> no-go.
Huh? In that case, the uncertified primitive is not back-face-culled, but the
certified part is bfc'ed. How do want to improve this? The rendering engine
can't bfc un-certified files.
> Every file (primitive / subpart / part / model) once certified, will
> benefit for itself, as long as CLIPPING is LOCAL.
Nope. No subfile in a rendering, which is below an uncertified file, can assume
it is normal or inverted. It doesn't matter if we define CLIPPING as local or
passed-down.
Steve
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Special:
|
[DAT] (requires LDraw-compatible viewer)
|
Subject:
|
Re: Line in the Sand
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Wed, 10 Nov 1999 12:44:49 GMT
|
Reply-To:
|
Rui.Martins@=saynotospam=link.pt
|
Viewed:
|
2574 times
|
| |
|
On Tue, 9 Nov 1999, Steve Bliss wrote:
> On Mon, 8 Nov 1999 16:38:50 GMT, Rui Martins <Rui.Martins@link.pt> wrote:
>
> > of course, but all files start on one root, if that is no BFC certified,
> > than no acceleration.
>
> As Jacob said, this is why the specification suggests that rendering programs
> allow the user to select the option of defaulting CLIPPING to on or off.
Strange sentence, CLIPPING is OFF by default, you can change that by
including a CLIPPING ON. And this was not what was beeing discussed. See
below.
> > but a certified part can have sub parts not certified ! hence another
> > no-go.
>
> Huh? In that case, the uncertified primitive is not back-face-culled, but the
> certified part is bfc'ed. How do want to improve this? The rendering engine
> can't bfc un-certified files.
Look at this two trees
root root
C N
/ \ / \
C N C N
/| |\ /| |\
C N C N C N C N
1 2 3 4 5 6 7 8
'C' means a certified .DAT
'N' means a NOT certified .DAT
Branch:
1: C-C-C accelerated. Hence all files (this is the best case)
2: C-C accelerated -N UNaccelerated
3: C accelerated N-C UNaccelerated
4: C accelerated N-C UNaccelerated
5: none accelerated N-C-C UNaccelerated
6: none accelerated N-C-N UNaccelerated
7: none accelerated N-N-C UNaccelerated
8: none accelerated N-N-N UNaccelerated (This is the current case)
with some tweaking case 5 and 6 could also accelerate the 'C'ertified
files.
So resuming, with your proposal you can't accelerate all the
certified files, with my proposal you CAN.
This becomes even more evident if you have a branch like:
C-N-C-C-C-N-C
The higher the 'N'ot certified file is, the worst the case is.
remember that the first step is branch 7, we will try to
certified/optimize the primitives files.
The Only thing that I have not taken into account iet is:
" if any of these files has an INVERT command. "
Your proposal will have the same acceleration problems, but
my proposal will keep its robustness, if the invert command is processed
in the following form: (I refreshed my ideia)
- We have a Global state variable which keeps track of the current invert
state (by branch. NOTE: we should use depth first search order to use
only one variable).
- if the current file is processed with:
* invert_state = INVERTED, we interpret winding CCW as CW and vice-versa.
* invert_state = NORMAL, we interpret winding CCW and CW normally.
Remember that my proposal uses CLIPPING as a local setting.
Is this too complicated ?
I think not, maybe I can't explain my self well, or you guys are beeing
to stubborn. ;P sheech.
P.S.
Minstorm yourselfs please.
___
/ /_
/_ /
/ /_
/_ /
//
/
Rui Martins
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
On Wed, 10 Nov 1999 12:44:49 GMT, Rui Martins <Rui.Martins@link.pt> wrote:
> On Tue, 9 Nov 1999, Steve Bliss wrote:
>
> > As Jacob said, this is why the specification suggests that rendering programs
> > allow the user to select the option of defaulting CLIPPING to on or off.
>
> Strange sentence, CLIPPING is OFF by default, you can change that by
> including a CLIPPING ON. And this was not what was beeing discussed. See
> below.
I don't think I understand you here. Do you mean that it is strange to let the
user and/or programmer of the rendering program set the initial CLIPPING value?
[clipped nice rendering-process tree]
> The Only thing that I have not taken into account iet is:
> " if any of these files has an INVERT command. "
>
> Your proposal will have the same acceleration problems, but
> my proposal will keep its robustness, if the invert command is processed
> in the following form: (I refreshed my ideia)
>
> - We have a Global state variable which keeps track of the current invert
> state (by branch. NOTE: we should use depth first search order to use
> only one variable).
>
> - if the current file is processed with:
> * invert_state = INVERTED, we interpret winding CCW as CW and vice-versa.
>
> * invert_state = NORMAL, we interpret winding CCW and CW normally.
>
> Is this too complicated ?
It's not too complicated. A rendering engine will always have to do this in
order to correctly clip polygons. But it won't allow us to make any assumptions
about C-N-C branches.
First question: which invert-state are we keeping track of, the occurrences of 0
INVERT or the determinant of the transformation matrix?
If we are tracking 0 INVERTS, then we must have certified files all the way down
the branch in order track the invert_state. One non-certified file breaks the
chain.
If we are just looking at the determinant of the transformation matrix, then we
don't need a global variable, the determinant can be id'ed locally. But the
determinant doesn't tell us what we need to know. We need to know the authors'
intentions when they wrote the various files in the branch. Did they mean to
invert or not?
There's no way to track the invert-state along a C-N-C branch.
The one assumption which can (generally) be made is this: references from the
main model file to the parts-files do *not* invert the subfile. If we also
*assume* the main model is certified[1], then any certified part-files can be
clipped.
Steve
1) Even if there's no 0 CERTIFY BFC in the main file, 99%+ model files are
compliant, because they only reference part-files, and do not intend to invert
the parts.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
On Sat, 6 Nov 1999 20:50:24 GMT, sparre@sys-323.risoe.dk (Jacob Sparre Andersen)
wrote:
> Steve:
>
> I have a small linguistic correction, but except for that,
> I consider the document finished:
>
> There will be a few requirements placed on the design of rendering programs,
> in order to achieve correct renderings. Any program should may violate
> ^^^^^^^^^^
> Wouldn't "may" be sufficient?
Yes, and 'may' is more more correct than 'should', since the "Rendering Engine
Requirements" section really is included just to provide a framework for the
language extensions. The document specifies the input, and we have a general
understanding about what the output should be, but the stuff in the middle is
internal to the rendering engine, and it can operate anyway the programmer
wants.
Maybe "Rendering Engine Requirements" should be renamed to something less
forceful?
Steve
| | | | | | | | | | | | | | | | | | | | | | | | |
On 5 Nov 1999, Rui Martins wrote:
> 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.
>
> So IMHO it should be like this:
> -----------------------
> 0 CERTIFY { BFC | NOBFC }
> default: NOBFC
I'll make these changes.
I think all your points have been discussed in follow-up messages, so I'll make
my responses (if there are any) to those later messages.
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.
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/> --
------------------------------------------------
| | | | | | | | | | | | | | | | | | | |
| |
|
Still discussing <http://www.geocities.com/partsref/bfcspec.txt>.
Here's another syntactical approach to BFC. Like it, hate it, let us know what
you think.
Have a single 0 BFC statement, which allows specifications of various
options/settings. Something like:
0 BFC ( CERTIFY | NOCERTIFY | CLIP | NOCLIP | CW | CCW | NOWIND | INVERTNEXT )+
The + symbol indicates 1 or more occurrences of the preceeding group.
this could be written as:
0 BFC [CERTIFY | NOCERTIFY] [CLIP | NOCLIP] [CW | CCW | NOWIND] [INVERTNEXT]
... with the understanding that options could be specified in any order.
CERTIFY = the file is compliant
NOCERTIFY = the file is not compliant
CLIP = enable clipping
NOCLIP = disable clipping
CW = polygon winding is clockwise
CCW = polygon winding is anti-clockwise
NOWIND = polygon winding is variable
INVERTNEXT = the next command is a subfile reference, and it is inverted.
Only one option of each group would be allowed on a single statement. So CLIP
and NOCLIP couldn't be both specified on the same BFC line.
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.
This approach has a couple of advantages:
- slightly simplify/streamline parsing, because only one meta-command is used.
- Allow us to get past the issue of "what statement should be used to mark
compliant files".
Steve
| | | | | | | | | | | | | | | | | | | | |
Steve:
> Still discussing <http://www.geocities.com/partsref/bfcspec.txt>.
>
> Here's another syntactical approach to BFC. Like it, hate
> it, let us know what you think.
[...]
It is definitely a useable option. How will the
specification document look then? If it is easier to read
that way, then you have one proponent for that solution.
Play well,
Jacob
------------------------------------------------
-- E-mail: sparre@cats.nbi.dk --
-- Web...: <URL:http://www.ldraw.org/FAQ/> --
------------------------------------------------
| | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev, Jacob Sparre Andersen wrote:
> Steve:
>
> > Still discussing <http://www.geocities.com/partsref/bfcspec.txt>.
> >
> > Here's another syntactical approach to BFC. Like it, hate
> > it, let us know what you think.
>
> [...]
>
> It is definitely a useable option. How will the
> specification document look then? If it is easier to read
> that way, then you have one proponent for that solution.
There are two possibilities for updating the document with this approach:
1. Just change the syntax expressions, and modify any syntax-specific
references. This would be the low-impact approach, with only cosmetic changes.
2. Rework the document. Add a new section which discusses the functional
requirements (must be able to turn clipping on and off, set the winding, and
invert subfiles), and change the existing "Language Extensions" section to
specify how the single 0 BFC statement implements the requirements.
I'll try doing #2 this weekend.
Steve
| | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev, Steve Bliss wrote:
Still discussing <http://www.geocities.com/partsref/bfcspec.txt>.
I posted a new version, with the short-form syntax, to
<http://www.geocities.com/partsref/bfcspecv4.txt>
Comments?
Steve
| | | | | | | | | | | | | | | | | | | | | | |
Steve:
> Still discussing <http://www.geocities.com/partsref/bfcspec.txt>.
>
> I posted a new version, with the short-form syntax, to
> <http://www.geocities.com/partsref/bfcspecv4.txt>
>
> Comments?
My comments/changes will be preceded by a "J".
[...]
Subfile. A DAT file referenced from another file, via a linetype 1 command.
Or any file which is lower in the file-reference tree than the current file.
J Or any file which is the subfile of the current file (or thus of any of its
J subfiles).
J
1 Subpart. A DAT file which is only a portion of a complete element. Does
[...]
4 CERTIFY
4 Certified = (Command.Option = "BFC")
4 CLIPPING
4 LocalClip = (Command.Option = "ON")
J What does this "Command.Option" stuff mean?
[...]
There may be more comments later, but I have to go now.
Play well,
Jacob
------------------------------------------------
-- E-mail: sparre@cats.nbi.dk --
-- Web...: <URL:http://www.ldraw.org/FAQ/> --
------------------------------------------------
| | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev, Jacob Sparre Andersen wrote:
> Steve:
>
> > Still discussing <http://www.geocities.com/partsref/bfcspec.txt>.
> >
> > I posted a new version, with the short-form syntax, to
> > <http://www.geocities.com/partsref/bfcspecv4.txt>
> >
> > Comments?
>
> My comments/changes will be preceded by a "J".
>
> [...]
> Subfile. A DAT file referenced from another file, via a linetype 1 command.
> Or any file which is lower in the file-reference tree than the current file.
>
> J Or any file which is the subfile of the current file (or thus of any of its
> J subfiles).
Er, OK. I'll put that in, but it seems redundant.
> 1 Subpart. A DAT file which is only a portion of a complete element. Does
> [...]
> 4 CERTIFY
> 4 Certified = (Command.Option = "BFC")
> 4 CLIPPING
> 4 LocalClip = (Command.Option = "ON")
>
> J What does this "Command.Option" stuff mean?
It means that I stuffed in the pseudo-code without rewriting the syntax-specific
sections. :(
Steve
| | | | | | | | | | | | | | | | | |
Still discussing:
<http://www.geocities.com/partsref/bfcspec.txt>
and now
<http://www.geocities.com/partsref/bfcspecv4.txt>
I posted an update to the v4 spec just now. It includes the changes suggested
by Jacob.
Things have been quiet lately, so I want to throw out a couple of questions:
Does anyone have an opinion on whether it would be preferable to go with the
original syntax approach (having several meta-statements), or the newer approach
(a single meta-statement, with options)?
Original:
0 CERTIFY ( BFC | NOBFC )
0 WINDING ( CW | CCW | UNKNOWN )
0 CLIPPING ( ON | OFF )
0 INVERTNEXT
Newer:
0 BFC [CERTIFY|NOCERTIFY] [CLIP|NOCLIP] [CW|CCW|NOWIND] [INVERTNEXT]
Will the newer specification address everybody's issues?
Maybe we can get this finalized before the end of the year. Well, a guy can
dream, right? ;)
Steve
| | | | | | | | | | | | | | | | | |
Steve:
> Still discussing:
> <http://www.geocities.com/partsref/bfcspec.txt>
> and now
> <http://www.geocities.com/partsref/bfcspecv4.txt>
> Does anyone have an opinion on whether it would be
> preferable to go with the original syntax approach (having
> several meta-statements), or the newer approach (a single
> meta-statement, with options)?
I kind of like the newer approach.
Play well,
Jacob
------------------------------------------------
-- E-mail: sparre@cats.nbi.dk --
-- Web...: <URL:http://www.ldraw.org/FAQ/> --
------------------------------------------------
| | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev, Steve Bliss writes:
> Still discussing:
> Maybe we can get this finalized before the end of the year. Well, a guy can
> dream, right? ;)
>
> Steve
at first i misread that as:
> Maybe we can get this finalized before the end of next year....
and thought to myself "wow, Steve's in a really cynical mood".. hehe.. guess
i'm just projecting my own cynicism...
J
| | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev, onyx wrote:
> In lugnet.cad.dev, Steve Bliss writes:
> > Still discussing:
> > Maybe we can get this finalized before the end of the year. Well, a guy can
> > dream, right? ;)
> >
> > Steve
>
> at first i misread that as:
> > Maybe we can get this finalized before the end of next year....
>
> and thought to myself "wow, Steve's in a really cynical mood".. hehe.. guess
> i'm just projecting my own cynicism...
I had originally written "before the end of this millenium", but I thought that
sounded too pessimistic. And I didn't want to give anyone an opening for the
2000/2001 diatribe.
Steve
Personally, I just care when the odometer rolls over.
| | | | | | | | | | | | | | | | | | | | | | |
Steve Bliss wrote:
> In lugnet.cad.dev, onyx wrote:
>
> > In lugnet.cad.dev, Steve Bliss writes:
> > > Still discussing:
> > > Maybe we can get this finalized before the end of the year. Well, a guy can
> > > dream, right? ;)
> > >
> > > Steve
> >
> > at first i misread that as:
> > > Maybe we can get this finalized before the end of next year....
> >
> > and thought to myself "wow, Steve's in a really cynical mood".. hehe.. guess
> > i'm just projecting my own cynicism...
>
> I had originally written "before the end of this millenium", but I thought that
> sounded too pessimistic. And I didn't want to give anyone an opening for the
> 2000/2001 diatribe.
>
> Steve
> Personally, I just care when the odometer rolls over.
If the academics are right, it may have rolled over in 1993/94; so many problems
are associated with just when we started counting, not to mention whether it's 2000
or 2001 years!
best,
LFB
| | | | | | | | | | | | | | | | | | | |
| |
|
Steve Bliss wrote...
> Still discussing:
> <http://www.geocities.com/partsref/bfcspec.txt>
> and now
> <http://www.geocities.com/partsref/bfcspecv4.txt>
>
> I posted an update to the v4 spec just now. It includes the changes suggested
> by Jacob.
>
> Things have been quiet lately, so I want to throw out a couple of questions:
>
> Does anyone have an opinion on whether it would be preferable to go with the
> original syntax approach (having several meta-statements), or the newer approach
> (a single meta-statement, with options)?
>
> Original:
> 0 CERTIFY ( BFC | NOBFC )
> 0 WINDING ( CW | CCW | UNKNOWN )
> 0 CLIPPING ( ON | OFF )
> 0 INVERTNEXT
>
> Newer:
> 0 BFC [CERTIFY|NOCERTIFY] [CLIP|NOCLIP] [CW|CCW|NOWIND] [INVERTNEXT]
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 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"
> 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"
> 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.
And this implies 0 BFC CLIP and 0 BFC CCW. (which should be added)
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.
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.
*
*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?
> 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.
> 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...
> 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"
> 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.
> 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.
BTW, "CERTIFY" - shouldn't it be "CERTIFIED" ?
> 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.
/Lars
| | | | | | | | | | | | | | | | | |
| |
|
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
| | | | | | | | | | | | | | | | | |
In lugnet.cad.dev, Steve Bliss writes:
> > > Still discussing:
> > > <http://www.geocities.com/partsref/bfcspec.txt>
> > > and now
> > > <http://www.geocities.com/partsref/bfcspecv4.txt>
Seems Geocities is having some trouble, and the shortcut URLs won't work. Try
these instead:
<http://www.geocities.com/SouthBeach/Lagoon/8641/bfcspec.txt>
<http://www.geocities.com/SouthBeach/Lagoon/8641/bfcspecv4.txt>
Steve
| | | | | | | | | | | | | | | | | | | | | |
| |
|
[ Still discussing
http://www.geocities.com/SouthBeach/Lagoon/8641/bfcspecv4.txt ]
Steve:
You can also put them on ldraw.org now that you have an
account here.
Here comes a commented/edited version. Lines starting with
"#" are my comments and lines starting with "J" are my
changes/additions.
------------------------------------------------------------------------------
[...]
7 revision: 7, 1999.12.08
[...]
4 Inversion is the one BFC option which accumulates globally. If the current
4 file is being rendered inverted, then any subfiles of the current file are
4 also rendered as inverted.
# In what sense is inversion more "global" than clipping?
[...]
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
# ^^^^^^^^^^^^^^^^^^^^^^^^^^
# You might want to make it more clear that it only refers
# to the _immediately_ following line.
[...]
There will be a few requirements placed on the design of rendering programs,
# ^^^^^^^^^^^^
# What about reformulating this as "implementation advice"
# (since "Any program may violate...").
[...]
Matrix Inversions. Rendering engines will need to correct for transformation
1 matrices which inadvertently invert a subfile. They will also need to
1 allow for situations in which the matrix is deliberately given a negative
1 determinant, in order to mirror the subfile.
# I suppose that the meaning of this statement is that the
# (C)CW-ness of the polygons is compensated for the
# determinant of the accumulated orientation matrix, but it
# is not very clear.
[...]
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
7 they were inverted. Assuming that all part files used in a rendering allows
7 the rendering engine to apply BFC-processing on these parts (assuming the
J parts are certified), even if the calling files aren't certified.
[...]
7 If 32 <= Color And Color <= 47 Then // This restriction may or may not be
7 AccumClip = FALSE // required, depending on the style of
7 End If // rendering for transparent surfaces.
# Shouldn't the check on colour numbers rather be formulated
# "If Transparent (Colour) Then"? We should remember that
# people can redefine the meaning of the colour numbers, so
# other numbers than the range 32 to 47 can refer to
# transparent colours.
[...]
4 If Command.LineType != INVERTNEXT Then
4 InvertNext = FALSE
4 End If
# Shouldn't the check be:
J If Command.LineType != BFC Or Else no Option in Command is INVERTNEXT Then
J InvertNext = FALSE
J End If
[...]
6 --------------------------------------------------------------------------------
6 Guidelines for Part and Primitives authors
6 --------------------------------------------------------------------------------
6 - How to write double-sided and decoration sections
6 - Default values
6 0 BFC CERTIFY
6 =
6 0 BFC CLIP CCW
# ???
------------------------------------------------------------------------------
Play well,
Jacob
------------------------------------------------------------
-- E-mail: sparre@cats.nbi.dk --
-- Web...: <URL: http://hugin.ldraw.org/LEGO/Dyr/ > --
------------------------------------------------------------
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev, Jacob Sparre Andersen wrote:
> [ Still discussing
> http://www.geocities.com/SouthBeach/Lagoon/8641/bfcspecv4.txt ]
>
> Steve:
>
> You can also put them on ldraw.org now that you have an
> account here.
It's an admin role vs. personal role thing. I took it upon myself to write up a
spec, I didn't want to imply that it was endorsed by the group at large.
> Here comes a commented/edited version. Lines starting with
> "#" are my comments and lines starting with "J" are my
> changes/additions.
>
> ------------------------------------------------------------------------------
> [...]
> 7 revision: 7, 1999.12.08
> [...]
> 4 Inversion is the one BFC option which accumulates globally. If the current
> 4 file is being rendered inverted, then any subfiles of the current file are
> 4 also rendered as inverted.
>
> # In what sense is inversion more "global" than clipping?
Hmmm. You're right. Inversion is no more global than accumulated clipping.
They are identically global. This paragraph is now:
9 Inversion accumulates down the reference branch. If the current
4 file is being rendered inverted, then any subfiles of the current file are
4 also rendered as inverted.
> 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
> # ^^^^^^^^^^^^^^^^^^^^^^^^^^
> # You might want to make it more clear that it only refers
> # to the _immediately_ following line.
OK. The paragraph does have some verbiage in that direction, but I will add to
it:
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 subfile reference should
4 have its orientation inverted, i.e. the inside/outside definition should be
4 swapped. Inverted subfiles must be preceeded by a 0 BFC INVERTNEXT statement,
4 and the 0 BFC INVERTNEXT statement may not appear anywhere else in a file.
9 The INVERTNEXT flag applies *only* to the one subfile which immediately
9 follows. Any subfile commands afterward are processed normally.
> There will be a few requirements placed on the design of rendering programs,
> # ^^^^^^^^^^^^
> # What about reformulating this as "implementation advice"
> # (since "Any program may violate...").
OK:
9 Rendering Engine Guidelines
--------------------------------------------------------------------------------
9 This section gives some suggestions for the design of rendering programs,
3 in order to achieve correct renderings. Any program may violate
9 these guidelines, if there is another way to acheive a valid rendering.
> Matrix Inversions. Rendering engines will need to correct for transformation
> 1 matrices which inadvertently invert a subfile. They will also need to
> 1 allow for situations in which the matrix is deliberately given a negative
> 1 determinant, in order to mirror the subfile.
>
> # I suppose that the meaning of this statement is that the
> # (C)CW-ness of the polygons is compensated for the
> # determinant of the accumulated orientation matrix, but it
> # is not very clear.
It's not very clear, because I was trying to avoid telling people specifically
how to code their programs. It might make sense to write a sample program to
illustrate these hard-to-explain points.
Try this:
Matrix Inversions. Rendering engines will need to correct for transformation
1 matrices which inadvertently invert a subfile. They will also need to
1 allow for situations in which the matrix is deliberately given a negative
9 determinant, in order to mirror the subfile.
9
9 The typical method of determining that the file has been manually inverted is
9 to calculate the determinate of the transformation matrix. If the determinate
9 is negative, then the subfile has been inverted. This document does not
9 attempt to address the details of 3D graphics algorithms and issues.
9
9 The typical way to adjust for matrix inversions is to switch the winding of
9 the polygon vertices. That is, if the DAT specifies the winding as CW, and
9 the current subfile has been inverted, the rendering program would proceed as
9 if the winding is CCW.
> 7 the rendering engine to apply BFC-processing on these parts (assuming the
> J parts are certified), even if the calling files aren't certified.
OK.
> 7 If 32 <= Color And Color <= 47 Then // This restriction may or may not be
> 7 AccumClip = FALSE // required, depending on the style of
> 7 End If // rendering for transparent surfaces.
>
> # Shouldn't the check on colour numbers rather be formulated
> # "If Transparent (Colour) Then"? We should remember that
> # people can redefine the meaning of the colour numbers, so
> # other numbers than the range 32 to 47 can refer to
> # transparent colours.
Good idea. But that entire test belongs in the BFC() function.
I changed every occurrence of Color to Colour. Any other American-isms which
need to be changed to Australia-isms?
> 4 If Command.LineType != INVERTNEXT Then
> 4 InvertNext = FALSE
> 4 End If
>
> # Shouldn't the check be:
>
> J If Command.LineType != BFC Or Else no Option in Command is INVERTNEXT Then
> J InvertNext = FALSE
> J End If
I changed it to:
9 If Command.LineType != BFC Then
4 InvertNext = FALSE
9 ElseIf No Option in Command is INVERTNEXT Then
9 InvertNext = FALSE
4 End If
... to avoid any problems with evaluating tests in compound boolean expressions.
> 6 --------------------------------------------------------------------------------
> 6 Guidelines for Part and Primitives authors
> 6 --------------------------------------------------------------------------------
> 6 - How to write double-sided and decoration sections
> 6 - Default values
> 6 0 BFC CERTIFY
> 6 =
> 6 0 BFC CLIP CCW
>
> # ???
Ties back to the issue at the top of the file:
6 - The authors guidelines section is completely undeveloped.
Steve
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
[ Still discussing
http://www.geocities.com/SouthBeach/Lagoon/8641/bfcspecv4.txt ]
Steve:
> > You can also put them on ldraw.org now that you have an
> > account here.
>
> It's an admin role vs. personal role thing. I took it
> upon myself to write up a spec, I didn't want to imply
> that it was endorsed by the group at large.
That makes sense.
> > Here comes a commented/edited version. Lines starting with
> > "#" are my comments and lines starting with "J" are my
> > changes/additions.
I'll reuse the notation.
--------------------------------------------------------------------------------
> 9 Inversion accumulates down the reference branch. If the current
> 4 file is being rendered inverted, then any subfiles of the current file are
> 4 also rendered as inverted.
# Fine.
> 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 subfile reference should
> 4 have its orientation inverted, i.e. the inside/outside definition should be
> 4 swapped. Inverted subfiles must be preceeded by a 0 BFC INVERTNEXT statement,
> 4 and the 0 BFC INVERTNEXT statement may not appear anywhere else in a file.
> 9 The INVERTNEXT flag applies *only* to the one subfile which immediately
> 9 follows. Any subfile commands afterward are processed normally.
# I'll try a complete reformulation:
4 INVERTNEXT
J This option is used to swap the definitions of "inside" and "outside" (i.e.
J from which side the polygons can be seen) of a single subfile.
J This option can only be used on a line immediately preceeding a line with a
J subfile command (linetype 1), and it only influences that single subfile
J reference.
J Specifically, the sign of the determinant of the orientation matrix should
J not be considered, when a rendering program determines if a subfile is
J turned inside-out.
# Is it clear this way?
> 9 Rendering Engine Guidelines
> --------------------------------------------------------------------------------
> 9 This section gives some suggestions for the design of rendering programs,
> 3 in order to achieve correct renderings. Any program may violate
> 9 these guidelines, if there is another way to acheive a valid rendering.
# Fine.
> > Matrix Inversions. Rendering engines will need to correct for transformation
> > 1 matrices which inadvertently invert a subfile. They will also need to
> > 1 allow for situations in which the matrix is deliberately given a negative
> > 1 determinant, in order to mirror the subfile.
> >
> > # I suppose that the meaning of this statement is that the
> > # (C)CW-ness of the polygons is compensated for the
> > # determinant of the accumulated orientation matrix, but it
> > # is not very clear.
>
> It's not very clear, because I was trying to avoid telling people specifically
> how to code their programs. It might make sense to write a sample program to
> illustrate these hard-to-explain points.
# I tried to add a bit of clarification with the INVERTNEXT
# text. Maybe that is enough.
> Try this:
> Matrix Inversions. Rendering engines will need to correct for transformation
> 1 matrices which inadvertently invert a subfile. They will also need to
> 1 allow for situations in which the matrix is deliberately given a negative
> 9 determinant, in order to mirror the subfile.
> 9
> 9 The typical method of determining that the file has been manually inverted is
> 9 to calculate the determinate of the transformation matrix. If the determinate
> 9 is negative, then the subfile has been inverted. This document does not
> 9 attempt to address the details of 3D graphics algorithms and issues.
# %s/determinate/determinant/g ?
> 9
> 9 The typical way to adjust for matrix inversions is to switch the winding of
> 9 the polygon vertices. That is, if the DAT specifies the winding as CW, and
> 9 the current subfile has been inverted, the rendering program would proceed as
> 9 if the winding is CCW.
# I am not sure this actually clarifies things more. See if
# the text with the INVERTNEXT is enough.
> > 7 If 32 <= Color And Color <= 47 Then // This restriction may or may not be
> > 7 AccumClip = FALSE // required, depending on the style of
> > 7 End If // rendering for transparent surfaces.
> >
> > # Shouldn't the check on colour numbers rather be formulated
> > # "If Transparent (Colour) Then"? We should remember that
> > # people can redefine the meaning of the colour numbers, so
> > # other numbers than the range 32 to 47 can refer to
> > # transparent colours.
>
> Good idea. But that entire test belongs in the BFC() function.
# Yes.
> I changed every occurrence of Color to Colour. Any other American-isms which
> need to be changed to Australia-isms?
# Didn't notice any.
> I changed it to:
>
> 9 If Command.LineType != BFC Then
> 4 InvertNext = FALSE
> 9 ElseIf No Option in Command is INVERTNEXT Then
> 9 InvertNext = FALSE
> 4 End If
>
> ... to avoid any problems with evaluating tests in compound boolean expressions.
# Probably better, even though the "or else" is very clear
# (for Ada programmers ;-).
--------------------------------------------------------------------------------
Play well,
Jacob
------------------------------------------------------------
-- E-mail: sparre@cats.nbi.dk --
-- Web...: <URL: http://hugin.ldraw.org/LEGO/Biler/ > --
------------------------------------------------------------
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev, Jacob Sparre Andersen wrote:
> [ Still discussing
> http://www.geocities.com/SouthBeach/Lagoon/8641/bfcspecv4.txt ]
>
> Steve:
>
> > 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 subfile reference should
> > 4 have its orientation inverted, i.e. the inside/outside definition should be
> > 4 swapped. Inverted subfiles must be preceeded by a 0 BFC INVERTNEXT statement,
> > 4 and the 0 BFC INVERTNEXT statement may not appear anywhere else in a file.
> > 9 The INVERTNEXT flag applies *only* to the one subfile which immediately
> > 9 follows. Any subfile commands afterward are processed normally.
>
> # I'll try a complete reformulation:
>
> 4 INVERTNEXT
> J This option is used to swap the definitions of "inside" and "outside" (i.e.
> J from which side the polygons can be seen) of a single subfile.
> J This option can only be used on a line immediately preceeding a line with a
> J subfile command (linetype 1), and it only influences that single subfile
> J reference.
> J Specifically, the sign of the determinant of the orientation matrix should
> J not be considered, when a rendering program determines if a subfile is
> J turned inside-out.
>
> # Is it clear this way?
I like your explanation better, but I think we're both missing the point: this
paragraph is supposed to be about INVERTNEXT, not inversion. Fewer details are
appropriate at this point. More details should go in (1) the explanation of
inversion in the "Language Extension Functionality" and (2) pseudo-code for the
BFC() function.
The documentation for INVERTNEXT should be focused the specifics of INVERTNEXT,
not on the definition/affect of inversion:
S INVERTNEXT
S This option inverts a subfile. It may only be used immediately before a
S subfile command line, and nowhere else.
S
S Example:
S 0 BFC INVERTNEXT
S 1 16 0 0 0 1 0 0 0 1 0 0 0 1 somefile.dat
S 1 16 0 0 0 1 0 0 0 1 0 0 0 1 another.dat
S
S In this example, somefile.dat would be rendered as inverted. Another.dat
S would not be inverted.
S
S For further information, see "Inversion" in the Language Extension
S Functionality section.
For now, I'm not going to change the INVERTNEXT paragraph. It does need to be
clarified, and I'll add that to the issues list. But before making changes, I'd
like to hear back from you (and anyone else) on my comments and suggestions.
> --------------------------------------------------------------------------------
[Matrix inversions]
Question: should there be a definition-entry for matrix-inversion?
Second question: why did we decide that matrix-inversions were evil? I remember
being thick-headed about seeing the problem, but now I don't remember what the
problem is.
> > Try this:
> > Matrix Inversions. Rendering engines will need to correct for transformation
> > 1 matrices which inadvertently invert a subfile. They will also need to
> > 1 allow for situations in which the matrix is deliberately given a negative
> > 9 determinant, in order to mirror the subfile.
> > 9
> > 9 The typical method of determining that the file has been manually inverted is
> > 9 to calculate the determinate of the transformation matrix. If the determinate
> > 9 is negative, then the subfile has been inverted. This document does not
> > 9 attempt to address the details of 3D graphics algorithms and issues.
>
> # %s/determinate/determinant/g ?
Er, yes.
BTW, should I change "transformation matrix" to "orientation matrix" when
discussing the matrix being used to map the current (sub)file onto the screen?
(This corresponds to AccumTransformMatrix in the pseudo-code) (which can also be
renamed)
> > 9 The typical way to adjust for matrix inversions is to switch the winding of
> > 9 the polygon vertices. That is, if the DAT specifies the winding as CW, and
> > 9 the current subfile has been inverted, the rendering program would proceed as
> > 9 if the winding is CCW.
>
> # I am not sure this actually clarifies things more. See if
> # the text with the INVERTNEXT is enough.
OK, let me check. (scroll, scroll, scroll). Nope. You suggested the following
text:
> J Specifically, the sign of the determinant of the orientation matrix should
> J not be considered, when a rendering program determines if a subfile is
> J turned inside-out.
But that is not sufficient. AFAIK, an inverted orientation matrix will reverse
the results of BFC-testing. So the rendering program must do more than
disregard the determinants. It must adjust for the effects of the matrix on the
polygons and their normal vectors.
> > I changed it to:
> >
> > 9 If Command.LineType != BFC Then
> > 4 InvertNext = FALSE
> > 9 ElseIf No Option in Command is INVERTNEXT Then
> > 9 InvertNext = FALSE
> > 4 End If
> >
> > ... to avoid any problems with evaluating tests in compound boolean expressions.
>
> # Probably better, even though the "or else" is very clear
> # (for Ada programmers ;-).
It's clear, especially one-liners like this example, but I like having verbiage
wrap around both the beginning and end of nested statement blocks, to keep
everything straight.
Steve
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
[ Still discussing
http://www.geocities.com/SouthBeach/Lagoon/8641/bfcspecv4.txt ]
Steve:
[...]
> I like your explanation better, but I think we're both missing the point: this
> paragraph is supposed to be about INVERTNEXT, not inversion. Fewer details are
> appropriate at this point. More details should go in (1) the explanation of
> inversion in the "Language Extension Functionality" and (2) pseudo-code for the
> BFC() function.
Correct.
> The documentation for INVERTNEXT should be focused the specifics of INVERTNEXT,
> not on the definition/affect of inversion:
>
> S INVERTNEXT
> S This option inverts a subfile. It may only be used immediately before a
> S subfile command line, and nowhere else.
J subfile command line, and it only influences the immediately
J following subfile command.
I don't think the "and nowhere else" is that important. You
already have written "only".
> S
> S Example:
> S 0 BFC INVERTNEXT
> S 1 16 0 0 0 1 0 0 0 1 0 0 0 1 somefile.dat
> S 1 16 0 0 0 1 0 0 0 1 0 0 0 1 another.dat
> S
> S In this example, somefile.dat would be rendered as inverted. Another.dat
> S would not be inverted.
> S
> S For further information, see "Inversion" in the Language Extension
> S Functionality section.
Good.
> For now, I'm not going to change the INVERTNEXT paragraph. It does need to be
> clarified, and I'll add that to the issues list. But before making changes, I'd
> like to hear back from you (and anyone else) on my comments and suggestions.
Try the formulation above, and insert something like my
previous INVERTNEXT text in the "Inversion" section.
> Question: should there be a definition-entry for matrix-inversion?
Shouldn't be necessary. Or is it?
> Second question: why did we decide that matrix-inversions were evil? I remember
> being thick-headed about seeing the problem, but now I don't remember what the
> problem is.
One problem is that it can be difficult to see if a matrix
has negative determinant.
Another one is that some of us are lazy enough to mirror our
subfiles in stead of writing two copies.
> > > Try this:
> > > Matrix Inversions. Rendering engines will need to correct for transformation
> > > 1 matrices which inadvertently invert a subfile. They will also need to
> > > 1 allow for situations in which the matrix is deliberately given a negative
> > > 9 determinant, in order to mirror the subfile.
> > > 9
> > > 9 The typical method of determining that the file has been manually inverted is
> > > 9 to calculate the determinate of the transformation matrix. If the determinate
> > > 9 is negative, then the subfile has been inverted. This document does not
> > > 9 attempt to address the details of 3D graphics algorithms and issues.
> >
> > # %s/determinate/determinant/g ?
>
> Er, yes.
>
> BTW, should I change "transformation matrix" to "orientation matrix" when
> discussing the matrix being used to map the current (sub)file onto the screen?
Don't know.
> > > 9 The typical way to adjust for matrix inversions is to switch the winding of
> > > 9 the polygon vertices. That is, if the DAT specifies the winding as CW, and
> > > 9 the current subfile has been inverted, the rendering program would proceed as
> > > 9 if the winding is CCW.
> >
> > # I am not sure this actually clarifies things more. See if
> > # the text with the INVERTNEXT is enough.
[ My head is not clear enough for matrix operations at the
moment - I'll be back later with comments to the rest. ]
Play well,
Jacob
------------------------------------------------------------
-- E-mail: sparre@cats.nbi.dk --
-- Web...: <URL: http://hugin.ldraw.org/LEGO/Biler/ > --
------------------------------------------------------------
| | | | | | | | | | | | | | | | | | | | | | | |
> [ Still discussing
> http://www.geocities.com/SouthBeach/Lagoon/8641/bfcspecv4.txt ]
In lugnet.cad.dev, Jacob Sparre Andersen wrote:
[about INVERTNEXT]
> Try the formulation above, and insert something like my
> previous INVERTNEXT text in the "Inversion" section.
OK.
Steve
| | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
Jacob Sparre Andersen wrote...
> [ Still discussing
> http://www.geocities.com/SouthBeach/Lagoon/8641/bfcspecv4.txt ]
>
> Steve:
(snip)
> > Second question: why did we decide that matrix-inversions were evil? I remember
> > being thick-headed about seeing the problem, but now I don't remember what the
> > problem is.
>
> One problem is that it can be difficult to see if a matrix
> has negative determinant.
Why? Are you thinking about
1 16 -4 0 0 0 0 0 0 0 4 1-4disc.dat
The determinant is zero, which BTW causes POVRay to halt
("singular matrix"). L3P has to fix these matrices or POVRay
would not render many parts at all!
As part of certifying a DAT file I believe this kind of subfile
reference should be fixed as well, like into
1 16 -4 0 0 0 1 0 0 0 4 1-4disc.dat
"L3P -check -w3" will help spot the problems.
> Another one is that some of us are lazy enough to mirror our
> subfiles in stead of writing two copies.
Mirroring is not a problem. It causes a "negative determinant matrix"
which can be detected and adjusted for (by toggling winding).
So matrix-inversions are not evil.
/Lars
| | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev, Lars C. Hassing wrote:
> Mirroring is not a problem. It causes a "negative determinant matrix"
> which can be detected and adjusted for (by toggling winding).
> So matrix-inversions are not evil.
Matrix-inversions are not evil. But for some reason, using them to actually
invert subfiles is evil (as opposed to using INVERTNEXT to invert subfiles).
If I reallly needed an answer to this, I'd go read past messages. But I *do*
remember:
a) I originally thought INVERTNEXT was redundant, because inversions could be
handled by inverting matrices.
b) I was later convinced that INVERTNEXT was needed.
I don't remember *why* INVERTNEXT is needed. But I am sure it is needed.
Steve
| | | | | | | | | | | | | | | | | | | | | | | |
Steve Bliss wrote ...
> I don't remember *why* INVERTNEXT is needed. But I am sure it is needed.
Is this a joke? You argue very well in "Inversion" in "Language Extension
Functionality" about the 3D tube ;-)
/Lars
Sorry if I missed a pun.
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev, Lars C. Hassing wrote:
> Steve Bliss wrote ...
> > I don't remember *why* INVERTNEXT is needed. But I am sure it is needed.
>
> Is this a joke? You argue very well in "Inversion" in "Language Extension
> Functionality" about the 3D tube ;-)
Nope, not a joke. I seriously didn't remember the reason(s) why other
approaches wouldn't work as well as INVERTNEXT.
I poked around old messages a little bit, I think I remember better now.
Let me (attempt to) explain:
When this whole BFC discussion started, I thought the best way to invert
subfiles was to negate the orientation matrix.
Later in the discussion, it became apparent to me that using the orientation
matrix was not a workable way to deal with inversion. Other people realized
this from the start, I think.
As I remember, the only other suggested approach to inverted objects was to have
two sets of primitives; one set with normal orientation, the other set inverted.
This is actually a workable solution, but limits the power of the LDraw
language, and requires somebody to *write* all the inverterd-primitive files.
So INVERTNEXT is our best solution to the problem.
Steve
| | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
> > Mirroring is not a problem. It causes a "negative determinant matrix"
> > which can be detected and adjusted for (by toggling winding).
> > So matrix-inversions are not evil.
>
> Matrix-inversions are not evil. But for some reason, using them to actually
> invert subfiles is evil (as opposed to using INVERTNEXT to invert subfiles).
>
> If I reallly needed an answer to this, I'd go read past messages. But I *do*
> remember:
>
> a) I originally thought INVERTNEXT was redundant, because inversions could be
> handled by inverting matrices.
> b) I was later convinced that INVERTNEXT was needed.
>
> I don't remember *why* INVERTNEXT is needed. But I am sure it is needed.
I do, it's because of those cases like an hollow cylindir DAT file is
referenced by another DAT file. Since the cylinder is supposed to be
define outwards, but you can use it to make the inside/outside of a stud
(for example) and the if the renderer corrected the inverted matrix, it
will clip the inside cylinder since it would seam to be facing outwards.
Actually this is needed for backwards compatibility, and expecially
because of our laziness in doing the correct editing, and NOT mirroring
things.
Another fact is that INVERTNEXT is NOT to correct for the Matrix with
negative determinant, but for the lego cad builder to inform the renderer,
I want to use this particular DAT file inverted (NOT MIRRORED) i.e. Every
face which was facing outwards will now considered to be facing inwards,
and viceversa, and upwards has downwards and viceversa.
Actually what we are saying is:
"now all the unclipable polygons will be clippable, and viceversa"
But all this has been debated too many times, and a long time ago already,
so make up your minds.
Either we support the INVERTNEXT to support our laziness, or we don't, and
we will have to have 2 versions of the DAT files we eventually would like
to use inverted (inside-out).
See ya.
Rui Martins
| | | | | | | | | | | | | | | | | | | |
| |
|
Steve Bliss wrote...
> 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.
OK. The pseudo-code reflects this now.
> > 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:
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. Sorry.
> > *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.
Huh? please explain why.
> > 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?
I just meant to accommodate both "your way with CERTIFY" and
"my way without it". And you already have!
> > > 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.
Sorry, I didn't make myself clear. I am NOT going to begin clipping
non-BFC parts. It is of course not possible. But I WOULD like to clip
BFC parts, even if the superfiles are not certified, i.e. let old
model files (=non-BFC files) benefit from BFC-parts.
"All DAT files are equal, but some are more equal than others" :-)
Parts are objects with obvious orientation. You are not in doubt what is
inside/outside of a part!
However, consider the 4-4cyli.dat. Even if its orientation was defined
and it was certified, you could not use that info for clipping
if it was not referenced from a certified part, i.e. a part that have
gone through considerations whether to use INVERTNEXT or not.
Because the orientation of parts is natural and intuitive, certified
parts would be the right place for enabling clipping.
And it would be safe and legal to do so, because rendering programs
keep track of transformation-inversions, i.e. you can safely use
mirrorred submodels.
See also last 5 paragraphs of http://www.lugnet.com/cad/dev/?n=3084
and http://www.lugnet.com/cad/dev/?n=3102
> > > 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.
You added AccumTransformMatrix as a parameter to RenderFile but forgot the
AccumTransformMatrix * Command.TransformMatrix in the two calls to RenderFile.
Actually the color should also be a parameter to RenderFile. A transparent
file cannot be clipped. If you add
Color integer // current color
as a parameter, then you can add this before "OpenFile(ModelFile)":
If 32 <= Color And Color <= 47 Then AccumClip = FALSE
and this after "Get Next Command":
If Command.Color = 16 Then
Command.Color = Color
Else
If Command.Color = 24 Then
Command.Color = EdgeColor(CurColor)
and add Command.Color in the two calls to RenderFile.
Feel free to rename/recode, I hope you get the idea.
> > 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.
It's not important, it just stroke me that CLIP INVERTNEXT are commands/orders
(imperative), CERTIFIED is a state (adjective).
> > > 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.
I sincerely hope part authors will support the BFC. They are the ones to do
the hard work. I hope Jean-Pierre PARIS's program will be a great help.
I wouldn't worry too much about programmers though, it's pretty easy and
you have alreay provided pseudo-code.
/Lars
| | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev, Lars C. Hassing wrote:
> Steve Bliss wrote...
> > Double-sided sections won't be very rare. They'll be needed for all decorated
> > parts.
>
> Huh? please explain why.
Sometimes, transparent parts have decorative printing. And the LDraw library
should be written so that modelers can use any part in any color, even if LEGO
hasn't released that part/color combination yet.
Decorations on transparent parts shows through when looking at the part from
behind. If the decoration polygons were put through the BFC-check, they would
be clipped in this situation, because the decoration is facing away from the
viewer.
> Sorry, I didn't make myself clear. I am NOT going to begin clipping
> non-BFC parts. It is of course not possible. But I WOULD like to clip
> BFC parts, even if the superfiles are not certified, i.e. let old
> model files (=non-BFC files) benefit from BFC-parts.
> See also last 5 paragraphs of http://www.lugnet.com/cad/dev/?n=3084
> and http://www.lugnet.com/cad/dev/?n=3102
Ahhh. "Model-files don't invert part-files". That's the key. I'll add that
paragraph back to the V4 document (which is now on V7, I think). But I'll
rewrite the paragraph to make it clear that the assumption is that model files
would not invert part files, not that "part files are right-side out" (I know,
they're really the same thing, but the wording is crucial IMO). And the part
files *must* be certified to be clipped.
OK, I've inserted the following text into the V4 document:
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
7 they were inverted. Assuming that all part files used in a rendering allows
7 the rendering engine to apply BFC-processing on these parts (assuming the
7 parts are 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.
> "All DAT files are equal, but some are more equal than others" :-)
:-)
> > > > 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.
>
> You added AccumTransformMatrix as a parameter to RenderFile but forgot the
> AccumTransformMatrix * Command.TransformMatrix in the two calls to RenderFile.
Hmm, good point.
> Actually the color should also be a parameter to RenderFile. A transparent
> file cannot be clipped. If you add
> Color integer // current color
>
> as a parameter, then you can add this before "OpenFile(ModelFile)":
> If 32 <= Color And Color <= 47 Then AccumClip = FALSE
>
> and this after "Get Next Command":
> If Command.Color = 16 Then
> Command.Color = Color
> Else
> If Command.Color = 24 Then
> Command.Color = EdgeColor(CurColor)
>
> and add Command.Color in the two calls to RenderFile.
> Feel free to rename/recode, I hope you get the idea.
Got it. The last bit is straying away from strict BFC-relevance (the colors 16
and 24), but I guess I can throw it in...
> I wouldn't worry too much about programmers though, it's pretty easy and
> you have alreay provided pseudo-code.
Attempting to be as clear as possible, I added this paragraph before the
pseudo-code:
7 The function BFC() returns a boolean value, indicating whether a polygon
7 should be rendered or culled. As the nature of this routine does not
7 impact the BFC standard, the logic for BFC() is not included in the following
7 pseudo-code. There is information about BFC processing available from many
7 locations, including <http://www.lugnet.com/cad/dev/>.
Steve
| | | | | | | | | | | | | | | | | |
| |
|
Steve Bliss wrote in message ...
> In lugnet.cad.dev, Lars C. Hassing wrote:
>
> > Steve Bliss wrote...
> > > Double-sided sections won't be very rare. They'll be needed for all decorated
> > > parts.
> >
> > Huh? please explain why.
>
> Sometimes, transparent parts have decorative printing. And the LDraw library
> should be written so that modelers can use any part in any color, even if LEGO
> hasn't released that part/color combination yet.
>
> Decorations on transparent parts shows through when looking at the part from
> behind. If the decoration polygons were put through the BFC-check, they would
> be clipped in this situation, because the decoration is facing away from the
> viewer.
Remember BFC must be disabled for transparent parts. That's what
If 32 <= Color And Color <= 47 Then AccumClip = FALSE
takes care of.
Frankly I can't think of any situations where double-sided sections are
*really* necessary, since all parts have a volume, because they are molded
in plastic.
However, two places where double-sided sections could be useful:
1) John Van mentioned a "stair-step-like part, where a single quad could
be used as the top of one step and the bottom of the next step up".
IMO this is bad modeling, as the part would look strange in transparent
and it may not necessarily speed up rendering having a large quad
rather than two small quads.
2) Stickers and flags. As a shortcut they *could* be modeled as thin objects.
> 7 If 32 <= Color And Color <= 47 Then // This restriction may or may not be
> 7 AccumClip = FALSE // required, depending on the style of
> 7 End If // rendering for transparent surfaces.
What do you mean with the comment?
That dither-transparency can use BFC? Well, in that case we do need
double-sided sections for decorations!
> > Sorry, I didn't make myself clear. I am NOT going to begin clipping
> > non-BFC parts. It is of course not possible. But I WOULD like to clip
> > BFC parts, even if the superfiles are not certified, i.e. let old
> > model files (=non-BFC files) benefit from BFC-parts.
>
> > See also last 5 paragraphs of http://www.lugnet.com/cad/dev/?n=3084
> > and http://www.lugnet.com/cad/dev/?n=3102
>
> Ahhh. "Model-files don't invert part-files". That's the key. I'll add that
> paragraph back to the V4 document (which is now on V7, I think). But I'll
> rewrite the paragraph to make it clear that the assumption is that model files
> would not invert part files, not that "part files are right-side out" (I know,
> they're really the same thing, but the wording is crucial IMO). And the part
> files *must* be certified to be clipped.
Yeah, that was the expression I was looking for ;-)
In Danish we have a noun (vrang) meaning "wrong side" or "reverse side".
I can't seem to find a similar English noun.
It is important to state that "inversion" in this discussion means
"turning inside out" or "turning the wrong side out" and not mirroring.
> 7 they were inverted. Assuming that all part files used in a rendering allows
Don't you need a comma?
8 they were inverted. Assuming that, all part files used in a rendering allows
> > > > > 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.
> >
> > You added AccumTransformMatrix as a parameter to RenderFile but forgot the
> > AccumTransformMatrix * Command.TransformMatrix in the two calls to RenderFile.
>
> Hmm, good point.
Yes, I really think you should consider updating the document :-)
> > Actually the color should also be a parameter to RenderFile. A transparent
> > file cannot be clipped. If you add
> > Color integer // current color
> >
> > as a parameter, then you can add this before "OpenFile(ModelFile)":
> > If 32 <= Color And Color <= 47 Then AccumClip = FALSE
> >
> > and this after "Get Next Command":
> > If Command.Color = 16 Then
> > Command.Color = Color
> > Else
> > If Command.Color = 24 Then
> > Command.Color = EdgeColor(CurColor)
> >
> > and add Command.Color in the two calls to RenderFile.
> > Feel free to rename/recode, I hope you get the idea.
>
> Got it. The last bit is straying away from strict BFC-relevance (the colors 16
> and 24), but I guess I can throw it in...
You're right that the last bit is not BFC relevant, you may remove it again.
It also contains a typo (CurColor) :-)
> > If 32 <= Color And Color <= 47 Then AccumClip = FALSE
Actually LDLite and MLCad uses 63 in stead of 47.
/Lars
| | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev, Lars C. Hassing wrote:
> Steve Bliss wrote in message ...
> > Decorations on transparent parts shows through when looking at the part from
> > behind. If the decoration polygons were put through the BFC-check, they would
> > be clipped in this situation, because the decoration is facing away from the
> > viewer.
>
> Remember BFC must be disabled for transparent parts. That's what
> If 32 <= Color And Color <= 47 Then AccumClip = FALSE
> takes care of.
Hmm. that makes me wonder if the logic of turning of BFC clipping when a part's
color is transparent will really work. Because a part may have the main color
as 16, and some sections are hard-coded to a transparent color. In this case,
the suggested logic would fail to cull correctly.
So it's not the transparent *part-file* which can't be BFC'ed, but the
transparent polygons.
Argh. I'll update the pseudo-code.
> Frankly I can't think of any situations where double-sided sections are
> *really* necessary, since all parts have a volume, because they are molded
> in plastic.
>
> However, two places where double-sided sections could be useful:
> 1) John Van mentioned a "stair-step-like part, where a single quad could
> be used as the top of one step and the bottom of the next step up".
> IMO this is bad modeling, as the part would look strange in transparent
> and it may not necessarily speed up rendering having a large quad
> rather than two small quads.
I agree with you on this. It's an unnecessary shortcut for the author.
> 2) Stickers and flags. As a shortcut they *could* be modeled as thin objects.
> > 7 If 32 <= Color And Color <= 47 Then // This restriction may or may not be
> > 7 AccumClip = FALSE // required, depending on the style of
> > 7 End If // rendering for transparent surfaces.
>
> What do you mean with the comment?
> That dither-transparency can use BFC?
That is correct.
> Well, in that case we do need
> double-sided sections for decorations!
That's what I was thinking. :)
But, we need this anyway. Without worrying about the details, think about the
basic logic: in some cases, the backside of decorations can appear in
renderings. And, as I pointed out above, the logic of disabling BFC clipping
for transparent parts is flawed.
> Yeah, that was the expression I was looking for ;-)
>
> In Danish we have a noun (vrang) meaning "wrong side" or "reverse side".
> I can't seem to find a similar English noun.
Do you mean inside-out or back?
> It is important to state that "inversion" in this discussion means
> "turning inside out" or "turning the wrong side out" and not mirroring.
Good point.
> > 7 they were inverted. Assuming that all part files used in a rendering allows
> Don't you need a comma?
> 8 they were inverted. Assuming that, all part files used in a rendering allows
No, I need a brain-check. I think this wording is slightly more clear:
8 they were inverted. Assuming part files are never inverted allows
8 the rendering engine to apply BFC-processing on all certified part-files,
8 even if the model file(s) are not BFC-certified.
> > > > > > 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.
> > >
> > > You added AccumTransformMatrix as a parameter to RenderFile but forgot the
> > > AccumTransformMatrix * Command.TransformMatrix in the two calls to RenderFile.
> >
> > Hmm, good point.
>
> Yes, I really think you should consider updating the document :-)
:p. It's there now, along with the following in the Declare section:
8 Command DATCommandLine // Structure containing parameters from a single
8 // DAT command-line.
> > > Actually the color should also be a parameter to RenderFile. A transparent
> > > file cannot be clipped. If you add
> > > Color integer // current color
> > >
> > > as a parameter, then you can add this before "OpenFile(ModelFile)":
> > > If 32 <= Color And Color <= 47 Then AccumClip = FALSE
I'm going to have to drop that bit again. That test actually belongs in the
(undocumented) BFC() function.
Anybody want to write pseudo-code for BFC(), including both the tests that are
specific to the LDraw BFC Standard, and the general approach to BFC'ing?
> > > and this after "Get Next Command":
> > > If Command.Color = 16 Then
> > > Command.Color = Color
> > > Else
> > > If Command.Color = 24 Then
> > > Command.Color = EdgeColor(CurColor)
> > >
> > > and add Command.Color in the two calls to RenderFile.
> > > Feel free to rename/recode, I hope you get the idea.
> >
> > Got it. The last bit is straying away from strict BFC-relevance (the colors 16
> > and 24), but I guess I can throw it in...
>
> You're right that the last bit is not BFC relevant, you may remove it again.
Gee, thanks. ;) It's too late, it's in now, so it's going to stay.
Steve
| | | | | | | | | | | | | | | | | |
| |
|
Steve Bliss wrote...
> In lugnet.cad.dev, Lars C. Hassing wrote:
>
> > Steve Bliss wrote in message ...
> > > Decorations on transparent parts shows through when looking at the part from
> > > behind. If the decoration polygons were put through the BFC-check, they would
> > > be clipped in this situation, because the decoration is facing away from the
> > > viewer.
> >
> > Remember BFC must be disabled for transparent parts. That's what
> > If 32 <= Color And Color <= 47 Then AccumClip = FALSE
> > takes care of.
>
> Hmm. that makes me wonder if the logic of turning of BFC clipping when a part's
> color is transparent will really work. Because a part may have the main color
> as 16, and some sections are hard-coded to a transparent color. In this case,
> the suggested logic would fail to cull correctly.
If IsTransparent(Color) Then AccumClip = FALSE
takes care of solid non-16 colors (decorations) in parts used transparently.
And a similar check added to BFC() can take care of transparent non-16
colors in parts used as solids.
So the logic is OK again.
> > > 7 If 32 <= Color And Color <= 47 Then // This restriction may or may not be
> > > 7 AccumClip = FALSE // required, depending on the style of
> > > 7 End If // rendering for transparent surfaces.
> >
> > What do you mean with the comment?
> > That dither-transparency can use BFC?
>
> That is correct.
>
> > Well, in that case we do need
> > double-sided sections for decorations!
>
> That's what I was thinking. :)
On second thoughts I don't think we need double-sided sections for decorations.
If a rendering program wishes to use BFC together with dither-transparency, it
can easily investigate whether there are non-16 colors in a transparent part.
We should not put an unnecessary rule on the part author.
> > In Danish we have a noun (vrang) meaning "wrong side" or "reverse side".
> > I can't seem to find a similar English noun.
>
> Do you mean inside-out or back?
I mean the inner surface. Like the "internal surface" of a sweater or a stocking.
If you don't have a similar noun/substantive/notion in English I can understand
why the subject is difficult to discuss, because we think/conceive differently
(as our spoken languages reflect) about the "inside surface".
/Lars
| | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev, Lars C. Hassing wrote:
> If IsTransparent(Color) Then AccumClip = FALSE
> takes care of solid non-16 colors (decorations) in parts used transparently.
> And a similar check added to BFC() can take care of transparent non-16
> colors in parts used as solids.
> So the logic is OK again.
Yes, it would render correctly, but it would also disable clipping more often
than is required, in the case of mixed solid and transparent sections. Think of
a submodel where the author used color 16, and the person using the submodel
renders it as transparent. If clipping is turned off at the start of the
submodel, then no part in that submodel could be BFC-ed, even if they were
solid-colored.
> On second thoughts I don't think we need double-sided sections for decorations.
> If a rendering program wishes to use BFC together with dither-transparency, it
> can easily investigate whether there are non-16 colors in a transparent part.
>
> We should not put an unnecessary rule on the part author.
I agree with not putting unnecessary rules on authors. I don't agree on
renderers being required to find the solid colors in a transparent part.
> I mean the inner surface. Like the "internal surface" of a sweater or a stocking.
> If you don't have a similar noun/substantive/notion in English I can understand
> why the subject is difficult to discuss, because we think/conceive differently
> (as our spoken languages reflect) about the "inside surface".
"inner surface" is as good as it gets. Or "inside" or "interior". But those
two also refer to the contained volume, not the actual surface.
Steve
| | | | | | | | | | | | | | | | | |
| |
|
Steve Bliss wrote...
> In lugnet.cad.dev, Lars C. Hassing wrote:
>
> > If IsTransparent(Color) Then AccumClip = FALSE
> > takes care of solid non-16 colors (decorations) in parts used transparently.
> > And a similar check added to BFC() can take care of transparent non-16
> > colors in parts used as solids.
> > So the logic is OK again.
>
> Yes, it would render correctly, but it would also disable clipping more often
> than is required, in the case of mixed solid and transparent sections. Think of
> a submodel where the author used color 16, and the person using the submodel
> renders it as transparent. If clipping is turned off at the start of the
> submodel, then no part in that submodel could be BFC-ed, even if they were
> solid-colored.
I think this is a possible, but rare case. It can, however, be circumvented by
regarding DAT files from PARTS as special.
> > On second thoughts I don't think we need double-sided sections for decorations.
> > If a rendering program wishes to use BFC together with dither-transparency, it
> > can easily investigate whether there are non-16 colors in a transparent part.
> >
> > We should not put an unnecessary rule on the part author.
>
> I agree with not putting unnecessary rules on authors. I don't agree on
> renderers being required to find the solid colors in a transparent part.
Why not? Any information you can gather by simply analysing a DAT file
should not be required to be stated by the part author.
/Lars
| | | | | | | | | | | | | | | | |
In lugnet.cad.dev, Lars C. Hassing wrote:
> Why not? Any information you can gather by simply analysing a DAT file
> should not be required to be stated by the part author.
In that case, why are we wiggling about with this BFC extension stuff?
Rendering programs can figure out what order vertices should be put in, and they
can figure out which way a polygon is facing. They don't need all this extra
effort from us and parts authors.
Steve
| | | | | | | | | | | | | | | | |
Steve Bliss wrote...
> In lugnet.cad.dev, Lars C. Hassing wrote:
>
> > Why not? Any information you can gather by simply analysing a DAT file
> > should not be required to be stated by the part author.
>
> In that case, why are we wiggling about with this BFC extension stuff?
> Rendering programs can figure out what order vertices should be put in, and they
> can figure out which way a polygon is facing. They don't need all this extra
> effort from us and parts authors.
:-)
Jean-Pierre's analyzer is not a "simple analysis" and may not work 100% correctly
without human intervention.
/Lars
| | | | | | |
