Subject:
|
Re: Some Words To BFC
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Thu, 6 Apr 2000 06:16:20 GMT
|
Viewed:
|
2235 times
|
| |
|
|
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.
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?
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?
> 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".
> 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?
> 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...
> 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).
> 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.
> 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.
> P.S. Please note that I am not in any way "dissing" all the work put into
> the BFC proposal. Without it, Michael probably wouldn't have implemented
> BFC, and we still be talking only theoretical.
You do realize that every point you've made has been discussed
previously, right?
> I simply think that given
> what we found in MLCad
What did we find in MLCad? I've seen little discussion of it here,
except for Michael's message.
> and given the impressive fixer programs we now have to
> work with, this way seems to offer the greatest potential improvement and the
> least complexity.
I still haven't seen these programs...
Steve
|
|
Message has 2 Replies:
 | | Re: Some Words To BFC
|
| (...) When it finds that any face of a primitive needs to be inverted. We would have to fix the current primitives so that all faces are pointing to the same direction. Take a look at the sphere primitive for example, it has faces pointing inside (...) (25 years ago, 6-Apr-00, to lugnet.cad.dev)
| | | Re: Some Words To BFC
|
| Steve Bliss <blisses@worldnet.att.net> wrote in message news:i86oessafp98dp6...4ax.com... (...) 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 (...) (25 years ago, 6-Apr-00, to lugnet.cad.dev)
|
Message is in Reply To:
| | Re: Some Words To BFC
|
| Leonardo Zide <leonardo@centroin.com.br> wrote in message news:38EB3EB8.D81D2C....com.br... (...) here, (...) 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 (...) (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
|
|
|
|
