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