 | | | | | |
Steve Bliss wrote ...
> I don't remember *why* INVERTNEXT is needed. But I am sure it is needed.
Is this a joke? You argue very well in "Inversion" in "Language Extension
Functionality" about the 3D tube ;-)
/Lars
Sorry if I missed a pun.
| | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev, Lars C. Hassing wrote:
> Steve Bliss wrote ...
> > I don't remember *why* INVERTNEXT is needed. But I am sure it is needed.
>
> Is this a joke? You argue very well in "Inversion" in "Language Extension
> Functionality" about the 3D tube ;-)
Nope, not a joke. I seriously didn't remember the reason(s) why other
approaches wouldn't work as well as INVERTNEXT.
I poked around old messages a little bit, I think I remember better now.
Let me (attempt to) explain:
When this whole BFC discussion started, I thought the best way to invert
subfiles was to negate the orientation matrix.
Later in the discussion, it became apparent to me that using the orientation
matrix was not a workable way to deal with inversion. Other people realized
this from the start, I think.
As I remember, the only other suggested approach to inverted objects was to have
two sets of primitives; one set with normal orientation, the other set inverted.
This is actually a workable solution, but limits the power of the LDraw
language, and requires somebody to *write* all the inverterd-primitive files.
So INVERTNEXT is our best solution to the problem.
Steve
| | | | | | |
