Subject:
|
Re: Line in the Sand
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Fri, 10 Dec 1999 20:21:14 GMT
|
Viewed:
|
2848 times
|
| |
|
|
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
|
|
Message has 1 Reply:
 | | Re: Line in the Sand
|
| Steve Bliss 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 (...) (25 years ago, 14-Dec-99, to lugnet.cad.dev)
|
Message is in Reply To:
| | Re: Line in the Sand
|
| Steve Bliss wrote in message ... (...) 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 (...) (25 years ago, 10-Dec-99, to lugnet.cad.dev)
|
85 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
|
|
|
|
