Subject:
|
Re: BFC and Primitives
|
Newsgroups:
|
lugnet.cad.dev.org.ldraw
|
Date:
|
Wed, 6 Mar 2002 22:32:03 GMT
|
Viewed:
|
332 times
|
| |
|
|
Damien Guichard wrote:
> In lugnet.cad.dev.org.ldraw, Steve Bliss writes:
>
> > Dear All (but mostly PT Reviewers),
> >
> > I'd like to update all the current primitive files to be BFC compliant.
> > This wouldn't be a huge task, at least for the geometric primitives (boxes,
> > circles, discs, rings, cones, cylinders, and torii).
> >
> > But when I start submitting these files to the Parts Tracker, most part
> > files will change status to "one or more subfiles not certified". This
> > could wreak havoc with us reviewing and certifying files - if no one reviews
> > the primitives, the parts can never reach a "certified!" status.
> >
> > So my question is this: if I submit BFC'ed primitives, is anyone ready and
> > willing to review the files for correctness? If no is able to review these
> > files, I won't submit them at this time.
> >
> > Steve
>
>
> IMHO, i don't consider BFC statements as an important ldraw issue, for
> following reasons:
>
> 1. Popular tools do not use these statements (including LDraw, MLCad, LDView
> and L3P & POV-ray). L3Lab use them but L3Lab is superceded by LDView both in
> speed and quality.
Some of those tools ( I know MLCad can use them ) already support them.
On top of that those are not the only tools around!
> 2. BFC statements have little or no potential in display speed improvement.
This is just not true. In my program it make a big deal. In general, anytime
you can quickly narrow down the number of triangles you need to process, you
will save time.
> This is the main reason why MLCad has switched to a better technique
> (different traversal of the BSP tree). The BSP tree traversal for which BFC
> statements have been designed will soon be (or already is) obsolete. BFC
> does not worth the effort.
I'm not sure I follow this statement. How does it matter what order you
process the triangles (traverse the tree) if you always have to process them
all it will take longer than processing some subset. What other criteria
does MLCad use to eliminate triangles from consideration? Is it doing
occlusion culling now?
> 3. I never review BFC statements, I treat them as comments. I know that is
> not be advocated behavior but I clearly assume that.
>
> I can vote BFC-equippped primitives, but then just expect blind votes.
> Finally, I don't want frozen PT situation due to upgrade to BFC primitives.
>
> I am sorry I am not more cooperative,
> Damien
--
_
-------------------------------ooO( )Ooo-------------------------------
Kyle J. McDonald (o o)
|||||
\\\//
(o o) kmcdonald@BigFoot.COM
-------------------------------ooO(_)Ooo-------------------------------
|
|
Message has 1 Reply:
 | | Re: BFC and Primitives
|
| I quote Michael Lachmann, from MLCad file ReleaseNotes.txt: Beginning with release V2.00 MLCad does no longer support BFC. However the metacommand itself is still supported but has no effect on drawing (BFC - BackFaceCulling was an experiment on (...) (22 years ago, 7-Mar-02, to lugnet.cad.dev.org.ldraw)
|
Message is in Reply To:
| | Re: BFC and Primitives
|
| (...) IMHO, i don't consider BFC statements as an important ldraw issue, for following reasons: 1. Popular tools do not use these statements (including LDraw, MLCad, LDView and L3P & POV-ray). L3Lab use them but L3Lab is superceded by LDView both in (...) (22 years ago, 6-Mar-02, to lugnet.cad.dev.org.ldraw)
|
26 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
|
|
|
|
