| |
In lugnet.cad.dev, Lars C. Hassing wrote:
> Steve Bliss wrote...
> > Double-sided sections won't be very rare. They'll be needed for all decorated
> > parts.
>
> Huh? please explain why.
Sometimes, transparent parts have decorative printing. And the LDraw library
should be written so that modelers can use any part in any color, even if LEGO
hasn't released that part/color combination yet.
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.
> Sorry, I didn't make myself clear. I am NOT going to begin clipping
> non-BFC parts. It is of course not possible. But I WOULD like to clip
> BFC parts, even if the superfiles are not certified, i.e. let old
> model files (=non-BFC files) benefit from BFC-parts.
> See also last 5 paragraphs of http://www.lugnet.com/cad/dev/?n=3084
> and http://www.lugnet.com/cad/dev/?n=3102
Ahhh. "Model-files don't invert part-files". That's the key. I'll add that
paragraph back to the V4 document (which is now on V7, I think). But I'll
rewrite the paragraph to make it clear that the assumption is that model files
would not invert part files, not that "part files are right-side out" (I know,
they're really the same thing, but the wording is crucial IMO). And the part
files *must* be certified to be clipped.
OK, I've inserted the following text into the V4 document:
7 Assumed inversions. Generally, it is not possible to assume that a subfile
7 is inverted or normal (which is the reason for the 0 BFC INVERTNEXT meta-
7 statement). One important special case is this: model files do not invert
7 part files. Parts are complex files which would be essentially useless if
7 they were inverted. Assuming that all part files used in a rendering allows
7 the rendering engine to apply BFC-processing on these parts (assuming the
7 parts are certified).
7
7 No assumptions can be made about models which make direct use of primitives
7 or polygon commands, so a rendering engine should not simply treat uncertified
7 model files as certified.
> "All DAT files are equal, but some are more equal than others" :-)
:-)
> > > > 4 RenderFile Command.Subfile,
> > > > 4 (AccumClip and LocalClip and Certified),
> > > > 4 (AccumInvert xor InvertNext)
> > > TransformMatrix * Command.TransformMatrix
> > >
> > > TransformMatrix could be renamed to AccumTransformMatrix like the other
> > > parameters to RenderFile.
>
> You added AccumTransformMatrix as a parameter to RenderFile but forgot the
> AccumTransformMatrix * Command.TransformMatrix in the two calls to RenderFile.
Hmm, good point.
> Actually the color should also be a parameter to RenderFile. A transparent
> file cannot be clipped. If you add
> Color integer // current color
>
> as a parameter, then you can add this before "OpenFile(ModelFile)":
> If 32 <= Color And Color <= 47 Then AccumClip = FALSE
>
> and this after "Get Next Command":
> If Command.Color = 16 Then
> Command.Color = Color
> Else
> If Command.Color = 24 Then
> Command.Color = EdgeColor(CurColor)
>
> and add Command.Color in the two calls to RenderFile.
> Feel free to rename/recode, I hope you get the idea.
Got it. The last bit is straying away from strict BFC-relevance (the colors 16
and 24), but I guess I can throw it in...
> I wouldn't worry too much about programmers though, it's pretty easy and
> you have alreay provided pseudo-code.
Attempting to be as clear as possible, I added this paragraph before the
pseudo-code:
7 The function BFC() returns a boolean value, indicating whether a polygon
7 should be rendered or culled. As the nature of this routine does not
7 impact the BFC standard, the logic for BFC() is not included in the following
7 pseudo-code. There is information about BFC processing available from many
7 locations, including <http://www.lugnet.com/cad/dev/>.
Steve
|
|
| |
Steve Bliss wrote in message ...
> In lugnet.cad.dev, Lars C. Hassing wrote:
>
> > Steve Bliss wrote...
> > > Double-sided sections won't be very rare. They'll be needed for all decorated
> > > parts.
> >
> > Huh? please explain why.
>
> Sometimes, transparent parts have decorative printing. And the LDraw library
> should be written so that modelers can use any part in any color, even if LEGO
> hasn't released that part/color combination yet.
>
> 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.
Frankly I can't think of any situations where double-sided sections are
*really* necessary, since all parts have a volume, because they are molded
in plastic.
However, two places where double-sided sections could be useful:
1) John Van mentioned a "stair-step-like part, where a single quad could
be used as the top of one step and the bottom of the next step up".
IMO this is bad modeling, as the part would look strange in transparent
and it may not necessarily speed up rendering having a large quad
rather than two small quads.
2) Stickers and flags. As a shortcut they *could* be modeled as thin objects.
> 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? Well, in that case we do need
double-sided sections for decorations!
> > Sorry, I didn't make myself clear. I am NOT going to begin clipping
> > non-BFC parts. It is of course not possible. But I WOULD like to clip
> > BFC parts, even if the superfiles are not certified, i.e. let old
> > model files (=non-BFC files) benefit from BFC-parts.
>
> > See also last 5 paragraphs of http://www.lugnet.com/cad/dev/?n=3084
> > and http://www.lugnet.com/cad/dev/?n=3102
>
> Ahhh. "Model-files don't invert part-files". That's the key. I'll add that
> paragraph back to the V4 document (which is now on V7, I think). But I'll
> rewrite the paragraph to make it clear that the assumption is that model files
> would not invert part files, not that "part files are right-side out" (I know,
> they're really the same thing, but the wording is crucial IMO). And the part
> files *must* be certified to be clipped.
Yeah, that was the expression I was looking for ;-)
In Danish we have a noun (vrang) meaning "wrong side" or "reverse side".
I can't seem to find a similar English noun.
It is important to state that "inversion" in this discussion means
"turning inside out" or "turning the wrong side out" and not mirroring.
> 7 they were inverted. Assuming that all part files used in a rendering allows
Don't you need a comma?
8 they were inverted. Assuming that, all part files used in a rendering allows
> > > > > 4 RenderFile Command.Subfile,
> > > > > 4 (AccumClip and LocalClip and Certified),
> > > > > 4 (AccumInvert xor InvertNext)
> > > > TransformMatrix * Command.TransformMatrix
> > > >
> > > > TransformMatrix could be renamed to AccumTransformMatrix like the other
> > > > parameters to RenderFile.
> >
> > You added AccumTransformMatrix as a parameter to RenderFile but forgot the
> > AccumTransformMatrix * Command.TransformMatrix in the two calls to RenderFile.
>
> Hmm, good point.
Yes, I really think you should consider updating the document :-)
> > Actually the color should also be a parameter to RenderFile. A transparent
> > file cannot be clipped. If you add
> > Color integer // current color
> >
> > as a parameter, then you can add this before "OpenFile(ModelFile)":
> > If 32 <= Color And Color <= 47 Then AccumClip = FALSE
> >
> > and this after "Get Next Command":
> > If Command.Color = 16 Then
> > Command.Color = Color
> > Else
> > If Command.Color = 24 Then
> > Command.Color = EdgeColor(CurColor)
> >
> > and add Command.Color in the two calls to RenderFile.
> > Feel free to rename/recode, I hope you get the idea.
>
> Got it. The last bit is straying away from strict BFC-relevance (the colors 16
> and 24), but I guess I can throw it in...
You're right that the last bit is not BFC relevant, you may remove it again.
It also contains a typo (CurColor) :-)
> > If 32 <= Color And Color <= 47 Then AccumClip = FALSE
Actually LDLite and MLCad uses 63 in stead of 47.
/Lars
|
|
| |
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.
So it's not the transparent *part-file* which can't be BFC'ed, but the
transparent polygons.
Argh. I'll update the pseudo-code.
> Frankly I can't think of any situations where double-sided sections are
> *really* necessary, since all parts have a volume, because they are molded
> in plastic.
>
> However, two places where double-sided sections could be useful:
> 1) John Van mentioned a "stair-step-like part, where a single quad could
> be used as the top of one step and the bottom of the next step up".
> IMO this is bad modeling, as the part would look strange in transparent
> and it may not necessarily speed up rendering having a large quad
> rather than two small quads.
I agree with you on this. It's an unnecessary shortcut for the author.
> 2) Stickers and flags. As a shortcut they *could* be modeled as thin objects.
> > 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. :)
But, we need this anyway. Without worrying about the details, think about the
basic logic: in some cases, the backside of decorations can appear in
renderings. And, as I pointed out above, the logic of disabling BFC clipping
for transparent parts is flawed.
> Yeah, that was the expression I was looking for ;-)
>
> 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?
> It is important to state that "inversion" in this discussion means
> "turning inside out" or "turning the wrong side out" and not mirroring.
Good point.
> > 7 they were inverted. Assuming that all part files used in a rendering allows
> Don't you need a comma?
> 8 they were inverted. Assuming that, all part files used in a rendering allows
No, I need a brain-check. I think this wording is slightly more clear:
8 they were inverted. Assuming part files are never inverted allows
8 the rendering engine to apply BFC-processing on all certified part-files,
8 even if the model file(s) are not BFC-certified.
> > > > > > 4 RenderFile Command.Subfile,
> > > > > > 4 (AccumClip and LocalClip and Certified),
> > > > > > 4 (AccumInvert xor InvertNext)
> > > > > TransformMatrix * Command.TransformMatrix
> > > > >
> > > > > TransformMatrix could be renamed to AccumTransformMatrix like the other
> > > > > parameters to RenderFile.
> > >
> > > You added AccumTransformMatrix as a parameter to RenderFile but forgot the
> > > AccumTransformMatrix * Command.TransformMatrix in the two calls to RenderFile.
> >
> > Hmm, good point.
>
> Yes, I really think you should consider updating the document :-)
:p. It's there now, along with the following in the Declare section:
8 Command DATCommandLine // Structure containing parameters from a single
8 // DAT command-line.
> > > Actually the color should also be a parameter to RenderFile. A transparent
> > > file cannot be clipped. If you add
> > > Color integer // current color
> > >
> > > as a parameter, then you can add this before "OpenFile(ModelFile)":
> > > If 32 <= Color And Color <= 47 Then AccumClip = FALSE
I'm going to have to drop that bit again. That test actually belongs in the
(undocumented) BFC() function.
Anybody want to write pseudo-code for BFC(), including both the tests that are
specific to the LDraw BFC Standard, and the general approach to BFC'ing?
> > > and this after "Get Next Command":
> > > If Command.Color = 16 Then
> > > Command.Color = Color
> > > Else
> > > If Command.Color = 24 Then
> > > Command.Color = EdgeColor(CurColor)
> > >
> > > and add Command.Color in the two calls to RenderFile.
> > > Feel free to rename/recode, I hope you get the idea.
> >
> > Got it. The last bit is straying away from strict BFC-relevance (the colors 16
> > and 24), but I guess I can throw it in...
>
> You're right that the last bit is not BFC relevant, you may remove it again.
Gee, thanks. ;) It's too late, it's in now, so it's going to stay.
Steve
|
|
| |
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
|
|
|
