Subject:
|
Re: Some Words To BFC
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Tue, 4 Apr 2000 16:56:02 GMT
|
Highlighted:
|
!
(details)
|
Viewed:
|
1814 times
|
| |
|
|
Reflecting on (my impressions of) what Steve, Mike, and Rui have been saying,
it seems we have two possible directions to go.
One direction, which Steve has developed, assumes we will have some files
which are BFC compliant, and some which are not. Thus BFC compliance needs
to be transferred down the chain of subfiles, so that only compliant subfiles
of compliant parent files are BFC'd. Using this model, the part database
could be brought into compliance over time, with immediate benefits for those
parts which are fixed, and backward compatibility for those parts not fixed.
The other direction, promoted by Rui, ignores the subfile chain and allows
any file or subfile marked BFC compliant to be BFC'd. Rui suggests that to
deal with the problem of superfile inversions to subfiles, we either fix the
part or offer the option of disabling BFC'ing. In my mind, this really only
is workable if all of the primitives, subfiles, and part files can be brought
into compliance. Otherwise, someone using MLCad would render a model, only
to find out that a couple parts used are not BFC compliant but inverted a
primitive that is compliant. Then the user has to disable BFC'ing and
redraw--very bad.
From what Michael said, it seems the most preferable situation is where all
part files are brought into compliance and the rendering engine has to make
the fewest possible checks--which sounds to me more like the second option.
The question is whether or not the entire parts library can be brought into
compliance with a reasonable amount of effort. An application which
automates most of this work would be an imperative if it is to be done, and
at least several people would have to commit to using and checking such an
application.
If I've misstated anyone's position, or if I'm missing some major issue here,
I apologize, and please enlighten me :)
-John Van
|
|
Message has 3 Replies:
 | | Re: Some Words To BFC
|
| (...) A second question: *should* parts be required to be BFC-compliant? There is a certain amount of extra work required to make parts work for BFC. Without a mostly-automated cleanup tool, does it make sense to put this burden on part authors? (...) (25 years ago, 4-Apr-00, to lugnet.cad.dev)
| | | Re: Some Words To BFC
|
| (...) This is common to both every approach I have seen, obviously ! (...) Nope! No imediate benefits, because with the parent dependence restrictions, you have to have an entire branch compliant to be able to do BFC, which includes the root,i.e. (...) (25 years ago, 5-Apr-00, to lugnet.cad.dev)
| | | Re: Some Words To BFC
|
| (...) I'd like to have all parts compliant by making a second copy of the primitives that can't be inverted instead of using "0 INVERSE" commands. Leonardo (25 years ago, 5-Apr-00, to lugnet.cad.dev)
|
Message is in Reply To:
| | Some Words To BFC
|
| Hy, I finaly got internet-access here, and could follow the discussions about BFC. Some words I would like to say first: I think it doesn't make sence to blame Steve about BFC stuff, since I asked him if the spec is in a state that we could try it. (...) (25 years ago, 4-Apr-00, to lugnet.cad.dev)
|
61 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
|
|
|
|
