Subject:
|
Re: Some Words To BFC
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Fri, 7 Apr 2000 17:43:48 GMT
|
Viewed:
|
2463 times
|
| |
|
|
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.
--------------------------------------------------------------------------
Near-pointer notes:
1) BTW, Michael's latest response
<http://www.lugnet.com/cad/dev/?n=4366> indicates that the 'checks' he
was concerned about are finding and correcting weird transform matrices,
not simple flag-flipping.
2) If BFC is entirely disabled, processing will go mildly faster if the
renderer doesn't even think about BFC'ing. The central control loop is
fairly small, so it might make sense to have two (or more) different
versions of it.
--------------------------------------------------------------------------
Another thought on the BFC-hood of new parts: if it is easy to prepare
parts for BFC, and authors understand the benefits of having parts be
BFC-ready,[3] then they will tend to run their parts through the LCAD
Parts Cleaner Program (hmm, LCAD PCP, that could be bad). No coercion
required. OTOH, if someone does a bang-up job on a new part, but it is
seriously BFC-challenged, we could accept the part, even if the author
won't face the BFC issues.
Flexibility is a good thing.
--------------------------------------------------------------------------
3) I think the benefits of BFC'ness will go beyond somewhat faster
renderings. One of the LDraw FAQs should be: "hey, I'm making a program
that reads DAT files, and why are all these parts messed up?"
--------------------------------------------------------------------------
> 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.
I've wondered if such a smart program is possible/likely. It *seems*
like any program would have to know a fair amount about the file being
manipulated, so it would know which operations to perform to match the
inversion. Probably this could be done by compiling a table of
reactions to inversions on any of the three axes. That wouldn't address
all possible cases, but it might help.
> > 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.
See [1] above, and my other post with details about speed problems with
either approach.
> 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.
I agree with that. Whether we're talking about one person doing the
post-processing or several, it still makes more sense for each author to
handle their own parts.
> As I mentioned elsewhere, I
> don't think my proposal works if part authors have to spend a lot of time
> fixing their parts.
And requiring new parts to be BFC'proof isn't even the major problem:
cleaning up the existing library all at once, and dealing with
unofficial parts effectively are both bigger hurdles to overcome.
> 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?
(I cannot face all the pointed puns that are wound into this
discussion!)
Whether or not transparent parts can be BFC'ed, depends on the renderer.
Some renderers (like LDraw and the LEGO Island program) use dithering to
indicate transparency, and so they only render the topmost transparent
surface. These programs can apply BFC processing to transparent parts.
Some programs render all transparent surfaces, to get layered effects.
The prevailing view is that these programs should *not* BFC transparent
surfaces, because the backsides matter, too. Sudden thought: all
surfaces occur in two's (the side facing the viewer, and the side facing
away), so it is possible to render with layering, and still do BFC'ing.
The rendering engine doesn't need that backside.
For best effects, the darkness of a transparent part depends on the
thickness of the material, not the number of surfaces the light goes
through. So these programs have to do a much more complicated analysis
than what we're ready to talk about here. Programs like this probably
*don't* do BFC at all.
> You may well have the more correct opinion here.
... or, I'm more wrong. It's very likely that it's one or the other ...
;)
> I guess I'd just like to
> see the option explored a little further before it is abandoned.
Sounds like a good idea.
> Given your
> experience with part creation, programming, and now part releasing, I'll
> ultimately support whatever way you decide to go on this.
You've got a fair amount of parts-experience yourself. Your name is on
more part files than any other parts-author. And let's wait until after
we get through the next vote/release cycle before I claim any special
knowledge or experience in that area. I'm more than willing to say that
my respect for Terry Keller and his contribution to LCAD increases more
and more every day.
Steve
|
|
Message has 1 Reply:
 | | Re: Some Words To BFC [DAT]
|
| Steve Bliss <blisses@worldnet.att.net> wrote in message news:dq3sesgb6vsh8kd...4ax.com... (...) flips (...) than (...) with (...) for (...) in (...) This makes a lot of sense to me. You are right, checking one flag per part file should not take too (...) (25 years ago, 10-Apr-00, to lugnet.cad.dev)
|
Message is in Reply To:
| | 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)
|
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
|
|
|
|
