Subject:
|
Re: Some Words To BFC
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Thu, 6 Apr 2000 21:55:07 GMT
|
Viewed:
|
3661 times
|
| |
|
|
Steve Bliss <blisses@worldnet.att.net> wrote in message
news:i86oessafp98dp6k5qijvbmbbob7mkni81@4ax.com...
> OK. I've thought about most of John's posting, and I think I'm ready to
> make an intelligible response.
>
> Just to be sure I caught everything, here's a (hopefully quick)
> re-iteration.
>
> The major differences between John's proposal and the proposal I wrote
> up are (I don't have any good names for them, so I'll call them John's
> and Steve's. Even though the ideas are not exactly uniquely ours):
>
> 1. In John's proposal, all files in the parts library are required to be
> BFC-certified. In Steve's proposal, there can be a mix of certified and
> uncertified part-files.
> 2. In Steve's proposal, dat-authors can enable/disable BFC'ing, and
> switch between writing CW and CCW polygons. In John's proposal, winding
> is always CW, and BFC'ing is always enabled.
> 3. In John's proposal, subfile inversion is avoided by having pairs of
> primitives, each pair having a normal file and an inverted file.
> Steve's proposal uses a special command to tell the renderer to invert a
> subfile.
>
> These three points can be considered independently from each other.
> Requiring all files to be BFC-compliant does not require inward-facing
> primitive files. And allowing authors to switch between CW and CCW does
> not mean that we have to allow some files to go uncertified. So we can
> pick and choose which options we want.
>
> Both proposals are alike in that the renderer would have to check the
> transformation matrix on subfile commands, and flip the CW/CCW check if
> the transformation matrix has a negative determinant.
>
> The proposals are also alike in that inward-facing subfiles need special
> handling.
>
> One thing John didn't mention is how to handle decorations so they show
> through transparent surfaces from the backside. Normally, all faces on
> the backside of an object are culled out, but decorations should be
> drawn anyway. This can be gotten around by simply doubling the
> decoration-faces, and reversing the winding on one set. So this isn't a
> *big* deal.
>
> My thought (this shouldn't be a surprise to anyone) is the BFC standard
> should cater to file authors: it should restrict their actions as little
> as possible, and *require* as little as possible from them. We're all
> volunteers here, and being told what we *must* do is no fun. The BFC
> requirements will not deter the truly profilic parts authors. But it
> does raise the learning curve for new authors, which could prevent us
> from attracting new people.
>
> One thing that John's proposal does not provide for is doing
> BFC-processing on files outside of the official LDraw library. I have
> two problems with that:
>
> a. The renderer has to look at the source of each file (after the file
> is located), and determine whether or not to allow BFC-ing. Besides
> slowing the renderer down, this *forces* the renderer to differentiate
> between files based on location. Currently, it doesn't matter where a
> file is located when it's rendered, it's just a file like any other dat
> file.
> b. There's no way for people to use BFC-ing on models, or unofficial
> parts. This could make it harder to test new files, among other things.
These are both very good criticisms of my proposal--so I'll just modify my
proposal :) If we fix all the official parts, then the renderer doesn't
really have to check where a file comes from. As long as the renderer flips
the expected CW/CCW-ness every time it finds an inverted matrix, any file
using only official parts can be correctly BFC'd.
Unofficial parts (and primitives) do provide a greater challenge to this than
I preveiously considered. Most of the time you find primitives in a model
file it's due to inlining an unofficial part in order to share the file with
others. For this problem I would offer two solutions. First, unofficial
parts can be "fixed" just like official parts if we have a handy program for
doing it. The second (weaker) solution would be just to disable BFC'ing in
the rendering program.
> On to specifics...
>
> In lugnet.cad.dev, John VanZwieten wrote:
>
> > Leonardo Zide <leonardo@centroin.com.br> wrote in message
> > news:38EB3EB8.D81D2CD7@centroin.com.br...
> > >
> > > 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.
> >
> > Hey, this idea might work in conjuction with your program that fixes • parts.
> > If we had a parallel directory (/pi/?) with a copy of each primitive with • the
> > winding opposite, then whenever the fixer program finds a primitive which
> > needs to be inverted, it could just add "pi/" to the primitive name in • that
> > line.
>
> Question #1: how does the program know that a primitive needs to be
> inverted?
If the faces of a primitive have the wrong winding (i.e. the inner box5's)
then the alternate primitive would be substituted. A smarter program could
detect which primitives could be fixed by inverting the matrix and rotating
the primitive back into place. Then only non-symetrical primitives would
need to be substituted.
>
> Question #2: why is adding "pi\" preferable to substituting a different
> file name (so the inverted primitives are in the p\ directory) or
> inserting a 0 INVERTNEXT statement?
The only reason for pi\ would be to avoid confusing part authors with
something like 1-4cysbi.dat. Whatever is the easiest way of distinguishing
the inverted primitives is fine with me. The difference between substituting
a different filename and using 0 INVERTNEXT is that using my proposal a
rendering engine would not have to be looking for and dealing with
meta-commands.
> > Part authors wouldn't have to mess with this; it would all be done in
> > the post-processing stage.
>
> You've read my viewpoint on a "post-processing stage".
And I'm quite sympathetic to that viewpoint. As much as I dislike the idea
of putting additional strain on part authors, it seems better than putting
all the strain on one person to post-process. As I mentioned elsewhere, I
don't think my proposal works if part authors have to spend a lot of time
fixing their parts.
> > So here's my suggestion for a simplified BFC regime:
> >
> > 1. We handle BFC certification at the parts level (/parts directory), and
> > fix all the parts at "once." New parts would be fixed before they are
> > released. By "fixed," I mean that all outward faces are wound CW, and a
> > second set of primitives are used to model "inner" faces. Cases of
> > double-sided quads would have to be ferreted out and fixed.
>
> Double-sided meaning decorations/patterns, or double-sided meaning one
> polygon is used with both front and back being surfaces of the part?
I meant double sided meaning one polygon is used with both front and back
being surfaces of the part. The pattern problem only surfaces with
transparent parts, right? Should transparent parts be BFC'd at all?
> > It seems to me that Leonardo's program is up to this task, perhaps with a
> > little improvement.
>
> Have you used Leonardo's program? I've heard of some different programs
> that can help with sorting polygons, but I haven't heard of anyone
> publishing one yet...
No, I haven't used it, but I hope to soon. I was basing my statement on his
remarks and the output he showed us.
> > 2. If the rendering program can assume that all parts are correctly CW, • then
> > it doesn't have to waste time checking for certification, winding • direction,
> > BFC on/off, etc.
>
> How much of a 'waste' is all that? Those kind of checks can be
> optimized (the pseudo-code in the bfcspecv4.txt file should not be
> viewed as a good design for optimal performance).
Programmers will have to handle this one. My impression from Michael is that
each additional check slows things down enough to add up over a model-sized
file.
> > If a part is used in a model file with an inverted matrix,
> > then that part must be CCW, and the rendering engine can account for that.
>
> Which is one slight step away from allowing the author to flip the
> CW/CCW flag directly.
>
> > As Michael pointed out, primitives, quads, etc. used in a model cannot be
> > BFC'd.
>
> If the model file is BFC-compliant, then anything in the file should be
> able to be BFC'd. If an author is coding primitives directly into a
> model file, they know enough that they can deal with the BFC issues.
Except in the case of inlining unofficial parts, as I mentioned before.
> > Likewise, mock-ups need to be kept out of the /parts directory so
> > they won't be BFC'd either.
>
> *All* unofficial parts need to be kept out of the \parts directory. I
> consider this a serious weakness, considering the number of mockups and
> unofficial parts floating around.
>
> > So what do you think? Can this be done? Are there contingencies not
> > accounted for here?
>
> Yes, technically, it can be done. I think the dual burden of (a)
> cleaning up all 1624 existing files and (b) requiring all new files to
> be BFC-compliant is too much. But that is an opinion, as is the
> opposing opinion.
You may well have the more correct opinion here. I guess I'd just like to
see the option explored a little further before it is abandoned. Given your
experience with part creation, programming, and now part releasing, I'll
ultimately support whatever way you decide to go on this.
-John Van
|
|
Message has 1 Reply:
 | | Re: Some Words To BFC
|
| (...) OK, here's a counter-proposal: don't require all parts/primitives to be BFC'able, and allow both BFC-ready and BFC-not-ready files in the same rendering. This reintroduces the concept of having a single meta-statement at the start of each (...) (25 years ago, 7-Apr-00, to lugnet.cad.dev)
|
Message is in Reply To:
| | Re: Some Words To BFC
|
| OK. I've thought about most of John's posting, and I think I'm ready to make an intelligible response. Just to be sure I caught everything, here's a (hopefully quick) re-iteration. The major differences between John's proposal and the proposal I (...) (25 years ago, 6-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
|
|
|
|
