Special:
|
[DAT] (requires LDraw-compatible viewer)
|
Subject:
|
Re: Some Words To BFC
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Mon, 10 Apr 2000 22:13:33 GMT
|
Viewed:
|
1113 times
|
| |
|
|
Steve Bliss <blisses@worldnet.att.net> wrote in message
news:dq3sesgb6vsh8kdp1i6bnmkcjn6jto5f55@4ax.com...
> In lugnet.cad.dev, John VanZwieten wrote:
>
> > 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.
>
> 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 file, telling the renderer whether
> the file is BFC'able or not.
>
> From what you've posted, I'm reading that you are concerned that the
> renderer not get bogged down with doing a lot of extra checking.[1]
> BUT, a certification flag is only used once per file. A fast rendering
> engine could have two different rendering-control loops: one that does
> BFC-checking, and one that doesn't.[2] The parsing routine can strip out
> the certification command while loading each file, and the rendering
> routine doesn't even have to think about the flag, except at the start
> of each file, where it will decide which control loop to use.
>
> This approach would allow people to easily use unofficial parts, without
> requiring them to deal with bad-BFC messes or penalize them by having to
> turn off BFC entirely. Also, the BFC standard wouldn't have to
> expect/depend on getting a 100% automatic and 100% reliable cleanup
> program.
This makes a lot of sense to me. You are right, checking one flag per part
file should not take too much processor time, and lets us achieve benefits
incrementally as we upgrade the parts database.
The other big problem (and what seems to be Rui's main point of contention)
is the "certification tree" issue: Does a certified part have to be in a
certified model, or in a certified submodel of a certified model, etc? I've
been trying to bend my mind around this one, and here's the best I can come
up with:
1. The BFC meta-command would have two usages:
0 BFC Certified means that the file may always be BFC'd, even if it's in an
uncertified branch of another file. The only candidates for this would be
truly solid files.
0 BFC Allowed means that the file may be BFC'd only if it's in a branch off
a BFC Certified file, and the branch contains only BFC Certified or BFC
Allowed files. This would be used for primitive files and non-solid
subparts.
Here are a few trees as examples, "U"=no certification "C"=Certified
"A"=Allowed:
U - C - A : the last file does get BFC'd
U - A : the last file does not get BFC'd
U - C - U - A : the last file does not get BFC'd
U - U - A : the last file does not get BFC'd
U - C - U : the last file does not get BFC'd
U - C - U - C : the last file does get BFC'd
So a proposal based on this might look like:
1. A file is BFC-certified if and only if all its type 3 and 4 faces are CW,
and all faces of any BFC-Certified or BFC-Allowed subfiles are CW after
taking into account negative determinants.
Some examples (and I apologize for the verbosity):
1. A part file uses type 3 & 4 faces and references several primitives. In
order to certify the part BFC (1) all its type 3 and 4 faces must be CW, (2)
any BFC allowed primitives referenced must be used "properly". "Proper"
primitive use means using an "outee" 3-D primitive in cases where the outside
faces form the outside of the part, and a second set of "innee" 3-D
primitives where the inside faces form the outside of the part. 2-D
primitives should be used so the the CW side forms the outside of the part.
Since the rendering program has to reverse the expected CW-ness whenever it
encounters a negative determinant, an inverted "outee" primitive is still an
"outee" primitive.
Brick 1x1 would be:
1 16 0 24 0 6 0 0 0 -20 0 0 0 6 box5.dat (box5 would have to be fixed
before it is certified, of course)
4 16 10 24 10 6 24 6 -6 24 6 -10 24 10
4 16 -10 24 10 -6 24 6 -6 24 -6 -10 24 -10
4 16 -10 24 -10 -6 24 -6 6 24 -6 10 24 -10
4 16 10 24 -10 6 24 -6 6 24 6 10 24 10
1 16 0 24 0 10 0 0 0 -24 0 0 0 10 pi/box5.dat
1 16 0 0 0 1 0 0 0 1 0 0 0 1 stud.dat
2. A part uses type 3 & 4 faces and references several BFC-Allowed
primitives as well as a subfile which is not BFC Certified. In this case,
the non-certified subfile would not be BFC'd, but the rest of the part would
be. Of course the 3&4 faces and primitives would have to be in good form.
This could be a way of handling transparent decorated parts. The decoration
could be placed in a non-certified subfile. Another (simpler) alternative is
just to not certify decorated parts.
3. A model file uses a mix of certified and uncertified parts, and the
author "cheated" by inverting some certified wing parts. If BFC is enabled
by the renderer, any certified parts get BFC'd, while other parts don't. The
renderer reverses the expected CW-ness for the inverted certified parts, so
they still get BFC'd correctly. There is no need to "certify" the model file
in order to enable BFC on the parts.
4. A model file uses a mix of certified and uncertified parts, as well as
some BFC-Allowed primitives and some type 3&4 faces. Unless the model
contains a 0 BFC Certified statement, only the certified parts will be BFC'd.
If the author of the model makes sure that all the BFC-allowed primitives and
the type 3&4 faces are used properly, he can add a 0 BFC Certified statement
to his model. The the type 3&4 faces and BFC-Allowed primitives, as well as
the certified parts, will be BFC'd. Uncertified parts would not be BFC'd
I hope I've covered all the bases with this idea. If there are contingencies
missing, feel free to point them out.
-John Van
|
|
Message has 1 Reply:
 | | Re: Some Words To BFC
|
| (...) Ooo, I like it. We'd flag which files are always "right-side-out" and which ones might be mis-inverted by legacy part-files. That doesn't break the reference-chain dependency entirely, but it does allow us to specify where it must apply, (...) (25 years ago, 11-Apr-00, to lugnet.cad.dev)
|
Message is in Reply To:
| | 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)
|
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
|
|
|
|
