Subject:
|
Re: Some Words To BFC
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Wed, 5 Apr 2000 14:17:46 GMT
|
Viewed:
|
2700 times
|
| |
|
|
Rui Martins <Rui.Martins@link.pt> wrote in message
news:Pine.GSU.4.10.10004051313380.16816-100000@is-sv...
> On Tue, 4 Apr 2000, John VanZwieten wrote:
>
> > 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.
>
> This is common to both every approach I have seen, obviously !
>
> > 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.
>
> 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. the Model file, which includes part files.
>
> So every model you have made until now will NOT benefit unless you re-edit • it.
> Also the more used files are the primitives files, which you won't benefit • until
> a part file is correct, since they generally reside at the leaf nodes of • the
> branch.
>
> You will have backward compatibility but at what cost ? to many checks !
>
> > The other direction, promoted by Rui, ignores the subfile chain and • allows
> > any file or subfile marked BFC compliant to be BFC'd.
>
> This assumption can be made, since all our *.dat files are used to define • a
> solid object (it should be solid, lego oarts are, only stickers don't • apply),
> which tells us that any face can be clipped if it is facing away from the • user.
>
Surely you don't mean _all_ our _*.dat_ files! All but a couple of the
primitives do not represent solid objects, and this is the central problem
with allowing them to be BFC'd in a non-certified part. There is no way you
can tell just from the winding if a 4-4cyli.dat is supposed to face out or
in.
> > 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.
>
> Only the unwanted inverts ! (the ones which don't use an invert matrix),
> which are NOT so many.
Why do you say not so many? Don't all the n x n bricks and plates use a box
primitive for the outside and the same box primitive for the inside? So if
we certify the box5.dat without fixing all the bricks and plates, all their
undersides will dissappear when using BFC.
> > In my mind, this really only
> > is workable if all of the primitives, subfiles, and part files can be • brought
> > into compliance.
>
> Not necessarily ! only a few files will show this problem, but every file
> already made can have IMEDIATE BENEFITS from the revised/compliant *.dat • files,
> as soon as they are available.
I beg to differ. Some files will show immediate benefits, while others will
be really messed up.
> > 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.
>
> In this case (which I already tought about) we just have to define as • default
> that overall clipping (render program option) is DISABLED, which will give • the
> user the same behaviour of today, if the user want's to increase • performance, he
> can turn the new feature on (ENABLE), knowing the POSSIBLE consequences if • used
> with non-BFC compliant files
IMHO, BFC isn't worth the work if it's not going to produce reliable results
along with increased performance. Having even 10% of he parts in my model
rendered incorrectly is not acceptable.
-John Van
|
|
Message has 1 Reply:
 | | Re: Some Words To BFC
|
| (...) If you assume (which is correct for lego parts) that every *.dat file you use to define a part, belongs to a whole object (the part) which is a solid object (it should be) then you can say that any of those subfiles can have their faces (...) (25 years ago, 5-Apr-00, to lugnet.cad.dev)
|
Message is in Reply To:
| | 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)
|
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
|
|
|
|
