Subject:
|
Re: Some Words To BFC
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Wed, 5 Apr 2000 12:43:24 GMT
|
Reply-To:
|
Rui.Martins@link.{avoidspam}pt
|
Viewed:
|
2340 times
|
| |
|
|
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.
> 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.
> 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.
> 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
> Then the user has to disable BFC'ing and redraw--very bad.
Assuming my previous paragraph, if the user tryed to get the extra performance
he knows the risks.
But as I already said, these cases are few and there is not much overhead with
this solution.
> > 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 fewer the checks, the better !
> The question is whether or not the entire parts library can be brought into
> compliance with a reasonable amount of effort.
If you think about it, the only files which can NOT be automatically made
compliant (in full) are the files which have the "unwanted inverts".
the invertions using the inverted matrix are easilly converted.
> 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.
I may be able to branch my current project, to be a checker for this stuff.
But i'm not promissing anything now.
> If I've misstated anyone's position, or if I'm missing some major issue here,
> I apologize, and please enlighten me :)
I hope my explanations have enlighten you.
See ya
Rui Martins
|
|
Message has 2 Replies:
 | | Re: Some Words To BFC
|
| In lugnet.cad.dev, Rui Manuel Silva Martins writes: <SNIP> (...) until (...) <SNIP> This is not true: Since the renderer has to assume a certain state for his models. The thing (at least in MLCad) works as follows: If BFC is on than the model is (...) (25 years ago, 5-Apr-00, to lugnet.cad.dev)
| | | Re: Some Words To BFC
|
| Rui Martins <Rui.Martins@link.pt> wrote in message news:Pine.GSU.4.10.1...0@is-sv... (...) saying, (...) subfiles (...) those (...) fixed. (...) restrictions, (...) it. (...) until (...) the (...) allows (...) a (...) apply), (...) user. (...) (...) (25 years ago, 5-Apr-00, to lugnet.cad.dev)
|
Message is in Reply To:
| | Re: Some Words To BFC
|
| 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. (...) (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
|
|
|
|
