| |
On Mon, 8 Nov 1999 16:38:50 GMT, Rui Martins <Rui.Martins@link.pt> wrote:
> > > > UNKNOWN = winding direction is unknown or variable. This setting will
> > > > disable clipping, until the winding is reset.
> > >
> > > Using someones expression, the UNKNOWN is 'syntatic sugar', because this
> > > will be implemented internally as CLIPPING OFF.
> > > If the user want's to inform that the 'winding' is not known,
> > > then he can make a regular comment, and use CLIPPING OFF
> >
> > This sounds correct, but do we want to eliminate this
> > syntactic sugar?
>
> why not ?
> Could you give a good reason !
Yes. WINDING UNKNOWN allows a DAT author to specify what is happening in the
file more precisely than CLIPPING OFF. Adding WINDING DOUBLE-SIDED would allow
even more author-precision, but there is no practical difference between
DOUBLE-SIDED and UNKNOWN, AFAIK.
There is a slight practical difference between WINDING UNKNOWN and CLIPPNG OFF
-- WINDING is a file-specific setting; the file's author can assume that they
always know the current WINDING setting. CLIPPING is passed down the reference
branch, and the current file should make *as few* assumptions about the CLIPPING
setting as possible.
Steve
|
|
| |
Steve Bliss wrote...
> Yes. WINDING UNKNOWN allows a DAT author to specify what is happening in • the
> file more precisely than CLIPPING OFF. Adding WINDING DOUBLE-SIDED would • allow
> even more author-precision, but there is no practical difference between
> DOUBLE-SIDED and UNKNOWN, AFAIK.
>
> There is a slight practical difference between WINDING UNKNOWN and CLIPPNG • OFF
> -- WINDING is a file-specific setting; the file's author can assume that • they
> always know the current WINDING setting. CLIPPING is passed down the • reference
> branch, and the current file should make *as few* assumptions about the • CLIPPING
> setting as possible.
Good point!
Jacob Sparre Andersen wrote:
> [ Still discussing http://www.geocities.com/partsref/bfcspec.txt ]
> certification = "0" "CERTIFY" ( "BFC" | "NOBFC" ) { certification_flag }
> winding = "0" "WINDING" ( "CW" | "CCW" | "UNKNOWN" )
> clipping = "0" "CLIPPING" ( "ON" | "OFF" )
> invert = "0" "INVERT"
Or you could write:
0 CERTIFY BFC | 0 CERTIFY NOBFC
0 WINDING CW | 0 WINDING CCW | 0 WINDING UNKNOWN
(I don't think "0 WINDING" alone makes much sense)
0 CLIPPING ON | 0 CLIPPING OFF
0 INVERT
(or maybe "0 INVERTNEXT" to stress that it is only the following
line, which must be of type 1, that is turned inside-out)
Still discussing http://www.geocities.com/partsref/bfcspec.txt :
The CERTIFY section:
> operational command-line in the file. No other statements are required • for
> backface culling to be applied to a file.
Then please add:
0 CERTIFY BFC implies 0 CLIPPING ON and 0 WINDING CCW.
The WINDING section:
> 0 WINDING [ CW | CCW | UNKNOWN ]
> default: CCW
As "0 WINDING" alone doesn't make much sense, the "default: CCW" should
be deleted. The default value should not refer to what 0 CERTIFY BFC
implies - you don't have a default for CLIPPING.
> UNKNOWN = winding direction is unknown or variable. This setting will • disable
> clipping, until the winding is reset.
>
> The WINDING setting is a local setting, it applies only to the polygons in
> the file in which the WINDING meta-statement appears.
"...This setting will disable clipping..." - I hope readers do not confuse
this with CLIPPING OFF. Although the next sentence says WINDING is local,
it should be made clear that clipping is not turned off for subfiles.
Can you think of a better wording of the two sentences?
Also there should be some words about using 0 CLIPPING OFF for a
double-sided
section of a file.
Well, we could start working right now by updating the primitives reference
http://www.ldraw.org/memorial/archive/FAQ/Primitives_Reference
by adding newer primitives and stating the orientation.
If we "invent" another meta command, like
0 ORIENTATIONARROW x1 y1 z1 x2 y2 z2
rendering programs could optionally draw an arrow and you could save
a nice bitmap for the primitives reference.
/Lars
PS. Jean-Pierre PARIS, how are you doing?
|
|
| |
On Wed, 10 Nov 1999 00:44:17 GMT, "Lars C. Hassing" <lch@ccieurope.com> wrote:
Still discussing <http://www.geocities.com/partsref/bfcspec.txt>
> Jacob Sparre Andersen wrote:
> > [ Still discussing http://www.geocities.com/partsref/bfcspec.txt ]
> > certification = "0" "CERTIFY" ( "BFC" | "NOBFC" ) { certification_flag }
> > winding = "0" "WINDING" ( "CW" | "CCW" | "UNKNOWN" )
> > clipping = "0" "CLIPPING" ( "ON" | "OFF" )
> > invert = "0" "INVERT"
>
> Or you could write:
> 0 CERTIFY BFC | 0 CERTIFY NOBFC
Yes, but the 0 CERTIFY ( BFC | NOBFC ) format is more common. And it emphasizes
that is one statement with various parameters. And it's less typing.
> 0 WINDING CW | 0 WINDING CCW | 0 WINDING UNKNOWN
> (I don't think "0 WINDING" alone makes much sense)
True. Using the parantheses ( ) to group the parameters indicates that one of
the options *must* be used. The square brackets [ ], that I used originally,
indicated that the parameters were optional. Which was definitely *not* the
intention.
> 0 INVERT
> (or maybe "0 INVERTNEXT" to stress that it is only the following
> line, which must be of type 1, that is turned inside-out)
Hmm. Interesting thought. I like it. Anyone else want to ( yay | nay ) this?
> The CERTIFY section:
> > operational command-line in the file. No other statements are required • for
> > backface culling to be applied to a file.
>
> Then please add:
> 0 CERTIFY BFC implies 0 CLIPPING ON and 0 WINDING CCW.
CERTIFY BFC doesn't imply CLIPPING ON -- the clipping mode/setting comes from
the superfile (for the main model-file, clipping is set by the rendering engine
or an explicit CLIPPING ON statement).
WINDING CCW is the default for files, as stated in the section for WINDING.
CERTIFY doesn't imply CCW winding at all--if a file started with these two
lines:
0 WINDING CW
0 CERTIFY BFC
... the winding should be CW, right?
If the CERTIFY statement 'implied' the winding, then this example would not be
clear (at least to the human reader) if the winding for this file is CW or CCW.
Does CERTIFY override the earlier WINDING or not?
That's why the WINDING setting has a default value, and CERTIFY doesn't affect
the WINDING setting in any way.
BUT, I'll see what I can do with the verbiage, to make thing more clear.
> The WINDING section:
> > 0 WINDING [ CW | CCW | UNKNOWN ]
> > default: CCW
> As "0 WINDING" alone doesn't make much sense, the "default: CCW" should
> be deleted. The default value should not refer to what 0 CERTIFY BFC
> implies - you don't have a default for CLIPPING.
WINDING is a file-specific setting, and it is appropriate to have a default
value for it. The default value applies before the first (if any) WINDING
statement. It is not valid to specify 0 WINDING with no parameter.
CLIPPING doesn't need a default, because it is passed down from the superfile.
It is up to the rendering engine to provide the initial value of CLIPPING.
> > UNKNOWN = winding direction is unknown or variable. This setting will • disable
> > clipping, until the winding is reset.
> >
> > The WINDING setting is a local setting, it applies only to the polygons in
> > the file in which the WINDING meta-statement appears.
>
> "...This setting will disable clipping..." - I hope readers do not confuse
> this with CLIPPING OFF. Although the next sentence says WINDING is local,
> it should be made clear that clipping is not turned off for subfiles.
> Can you think of a better wording of the two sentences?
> Also there should be some words about using 0 CLIPPING OFF for a
> double-sided section of a file.
Ergh. Thank you for pointing this out. I had not thought through all the
implications of the WINDING UNKNOWN (maybe WINDING NONE?) setting.
My intention was that WINDING UNKNOWN *would* disable clipping for subfiles, but
that is obviously *not* the way the document is written, and making things work
that way would be non-elegant. Then again, it seems counter-productive to
require part-authors to use both WINDING UNKNOWN and CLIPPING OFF when they make
use of subfiles in a non-compliant or double-sided section.
Maybe it would be better to drop WINDING UNKNOWN and specify that the default
value for CLIPPING is ON. File authors would use CLIPPING OFF for double-sided
or non-compliant sections of code. Note that the CLIPPING default would really
only effect the main file in a rendering, because superfiles would pass down
their clip-setting to subfiles.
Curent_Clip = Local_Clip and Super_File_Clip
Making this change would bring us closer to a consensus, it would simplify the
spec and keep it clean, and would eliminate overlapping and potentially
confusing functions.
> Well, we could start working right now by updating the primitives reference
> http://www.ldraw.org/memorial/archive/FAQ/Primitives_Reference
> by adding newer primitives and stating the orientation.
Good idea. That should be another thread, shouldn't it?
> If we "invent" another meta command, like
> 0 ORIENTATIONARROW x1 y1 z1 x2 y2 z2
> rendering programs could optionally draw an arrow and you could save
> a nice bitmap for the primitives reference.
Nice idea. You need a scale factor as well. Primitives are drawn in a variety
of scales (well, two scales: full size and -1-to-+1). For a reference document,
you'd need to be able to *see* all the primitives.
Considering how frequently some primitives are referenced in a rendered scene,
I'd rather minimize the excess data in the primitive files. I realize that
optimized renderers will only read and parse each file once, but why throw in
something that isn't necessary to the process of rendering.
We could just make a file which steps through each of the primitives, including
an orientation vectors. Something like (the first arrow is not right):
0 Primitive Reference
0 Name: PRIMREF.DAT
0 WRITE 1-4CON1.DAT 1/4 Cone Section 1:2 Radius, Scale: 10x
1 16 0 0 0 10 0 0 0 10 0 0 0 10 1-4con1.dat
2 24 -10 5 0 -30 5 0
3 24 -30 5 0 -25 5 2.5 -25 5 -2.5
0 STEP
0 CLEAR
0 WRITE 4-4DISC.DAT Full Disc, (X,Z)= (-1 to 1, -1 to 1), Scale: 10x
1 16 0 0 0 10 0 0 0 10 0 0 0 10 4-4disc.dat
2 24 0 0 0 0 -30 0
3 24 0 -30 0 -2.5 -25 0 2.5 -25 0
0 etc, etc
Then we could just add new primitives as they appear. Kind of awkward to view,
but it could be a way to proceed.
Steve
|
|
| |
Steve Bliss wrote...
> On Wed, 10 Nov 1999 00:44:17 GMT, "Lars C. Hassing" <lch@ccieurope.com> wrote:
> > The CERTIFY section:
> > > operational command-line in the file. No other statements are required for
> > > backface culling to be applied to a file.
> >
> > Then please add:
> > 0 CERTIFY BFC implies 0 CLIPPING ON and 0 WINDING CCW.
>
> CERTIFY BFC doesn't imply CLIPPING ON -- the clipping mode/setting comes from
> the superfile (for the main model-file, clipping is set by the rendering engine
> or an explicit CLIPPING ON statement).
But it *does* imply CLIPPING ON. Otherwise clipping would be off.
Remember, CLIPPING ON cannot turn clipping on if turned off in a
superfile.
If you render the part alone (just to view the single part) the CERTIFY
should enable clipping just like an explicit CLIPPING ON statement,
which you mentioned yourself above.
> WINDING CCW is the default for files, as stated in the section for WINDING.
> CERTIFY doesn't imply CCW winding at all--if a file started with these two
> lines:
>
> 0 WINDING CW
> 0 CERTIFY BFC
>
> ... the winding should be CW, right?
Well, it depends on what you mean by "operational command-line" in
"Every clippable file must include exactly one CERTIFY meta-statement,
and it must appear before the first operational command-line in the file."
It could also be an error if the CERTIFY is not first!
> > > UNKNOWN = winding direction is unknown or variable. This setting will
> > > disable clipping, until the winding is reset.
> > >
> > > The WINDING setting is a local setting, it applies only to the polygons in
> > > the file in which the WINDING meta-statement appears.
> >
> > "...This setting will disable clipping..." - I hope readers do not confuse
> > this with CLIPPING OFF. Although the next sentence says WINDING is local,
> > it should be made clear that clipping is not turned off for subfiles.
> > Can you think of a better wording of the two sentences?
> > Also there should be some words about using 0 CLIPPING OFF for a
> > double-sided section of a file.
>
> Ergh. Thank you for pointing this out. I had not thought through all the
> implications of the WINDING UNKNOWN (maybe WINDING NONE?) setting.
>
> My intention was that WINDING UNKNOWN *would* disable clipping for subfiles, but
> that is obviously *not* the way the document is written, and making things work
> that way would be non-elegant. Then again, it seems counter-productive to
> require part-authors to use both WINDING UNKNOWN and CLIPPING OFF when they make
> use of subfiles in a non-compliant or double-sided section.
Part-authors only have to use CLIPPING OFF, as it turns off clipping
for both local polygons (i.e. WINDING UNKNOWN is not needed) as well
as polygons in subfiles.
> Maybe it would be better to drop WINDING UNKNOWN and specify that the default
> value for CLIPPING is ON. File authors would use CLIPPING OFF for double-sided
> or non-compliant sections of code. Note that the CLIPPING default would really
> only effect the main file in a rendering, because superfiles would pass down
> their clip-setting to subfiles.
>
> Curent_Clip = Local_Clip and Super_File_Clip
>
> Making this change would bring us closer to a consensus, it would simplify the
> spec and keep it clean, and would eliminate overlapping and potentially
> confusing functions.
Yes.
> We could just make a file which steps through each of the primitives, including
> an orientation vectors. Something like (the first arrow is not right):
>
> 0 Primitive Reference
> 0 Name: PRIMREF.DAT
> 0 WRITE 1-4CON1.DAT 1/4 Cone Section 1:2 Radius, Scale: 10x
> 1 16 0 0 0 10 0 0 0 10 0 0 0 10 1-4con1.dat
> 2 24 -10 5 0 -30 5 0
> 3 24 -30 5 0 -25 5 2.5 -25 5 -2.5
> 0 STEP
> 0 CLEAR
> 0 WRITE 4-4DISC.DAT Full Disc, (X,Z)= (-1 to 1, -1 to 1), Scale: 10x
> 1 16 0 0 0 10 0 0 0 10 0 0 0 10 4-4disc.dat
> 2 24 0 0 0 0 -30 0
> 3 24 0 -30 0 -2.5 -25 0 2.5 -25 0
> 0 etc, etc
>
> Then we could just add new primitives as they appear. Kind of awkward to view,
> but it could be a way to proceed.
Though I think it is always better to place the information where it
belongs, your PRIMREF.DAT is a brilliant idea - scaling fixed too!
It looks good (nice arrows) and uses the tools we already have.
/Lars
|
|
| |
[ Still discussing http://www.geocities.com/partsref/bfcspec.txt ]
Steve:
> On Wed, 10 Nov 1999 00:44:17 GMT, "Lars C. Hassing"
> <lch@ccieurope.com> wrote:
[...]
> > 0 INVERT
> > (or maybe "0 INVERTNEXT" to stress that it is only the
> > following line, which must be of type 1, that is turned
> > inside-out)
>
> Hmm. Interesting thought. I like it. Anyone else want
> to ( yay | nay ) this?
"INVERTNEXT" is good. It makes the effect much more clear.
> > The CERTIFY section:
> > > operational command-line in the file. No other
> > > statements are required for backface culling to be
> > > applied to a file.
> >
> > Then please add:
> > 0 CERTIFY BFC implies 0 CLIPPING ON and 0 WINDING CCW.
>
> CERTIFY BFC doesn't imply CLIPPING ON -- the clipping
> mode/setting comes from the superfile (for the main
> model-file, clipping is set by the rendering engine or an
> explicit CLIPPING ON statement).
It gets much too messy when you mix the states of a
parameter and the setting of that parameter.
CERTIFY BFC does imply CLIPPING ON, but it will not
necessarily mean that any clipping will be done, because
that depends on the super-file as well.
When processing a LDraw file you have three _local_
variables:
- "bfc-certified" is initialised to false and should at
most be changed once by a LDraw file.
- "winding" is initialised to "ccw".
- "clipping" is initialised to "on".
The statement "0 CERTIFIED ( BFC | NOBFC )" will modify the
variable "bfc-certified", the statement "0 WINDING ( CW |
CCW | UNKNOWN )" will modify the variable "winding", and the
statement "0 CLIPPING ( ON | OFF )" will modify the variable
"clipping".
Two parameters are passed to the processing routine:
- "accumulated_clipping" is true when processing the root
file, and will otherwise only be true if both
"accumulated_clipping" and "clipping" were true in the
super file at the calling point.
- "inverted" is false when processing the root file, and
will otherwise depend on whether the calling statement
was preceded by a "0 INVERTNEXT" line. If it was, the
value of "inverted" will be the opposite of that in the
super file. If it wasn't tha value will be the same as
that in the super file.
Back-face-culling will only be applied if all of the
following apply:
- "bfc-certified" is true
- "accumulated_clipping" is true
- "clipping" is true
- "winding" is "cw" or "ccw"
The winding used for back-face-culling will be that of the
variable "winding", if "inverted" is false. Otherwise it
will be the opposite ("unknown" being neutral).
> 0 WINDING CW
> 0 CERTIFY BFC
>
> ... the winding should be CW, right?
Maybe. It depends on the definition of "operational
command-line".
I understand why you sometimes use specialised "programming"
languages for writing specifications.
> If the CERTIFY statement 'implied' the winding, then this
> example would not be clear (at least to the human reader)
> if the winding for this file is CW or CCW.
> Does CERTIFY override the earlier WINDING or not?
If "0 WINDING CW" is an operational command-line, it doesn't
matter. Otherwise the result is somewhat unclear. I would
prefer that that sequence wasn't allowed.
There isn't much point in allowing the use of BFC
meta-commands before you have notified the renderer that you
intend to follow the rules for BFC meta-commands.
> That's why the WINDING setting has a default value, and
> CERTIFY doesn't affect the WINDING setting in any way.
>
> BUT, I'll see what I can do with the verbiage, to make
> things more clear.
> > The WINDING section:
> > > 0 WINDING [ CW | CCW | UNKNOWN ]
> > > default: CCW
The default value is not for the WINDING _statement_, but
for the "winding" variable.
> CLIPPING doesn't need a default, because it is passed down
> from the superfile. It is up to the rendering engine to
> provide the initial value of CLIPPING.
The "clipping" variable does need to have a default value.
Otherwise you would be unable to distinguish between the
local setting and the clipping _status_ passed from the
super file (or you would break the clipping rules).
> Maybe it would be better to drop WINDING UNKNOWN and
> specify that the default value for CLIPPING is ON.
I don't think so. If you could translate my explanation
above to proper English, then the problem should be solved,
with the effect I understand you intended.
Play well,
Jacob
------------------------------------------------
-- E-mail: sparre@cats.nbi.dk --
-- Web...: <URL:http://www.ldraw.org/FAQ/> --
------------------------------------------------
|
|
| |
In lugnet.cad.dev, Jacob Sparre Andersen wrote:
> [ Still discussing http://www.geocities.com/partsref/bfcspec.txt ]
>
> Steve:
>
> > On Wed, 10 Nov 1999 00:44:17 GMT, "Lars C. Hassing"
> > <lch@ccieurope.com> wrote:
> > > 0 INVERT
> > > (or maybe "0 INVERTNEXT" to stress that it is only the
> > > following line, which must be of type 1, that is turned
> > > inside-out)
> >
> > Hmm. Interesting thought. I like it. Anyone else want
> > to ( yay | nay ) this?
>
> "INVERTNEXT" is good. It makes the effect much more clear.
OK, I'll change this in the document. Changes from the last few days will be
uploaded to GeoCities in the next hour or so.
Steve
|
|
| |
In lugnet.cad.dev, Jacob Sparre Andersen wrote:
> [ Still discussing http://www.geocities.com/partsref/bfcspec.txt ]
> > 0 WINDING CW
> > 0 CERTIFY BFC
> >
> > ... the winding should be CW, right?
>
> Maybe. It depends on the definition of "operational
> command-line".
>
> I understand why you sometimes use specialised "programming"
> languages for writing specifications.
Did you mean you=Steve or you=anyone?
> > If the CERTIFY statement 'implied' the winding, then this
> > example would not be clear (at least to the human reader)
> > if the winding for this file is CW or CCW.
> > Does CERTIFY override the earlier WINDING or not?
>
> If "0 WINDING CW" is an operational command-line, it doesn't
> matter. Otherwise the result is somewhat unclear. I would
> prefer that that sequence wasn't allowed.
I agree, the sequence should be illegal.
My point was, does CERTIFY BFC change the value of the internal local_clipping
variable, or not? My intention was that it does not. From a practical
viewpoint, it might as well, but it is not necessary for it to do so.
> The default value is not for the WINDING _statement_, but
> for the "winding" variable.
Good point. I will incorporate this into the document.
> I don't think so. If you could translate my explanation
> above to proper English, then the problem should be solved,
> with the effect I understand you intended.
How about some pseudo-code? Skipping a few beside-the-point details:
Recursive Procedure RenderFile
Parameters:
ModelFile string // File to render
AccumClip boolean // global clipping value yes/no
AccumInvert boolean // current inversion odd/even or normal/inverted
Declare
LocalClip boolean = TRUE
Winding trivalue(CCW, CW, UNKNOWN) = CCW
Certified boolean = FALSE
InvertNext boolean = FALSE
OpenFile(ModelFile)
Do Until EOF(ModelFile)
Get Next Command
Case Command.LineType
CERTIFY
Certified = (Command.Option = "BFC")
CLIPPING
LocalClip = (Command.Option = "ON")
WINDING_CCW
If AccumInvert Then
Winding = CW
Else
Winding = CCW
WINDING_CW
If AccumInvert Then
Winding = CCW
Else
Winding = CW
WINDING_UNKNOWN
Winding = UNKNOWN
INVERTNEXT
InvertNext = True
SUBFILE
RenderFile Command.Subfile,
(AccumClip and LocalClip),
(AccumInvert xor InvertNext)
LINE, CONDITIONAL_LINE
Deal with primitive command
TRIANGLE, QUAD
If AccumClip and LocalClip Then
If BFC(Command, TransformMatrix, Winding) Then
Render Command
Else
Don't render Command
Else
Render Command
End If
End Case
If Command.LineType != INVERTNEXT Then
InvertNext = FALSE
End If
Loop
End Procedure
Ick. Longer than I thought. Maybe I'll go back to plain English.
Steve
|
|
| |
[ Still discussing http://www.geocities.com/partsref/bfcspec.txt ]
Steve:
> In lugnet.cad.dev, Jacob Sparre Andersen wrote:
> > I understand why you sometimes use specialised "programming"
> > languages for writing specifications.
>
> Did you mean you=Steve or you=anyone?
You=anyone (kind of - English is a very imprecise language - "on"
in French, "man" in Danish, ...)
> My point was, does CERTIFY BFC change the value of the
> internal local_clipping variable, or not? My intention
> was that it does not. From a practical viewpoint, it
> might as well, but it is not necessary for it to do so.
That depends on how the program is written. You could
imagine that the variable "local_clipping" isn't defined
until it is verified that it is relevant.
> > I don't think so. If you could translate my explanation
> > above to proper English, then the problem should be solved,
> > with the effect I understand you intended.
>
> How about some pseudo-code? Skipping a few beside-the-point details:
[...]
Good. I think this clarifies a lot.
> Ick. Longer than I thought. Maybe I'll go back to plain English.
I don't think you can make it shorter as plain English, but
I will not complain if you attempt.
Play well,
Jacob
------------------------------------------------
-- E-mail: sparre@cats.nbi.dk --
-- Web...: <URL:http://www.ldraw.org/FAQ/> --
------------------------------------------------
|
|
| |
Steve Bliss wrote ...
> How about some pseudo-code
I think your pseudo-code delivers a fine evidence why the CERTIFY
is unnecessary ;-)
/Lars
|
|
| |
Oops! Forget a few important details in the psuedo-code!
In lugnet.cad.dev, Steve Bliss writes:
> ModelFile string // File to render
> AccumClip boolean // global clipping value yes/no
> AccumInvert boolean // current inversion odd/even or normal/inverted
>
> Declare
> LocalClip boolean = TRUE
> Winding trivalue(CCW, CW, UNKNOWN) = CCW
> Certified boolean = FALSE
> InvertNext boolean = FALSE
>
> SUBFILE
> RenderFile Command.Subfile,
> (AccumClip and LocalClip),
The last line above should be:
(AccumClip and LocalClip and
(Winding != UNKNOWN) and Certified),
> (AccumInvert xor InvertNext)
> LINE, CONDITIONAL_LINE
> Deal with primitive command
> TRIANGLE, QUAD
> If AccumClip and LocalClip Then
And the line above should be:
If AccumClip and LocalClip
And Certified Then
> If BFC(Command, TransformMatrix, Winding) Then
> Render Command
> Else
> Don't render Command
> Else
> Render Command
> End If
|
|
| |
Steve Bliss wrote in message ...
> Oops! Forget a few important details in the psuedo-code!
>
> In lugnet.cad.dev, Steve Bliss writes:
>
> > ModelFile string // File to render
> > AccumClip boolean // global clipping value yes/no
> > AccumInvert boolean // current inversion odd/even or normal/inverted
> >
> > Declare
> > LocalClip boolean = TRUE
> > Winding trivalue(CCW, CW, UNKNOWN) = CCW
> > Certified boolean = FALSE
> > InvertNext boolean = FALSE
> >
> > SUBFILE
> > RenderFile Command.Subfile,
> > (AccumClip and LocalClip),
>
> The last line above should be:
> (AccumClip and LocalClip and
> (Winding != UNKNOWN) and Certified),
No, WINDING is local! It does not affect subfiles, this is the very reason
why we have invented the CLIPPING command.
/Lars
|
|
| |
In lugnet.cad.dev, Lars C. Hassing wrote:
> No, WINDING is local! It does not affect subfiles, this is the very reason
> why we have invented the CLIPPING command.
Argh. You are correct, sir. Serves me right, trying to post quickly.
Here's a correction:
> > > SUBFILE
> > > RenderFile Command.Subfile,
> > > (AccumClip and LocalClip),
> >
> > The last line above should be:
> > (AccumClip and LocalClip and Certified),
Steve
|
|
|
