 | | | | | | |
| |
|
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
| | | | | | |
