Subject:
|
Re: BFC: LITS 2
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Tue, 4 Apr 2000 15:27:15 GMT
|
Reply-To:
|
RUI.MARTINS@avoidspamLINK.PT
|
Highlighted:
|
(details)
|
Viewed:
|
1799 times
|
| |
|
|
> > > At the least, the standard should say, "the BFC options must be
> > > explicitly declared in each file. If a file has an invalid declaration,
> > > the rendering engine should assume X and Y."
> >
> > Agreed! but that's NOT currently written that way, is it ?
>
> No, it isn't. BUT, there is very little functional difference between
> what is currently written and the suggestion above. As far as the
> function of a rendering engine is concerned, there is no difference --
> if a file doesn't specify the options, the renderer will use assumed
> values.
OK, I just stated that this isn't written as said above, maybe it would be
clearer if it was, but I undestood it from the "proposed spec".
[...SNIP...]
> > > > Allows a mix of extended and unextended files in one rendering, but
> > > > to allow clipping, all files, have to be certified !?!?
> > >
> > > This is an issue of language in the document. The second quoted passage
> > > was updated to read:
> >
> > NO it is NOT ! read on.
>
> Yes, this specific issue (comparing the two pieces of text), is at most
> a language issue. The two sections are not contradictory, they are
> unclear. The first section simply says that a model (that is, a
> collection of multiple DAT files) may include both certified and
> uncertified files. The second section says that when a subfile is
> rendered, all superfiles in the reference-chain must be certified in
> order for the subfile to be BFC'ed (along with the other conditions).
[Mind Drill ON 8) ]
I got that, but you keep on thinking about it, without trying the other
solution (the one which does not require the reference-chain dependence)
[Mind Drill OFF 8( ]
> > > |4 Clipping. It must be possible for a file to enable and disable clipping. But
> > > |4 even when clipping is enabled locally, it may not be possible to perform
> > > |4 clipping on the file in some circumstances. Any file will have clipping
> > > |4 applied only when the following conditions apply:
> > > |4 - All superfiles (in the current reference branch) are certified.
> > > |4 - The current file is certified.
> > > |4 - No superfile has disabled clipping prior to referencing this
> > > |4 subfile.
> > > |4 Unless all of these conditions are met at the time a subfile is rendered,
> > > |4 no clipping is possible.
> >
> > I know that the branch only would be required, but I don't agree with
> > this, it's too restrictive, withou need for it.
>
> Do you have a solution for it?
YES, just allow any *.dat to be BFCed for it self, no reference-chain
dependence. If the uggly undesirable invert feature (without matrix inversion)
is encountered, just disable cliping.
I' have already mentioned this in a very recent mail.
[...SNIP...]
> > > |7 Assumed inversions. Generally, it is not possible to assume that a subfile
> > > |7 is inverted or normal (which is the reason for the 0 BFC INVERTNEXT meta-
> > > |7 statement). One important special case is this: model files do not invert
> > > |7 part files. Parts are complex files which would be essentially useless if
> > > |8 they were inverted. Assuming part files are never inverted allows
> > > |9 the rendering engine to apply BFC-processing on these parts (assuming the
> > > |9 parts are certified), even if the calling files aren't certified.
> > > |7
> > > |7 No assumptions can be made about models which make direct use of primitives
> > > |7 or polygon commands, so a rendering engine should not simply treat uncertified
> > > |7 model files as certified.
> >
> > More processing clutter ! Undesirable
>
> No rendering engine has to do this (make assumptions about references to
> file in the parts directory). It is included in the spec as a
> suggestion for one way to improve performance.
Ok it's a sugestion !, but it won't help performance, it will actually
slowdown the program
> > First, Use comments, instead of clutering the BFC extension, and
> > disable CLIP in the section.
>
> Huh? I don't understand what you mean.
I said that in sequence of this:
"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. "
so, don't use WINDING UNKNOWN or DOUBLE-SIDED, instead just DISABLE CLIPPING
in that section.
If the author actually doesn't know the state of the winding, then he can
insert a comment
"0 unknown winding in the next section, so cliping disabled"
before the section, and another comment
"0 unknown winding in the previous section"
after or something similar.
The renderer does NOT need or want's to know if it is unknown or double-sided,
it just want't to know if it can be clipped or NOT.
> > Second if the "All branch must have cliping on to BFC" was NOT used, ideia
> > which I'm in favour, then no cliping info would be passed to references.
>
> That would be nice, but you haven't said how we're supposed to get
> around the problems.
There is only one problem, the "unwanted invert without matrix inversion",
and in that case just do what I have already said in this and a recent mail,
disable cliping (at user option), until the file is correct.
The renderer will render errouneously, if the user does NOT disable cliping.
Also if we want to be picky, we could add a config file to the renderers, so
that they now the current know files with unwanted inversions, so that they
could disable cliping in all the reference branchs which derived from them.
But I think this is too much work, and NOT worth it, just fix the file.
> > > In <http://www.lugnet.com/cad/dev/?n=3211>, Lars wrote:
> > >
> > > > Also there should be some words about using 0 CLIPPING OFF for a
> > > > double-sided
> > > > section of a file.
> >
> > Use comments, not Meta-commands, they will inder performance if use when
> > NOT absolutly required.
>
> I don't understand what you are saying here.
Same comment as before, the renderer does NOT need to know if it's double
sided or NOT, it just needs to know if it can be clipped or NOT.
Users should use this knowledge to implement double-sided faces. And to
document it just use comments, like in:
" 0 This section has clipping disabled due to beeing double sided!"
> > > This is an open issue. It's noted at the end of the document. That
> > > should be moved to the top.
> >
> > BIG Open Issue ! wouldn't you say ?
> >
> > It affects the entire way of processing files!
>
> I wouldn't say this is a big open issue, because Lars was discussing the
> need for documentation of the method, not discussing the methodology
> directly.
Maybe I got a litle ahead ! ;) sorry
What I meant is the CLIPPING assumptions and the processing rules which derive
from there.
If cliping is local, my tought is that no other file should influence clipping
in the current file unless itself. No reference-chain dependencies.
Since the begining that I am in favour of BFC extensions behaving like
state/methods of an object, the DAT file.
See ya
Rui Martins
|
|
Message has 1 Reply:
 | | Re: BFC: LITS 2
|
| (...) I've kept thinking about it, and I don't see a solution. There are some algorithms that can figure out the normal/inverted question in some cases, but these algorithms would be too slow to implement in a rendering program. And they are not (...) (24 years ago, 7-Apr-00, to lugnet.cad.dev)
|
Message is in Reply To:
| | Re: BFC: LITS 2
|
| (...) No, it isn't. BUT, there is very little functional difference between what is currently written and the suggestion above. As far as the function of a rendering engine is concerned, there is no difference -- if a file doesn't specify the (...) (24 years ago, 3-Apr-00, to lugnet.cad.dev)
|
24 Messages in This Thread:
  
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
