 | | | | | | |
| |
|
Steve Bliss wrote...
> In lugnet.cad.dev, Lars C. Hassing wrote:
>
> > Steve Bliss wrote in message ...
> > > Decorations on transparent parts shows through when looking at the part from
> > > behind. If the decoration polygons were put through the BFC-check, they would
> > > be clipped in this situation, because the decoration is facing away from the
> > > viewer.
> >
> > Remember BFC must be disabled for transparent parts. That's what
> > If 32 <= Color And Color <= 47 Then AccumClip = FALSE
> > takes care of.
>
> Hmm. that makes me wonder if the logic of turning of BFC clipping when a part's
> color is transparent will really work. Because a part may have the main color
> as 16, and some sections are hard-coded to a transparent color. In this case,
> the suggested logic would fail to cull correctly.
If IsTransparent(Color) Then AccumClip = FALSE
takes care of solid non-16 colors (decorations) in parts used transparently.
And a similar check added to BFC() can take care of transparent non-16
colors in parts used as solids.
So the logic is OK again.
> > > 7 If 32 <= Color And Color <= 47 Then // This restriction may or may not be
> > > 7 AccumClip = FALSE // required, depending on the style of
> > > 7 End If // rendering for transparent surfaces.
> >
> > What do you mean with the comment?
> > That dither-transparency can use BFC?
>
> That is correct.
>
> > Well, in that case we do need
> > double-sided sections for decorations!
>
> That's what I was thinking. :)
On second thoughts I don't think we need double-sided sections for decorations.
If a rendering program wishes to use BFC together with dither-transparency, it
can easily investigate whether there are non-16 colors in a transparent part.
We should not put an unnecessary rule on the part author.
> > In Danish we have a noun (vrang) meaning "wrong side" or "reverse side".
> > I can't seem to find a similar English noun.
>
> Do you mean inside-out or back?
I mean the inner surface. Like the "internal surface" of a sweater or a stocking.
If you don't have a similar noun/substantive/notion in English I can understand
why the subject is difficult to discuss, because we think/conceive differently
(as our spoken languages reflect) about the "inside surface".
/Lars
| | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev, Lars C. Hassing wrote:
> If IsTransparent(Color) Then AccumClip = FALSE
> takes care of solid non-16 colors (decorations) in parts used transparently.
> And a similar check added to BFC() can take care of transparent non-16
> colors in parts used as solids.
> So the logic is OK again.
Yes, it would render correctly, but it would also disable clipping more often
than is required, in the case of mixed solid and transparent sections. Think of
a submodel where the author used color 16, and the person using the submodel
renders it as transparent. If clipping is turned off at the start of the
submodel, then no part in that submodel could be BFC-ed, even if they were
solid-colored.
> On second thoughts I don't think we need double-sided sections for decorations.
> If a rendering program wishes to use BFC together with dither-transparency, it
> can easily investigate whether there are non-16 colors in a transparent part.
>
> We should not put an unnecessary rule on the part author.
I agree with not putting unnecessary rules on authors. I don't agree on
renderers being required to find the solid colors in a transparent part.
> I mean the inner surface. Like the "internal surface" of a sweater or a stocking.
> If you don't have a similar noun/substantive/notion in English I can understand
> why the subject is difficult to discuss, because we think/conceive differently
> (as our spoken languages reflect) about the "inside surface".
"inner surface" is as good as it gets. Or "inside" or "interior". But those
two also refer to the contained volume, not the actual surface.
Steve
| | | | | | | | | | | | | | | | | |
| |
|
Steve Bliss wrote...
> In lugnet.cad.dev, Lars C. Hassing wrote:
>
> > If IsTransparent(Color) Then AccumClip = FALSE
> > takes care of solid non-16 colors (decorations) in parts used transparently.
> > And a similar check added to BFC() can take care of transparent non-16
> > colors in parts used as solids.
> > So the logic is OK again.
>
> Yes, it would render correctly, but it would also disable clipping more often
> than is required, in the case of mixed solid and transparent sections. Think of
> a submodel where the author used color 16, and the person using the submodel
> renders it as transparent. If clipping is turned off at the start of the
> submodel, then no part in that submodel could be BFC-ed, even if they were
> solid-colored.
I think this is a possible, but rare case. It can, however, be circumvented by
regarding DAT files from PARTS as special.
> > On second thoughts I don't think we need double-sided sections for decorations.
> > If a rendering program wishes to use BFC together with dither-transparency, it
> > can easily investigate whether there are non-16 colors in a transparent part.
> >
> > We should not put an unnecessary rule on the part author.
>
> I agree with not putting unnecessary rules on authors. I don't agree on
> renderers being required to find the solid colors in a transparent part.
Why not? Any information you can gather by simply analysing a DAT file
should not be required to be stated by the part author.
/Lars
| | | | | | | | | | | | | | | | |
In lugnet.cad.dev, Lars C. Hassing wrote:
> Why not? Any information you can gather by simply analysing a DAT file
> should not be required to be stated by the part author.
In that case, why are we wiggling about with this BFC extension stuff?
Rendering programs can figure out what order vertices should be put in, and they
can figure out which way a polygon is facing. They don't need all this extra
effort from us and parts authors.
Steve
| | | | | | | | | | | | | | | | |
Steve Bliss wrote...
> In lugnet.cad.dev, Lars C. Hassing wrote:
>
> > Why not? Any information you can gather by simply analysing a DAT file
> > should not be required to be stated by the part author.
>
> In that case, why are we wiggling about with this BFC extension stuff?
> Rendering programs can figure out what order vertices should be put in, and they
> can figure out which way a polygon is facing. They don't need all this extra
> effort from us and parts authors.
:-)
Jean-Pierre's analyzer is not a "simple analysis" and may not work 100% correctly
without human intervention.
/Lars
| | | | | | |
