| |
In lugnet.cad.dat.parts, Tony Hafner wrote:
> In lugnet.cad.dat.parts, Orion Pobursky writes:
> > I'm concerned that if we release those primitives that can be used as both
> > inside and outside surfaces as BFC complient, we'll have to go back to all
> > the other pieces that use them to insert the INVERTNEXT directive (where
> > appropriate). Otherwise some renderers, like L3Lab, will render pieces
> > incorrectly.
>
> Is this a real issue? Parts can't be truly BFC compliant until all of their
> subparts are BFC compliant. So yes, you'll have to insert those INVERTNEXT
> commands. But the part wasn't BFC compliant before, and this is just
> another part of bringing it into compliance.
You've got it. When existing part files are made BFC-compliant, they
have to be checked through completely. The main changes are fixing
polygon wrapping and adding INVERTNEXT statements. Until a file is
labeled BFC-compliant, renderers shouldn't treat it as one.
> Or are there official parts
> out there that have BFC commands in them but are relying on non-BFC'd
> primitives?
Yes, this is true. And is something of an issue. However, it's not
hard to make 'unofficial' BFC'ed primitives. Which is what I've done
for developing and reviewing BFC parts.
> Maybe I'm way off base here, though. I am under the impression that if a
> parent file is not BFC'd, then the renderer is supposed to treat all child
> files as non-BFC'd. In other words, a part can reference all the BFC'd
> primitives in the world, but unless that part is BFC'd as well, all of the
> primitives are treated as if they weren't BFC'd.
Nope, you got it right.
Steve
|
|
Message has 2 Replies:
Message is in Reply To:
10 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
|
|
|
|
