| |
> Steve:
>
> I have a small linguistic correction, but except for that,
> I consider the document finished:
>
> There will be a few requirements placed on the design of rendering programs,
> in order to achieve correct renderings. Any program should may violate
> ^^^^^^^^^^
> Wouldn't "may" be sufficient?
>
> these requirements, if there is another way to acheive a valid rendering.
Agreed, it's logical. Should is too strong ! not like must, but strong
anyway.
> Rui:
>
> > > > > <http://www.geocities.com/partsref/bfcspec.txt>
>
> > I don't have much time now, but here are several problems.
> >
> > Examples:
> >
> > check the following two statements:
> > ---------------------------------------------------------------------------
> > > To make this standard useful and effective, the LDraw parts library
> > > must be updated to follow the new standard. Since it would be difficult to
> > > rewrite the entire library in one update, the standard will allow for a
> > > mix of extended and unextended files in one rendering.
> >
> > ---------------------------------------------------------------------------
> > > 2 Allowable Clipping. A subfile can only have clipping applied when the
> > > 2 following conditions apply:
> > > - All superfiles are certified.
> > > - The current file is certified.
> > > 2 - No superfile has disabled clipping prior to referencing this
> > > 2 subfile.
> >
> > ---------------------------------------------------------------------------
> >
> > Allows a mix of extended and unextended files in one rendering, but
> > to allow clipping, all files, have to be certified !?!?
>
> All the files in the relevant _branch_ of the rendering
> tree.
of course, but all files start on one root, if that is no BFC certified,
than no acceleration.
> If you certify your model, then every certified primitive
> will be drawn with back-face-culling when it is used for a
> certified part.
but a certified part can have sub parts not certified ! hence another
no-go.
> You can't get it any better!
Yes you can !
Every file (primitive / subpart / part / model) once certified, will
benefit for it
self, as long as CLIPPING is LOCAL.
There is only one problem, and that is the builder friendly INVERT
command context.
Example:
If some builder in the past made a file which enherently uses the
primitive/subpart inside-out, then when this primitive/subpart is
certified, all files that used it inside-out will have erroneously clipped
polygons.
I am shure that all you guys can figure out a solution for this, taking
into account the benefits of this option.
Some suggestion (haven't thought much one these iet):
- Only certify these error prune primitives after checking
all the already made subparts/parts that use them are certified.
Future subparts/parts should take the invert command into account.
OR
- supply the inside-out versions of these primitives, for compatibility
with older files.
OR
- Impose your rule (all tree branches must be certified) ONLY for
primitives (because they are the ones which are used inside-out
sometimes), but not to the whole tree branch.
OR
- Create a New file extension '*.dtc', for *.dat files which ware clipping
certified.
Do you have any more suggestions / constructive criticism.
> As soon as all the primitives are certified and people start
> to insert certification flags in their models, all certified
> parts will be drawn with back-face-culling.
That will take a lot of time. we should see progress (acceleration)
as soon as we start implementing it.
One major acceleration will be the 'stud.dat' file, because, AFAIK
no one uses it inside-out.
> I repeat: You can't get it any better!
see above.
> > This basicly resumes to:
> > - You won't benefit from the changes, UNLESS ALL the files you use
> > are certified.
>
> Wrong.
In branches, obviously, try to be constructive ;).
> > - Every already made (Old) model, won't ever benefit unless it is
> > redited.
>
> Yes, but if it only refers to ordinary parts, that is just a
> matter of inserting a "0 CERTIFY BFC" line in the file.
NO, all your *.dat files in every tree branch born on the top level
*.dat file (the model).
> I presume that the modelling programs (such as MLCAD) will
> insert the "0 CERTIFY BFC" line automatically in all models
> built in the "builder mode" (but not in "parts author
> mode").
Good suggestion !
> > > In some cases, it may be desirable to assume that a file is
> > > right-sideout, (and therefore clippable) even though not all superfiles
> > > are certified. One obvious example is files in the ldraw\parts
> > > directory.
> >
> > This paragraph is another one, sorry to say this, but IMHO
> > this paragraph it's a mess. (Could someone explain better !?)
>
> It means that there could be an option in the renderer that
> tells it that some files assume that their supermodels are
> certified, even if they (the supermodels) don't contain a
> "0 CERTIFY BFC" line.
>
> This is just an _option_ for the renderers, which can make
> them use back-face-culling on old models without a
> "0 CERTIFY BFC" line.
>
> > So now we can bend some of the rules, depending on path or something
> > else (which is not defined). How is this supposed to be implemented ?
>
> The renderers are allowed to give the user the _option_ of
> bending the rules slightly.
These things makes me remember the word 'hacking', until you get your
code running.
> > And what about the suggestion that someone supplied, that the default
> > context should be clarified ?
>
> > In my opinion the language extensions should be written with curly
> > braces '{' '}' instead of '[' ']', because the later means optional
> > parameter and the previous means compulsory parameter with possible
> > options if the pipe '|' is used.
>
> > So IMHO it should be like this:
> > -----------------------
> > 0 CERTIFY { BFC | NOBFC }
> > default: NOBFC
>
> No, but you could write it like this:
>
> { 0 CERTIFY [ BFC | NOBFC ] }
Resuming the above, and all the other examples which were after this last
example:
If you read the paragraph with the '{','}' ... etc (go read it again
please).
What it means is that with a rule like this:
0 CERTIFY [ BFC | NOBFC ]
you can come up with the following line:
0 CERTIFY
which is what should NOT be allowed ! Expecially in this case, if you
want this Meta-Command to be usefull/compatible for other certifications
in the future.
something like this:
{ 0 CERTIFY [ BFC | NOBFC ] }
is even worse, because it does not allow you to ommited the command
entirelly, this syntax as no logic at all. Maybe you swapped the context
of the '{' with the one of the '['.
But in any case, the whole command does not need to surrounded by
anything.
> The default value is for the case where the statement is
> omitted completely.
The same ideia here, Agreed.
> <SNIP>...
>
> > > UNKNOWN = winding direction is unknown or variable. This setting will
> > > disable clipping, until the winding is reset.
> >
> > Using someones expression, the UNKNOWN is 'syntatic sugar', because this
> > will be implemented internally as CLIPPING OFF.
> > If the user want's to inform that the 'winding' is not known,
> > then he can make a regular comment, and use CLIPPING OFF
>
> This sounds correct, but do we want to eliminate this
> syntactic sugar?
why not ?
Could you give a good reason !
See ya,
-----------
Rui Martins
|
|
| |
[ Still discussing http://www.geocities.com/partsref/bfcspec.txt ]
Rui:
> > > Allows a mix of extended and unextended files in one rendering, but
> > > to allow clipping, all files, have to be certified !?!?
> >
> > All the files in the relevant _branch_ of the rendering
> > tree.
>
> of course, but all files start on one root, if that is no BFC certified,
> then no acceleration.
Yes, but generally it is no big deal to certify a model file
- and there is the suggested option for the renderers
mentioned further down for the lazy.
> > If you certify your model, then every certified primitive
> > will be drawn with back-face-culling when it is used for a
> > certified part.
> but a certified part can have sub parts not certified ! hence another
> no-go.
Yes, but we aren't all that stupid. We will of cause start
certifying the primitives and critical sub-parts.
> > As soon as all the primitives are certified and people start
> > to insert certification flags in their models, all certified
> > parts will be drawn with back-face-culling.
>
> That will take a lot of time. we should see progress (acceleration)
> as soon as we start implementing it.
You can't eat a cake before you've baked it!
[...]
> > The renderers are allowed to give the user the _option_ of
> > bending the rules slightly.
>
> These things makes me remember the word 'hacking', until you get your
> code running.
It is an indirect way of accepting the files in the PARTS
directory as something special. Some of us feel that it is
important that all DAT files are equal (even though it, at
the moment, is practical that some are more equal than
others).
> > > In my opinion the language extensions should be written with curly
> > > braces '{' '}' instead of '[' ']', because the later means optional
> > > parameter and the previous means compulsory parameter with possible
> > > options if the pipe '|' is used.
I got it wrong first time.
I remember to have learnt that
( ... ) - means one copy of "...". This is just used to
group alternatives.
[ ... ] - means zero or one copy of "...".
{ ... } - means zero or more copies of "...".
According to that grammar, the production rules should be
written:
certification = "0" "CERTIFY" ( "BFC" | "NOBFC" ) { certification_flag }
winding = "0" "WINDING" ( "CW" | "CCW" | "UNKNOWN" )
clipping = "0" "CLIPPING" ( "ON" | "OFF" )
invert = "0" "INVERT"
> > This sounds correct, but do we want to eliminate this
> > syntactic sugar?
>
> why not ?
I like it.
Play well,
Jacob
------------------------------------------------
-- E-mail: sparre@cats.nbi.dk --
-- Web...: <URL:http://www.ldraw.org/FAQ/> --
------------------------------------------------
|
|
| |
On Tue, 9 Nov 1999 11:17:47 GMT, sparre@sys-323.risoe.dk (Jacob Sparre Andersen)
wrote:
> [ Still discussing http://www.geocities.com/partsref/bfcspec.txt ]
> certification = "0" "CERTIFY" ( "BFC" | "NOBFC" ) { certification_flag }
> winding = "0" "WINDING" ( "CW" | "CCW" | "UNKNOWN" )
> clipping = "0" "CLIPPING" ( "ON" | "OFF" )
> invert = "0" "INVERT"
You'll pardon me if I use an abbreviated notation, and skip the " characters.
> > > This sounds correct, but do we want to eliminate this
> > > syntactic sugar?
> >
> > why not ?
>
> I like it.
It's hard to argue with that.
Steve
|
|
| |
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
|
|
| |
On Mon, 8 Nov 1999 16:38:50 GMT, Rui Martins <Rui.Martins@link.pt> wrote:
> of course, but all files start on one root, if that is no BFC certified,
> than no acceleration.
As Jacob said, this is why the specification suggests that rendering programs
allow the user to select the option of defaulting CLIPPING to on or off.
> but a certified part can have sub parts not certified ! hence another
> no-go.
Huh? In that case, the uncertified primitive is not back-face-culled, but the
certified part is bfc'ed. How do want to improve this? The rendering engine
can't bfc un-certified files.
> Every file (primitive / subpart / part / model) once certified, will
> benefit for itself, as long as CLIPPING is LOCAL.
Nope. No subfile in a rendering, which is below an uncertified file, can assume
it is normal or inverted. It doesn't matter if we define CLIPPING as local or
passed-down.
Steve
|
|
| |
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?
|
|
| |
Steve:
> > [ Still discussing http://www.geocities.com/partsref/bfcspec.txt ]
> > certification = "0" "CERTIFY" ( "BFC" | "NOBFC" ) { certification_flag }
> > winding = "0" "WINDING" ( "CW" | "CCW" | "UNKNOWN" )
> > clipping = "0" "CLIPPING" ( "ON" | "OFF" )
> > invert = "0" "INVERT"
>
> You'll pardon me if I use an abbreviated notation, and skip the "
> characters.
Yes.
> > > > This sounds correct, but do we want to eliminate this
> > > > syntactic sugar?
> > >
> > > why not ?
> >
> > I like it.
>
> It's hard to argue with that.
The argument against should be that it complicates the
rendering significantly, but I don't think it does.
Play well,
Jacob
------------------------------------------------
-- E-mail: sparre@cats.nbi.dk --
-- Web...: <URL:http://www.ldraw.org/FAQ/> --
------------------------------------------------
|
|
 |
Special:
|
[DAT] (requires LDraw-compatible viewer)
|
Subject:
|
Re: Line in the Sand
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Wed, 10 Nov 1999 12:44:49 GMT
|
Reply-To:
|
RUI.MARTINS@nomorespamLINK.PT
|
Viewed:
|
2697 times
|
| |
|
|
On Tue, 9 Nov 1999, Steve Bliss wrote:
> On Mon, 8 Nov 1999 16:38:50 GMT, Rui Martins <Rui.Martins@link.pt> wrote:
>
> > of course, but all files start on one root, if that is no BFC certified,
> > than no acceleration.
>
> As Jacob said, this is why the specification suggests that rendering programs
> allow the user to select the option of defaulting CLIPPING to on or off.
Strange sentence, CLIPPING is OFF by default, you can change that by
including a CLIPPING ON. And this was not what was beeing discussed. See
below.
> > but a certified part can have sub parts not certified ! hence another
> > no-go.
>
> Huh? In that case, the uncertified primitive is not back-face-culled, but the
> certified part is bfc'ed. How do want to improve this? The rendering engine
> can't bfc un-certified files.
Look at this two trees
root root
C N
/ \ / \
C N C N
/| |\ /| |\
C N C N C N C N
1 2 3 4 5 6 7 8
'C' means a certified .DAT
'N' means a NOT certified .DAT
Branch:
1: C-C-C accelerated. Hence all files (this is the best case)
2: C-C accelerated -N UNaccelerated
3: C accelerated N-C UNaccelerated
4: C accelerated N-C UNaccelerated
5: none accelerated N-C-C UNaccelerated
6: none accelerated N-C-N UNaccelerated
7: none accelerated N-N-C UNaccelerated
8: none accelerated N-N-N UNaccelerated (This is the current case)
with some tweaking case 5 and 6 could also accelerate the 'C'ertified
files.
So resuming, with your proposal you can't accelerate all the
certified files, with my proposal you CAN.
This becomes even more evident if you have a branch like:
C-N-C-C-C-N-C
The higher the 'N'ot certified file is, the worst the case is.
remember that the first step is branch 7, we will try to
certified/optimize the primitives files.
The Only thing that I have not taken into account iet is:
" if any of these files has an INVERT command. "
Your proposal will have the same acceleration problems, but
my proposal will keep its robustness, if the invert command is processed
in the following form: (I refreshed my ideia)
- We have a Global state variable which keeps track of the current invert
state (by branch. NOTE: we should use depth first search order to use
only one variable).
- if the current file is processed with:
* invert_state = INVERTED, we interpret winding CCW as CW and vice-versa.
* invert_state = NORMAL, we interpret winding CCW and CW normally.
Remember that my proposal uses CLIPPING as a local setting.
Is this too complicated ?
I think not, maybe I can't explain my self well, or you guys are beeing
to stubborn. ;P sheech.
P.S.
Minstorm yourselfs please.
___
/ /_
/_ /
/ /_
/_ /
//
/
Rui Martins
|
|
| |
> <SNIP> ...
> > but a certified part can have sub parts not certified ! hence another
> > no-go.
>
> Yes, but we aren't all that stupid. We will of cause start • -------------------------
> certifying the primitives and critical sub-parts.
Don't take this so personally, it's not worth it.
I am only trying to contribute to a worthy cause (LEGO).
Everyone can have different opinions.
I don't need to jump on the other guys traught.
Anyway, I apologise if I have offended anyone,
but I think I haven't.
> > > As soon as all the primitives are certified and people start
> > > to insert certification flags in their models, all certified
> > > parts will be drawn with back-face-culling.
> >
> > That will take a lot of time. we should see progress (acceleration)
> > as soon as we start implementing it.
>
> You can't eat a cake before you've baked it!
I was thinking more on the lines of, a table full of cakes (parts), but
until you fill the table you can start eating the cakes which are already
there. 8-P
-----------
Rui Martins
|
|
| |
On Wed, 10 Nov 1999 12:53:51 GMT, Rui Martins <Rui.Martins@link.pt> wrote:
> > You can't eat a cake before you've baked it!
>
> I was thinking more on the lines of, a table full of cakes (parts), but
> until you fill the table you can start eating the cakes which are already
> there. 8-P
In our case, it makes sense to make a single trip to the store for ingredients
(primitives). Once we've got the ingredients on-hand, we can start baking the
cakes.
Steve
No, this didn't really add to the discussion. I just liked the analogy.
|
|
| |
On 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
|
|
| |
On Wed, 10 Nov 1999 12:44:49 GMT, Rui Martins <Rui.Martins@link.pt> wrote:
> On Tue, 9 Nov 1999, Steve Bliss wrote:
>
> > As Jacob said, this is why the specification suggests that rendering programs
> > allow the user to select the option of defaulting CLIPPING to on or off.
>
> Strange sentence, CLIPPING is OFF by default, you can change that by
> including a CLIPPING ON. And this was not what was beeing discussed. See
> below.
I don't think I understand you here. Do you mean that it is strange to let the
user and/or programmer of the rendering program set the initial CLIPPING value?
[clipped nice rendering-process tree]
> The Only thing that I have not taken into account iet is:
> " if any of these files has an INVERT command. "
>
> Your proposal will have the same acceleration problems, but
> my proposal will keep its robustness, if the invert command is processed
> in the following form: (I refreshed my ideia)
>
> - We have a Global state variable which keeps track of the current invert
> state (by branch. NOTE: we should use depth first search order to use
> only one variable).
>
> - if the current file is processed with:
> * invert_state = INVERTED, we interpret winding CCW as CW and vice-versa.
>
> * invert_state = NORMAL, we interpret winding CCW and CW normally.
>
> Is this too complicated ?
It's not too complicated. A rendering engine will always have to do this in
order to correctly clip polygons. But it won't allow us to make any assumptions
about C-N-C branches.
First question: which invert-state are we keeping track of, the occurrences of 0
INVERT or the determinant of the transformation matrix?
If we are tracking 0 INVERTS, then we must have certified files all the way down
the branch in order track the invert_state. One non-certified file breaks the
chain.
If we are just looking at the determinant of the transformation matrix, then we
don't need a global variable, the determinant can be id'ed locally. But the
determinant doesn't tell us what we need to know. We need to know the authors'
intentions when they wrote the various files in the branch. Did they mean to
invert or not?
There's no way to track the invert-state along a C-N-C branch.
The one assumption which can (generally) be made is this: references from the
main model file to the parts-files do *not* invert the subfile. If we also
*assume* the main model is certified[1], then any certified part-files can be
clipped.
Steve
1) Even if there's no 0 CERTIFY BFC in the main file, 99%+ model files are
compliant, because they only reference part-files, and do not intend to invert
the parts.
|
|
| |
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
|
|
|
