| |
Jacob Sparre Andersen wrote...
> [ Still discussing
> http://www.geocities.com/SouthBeach/Lagoon/8641/bfcspecv4.txt ]
>
> Steve:
(snip)
> > Second question: why did we decide that matrix-inversions were evil? I remember
> > being thick-headed about seeing the problem, but now I don't remember what the
> > problem is.
>
> One problem is that it can be difficult to see if a matrix
> has negative determinant.
Why? Are you thinking about
1 16 -4 0 0 0 0 0 0 0 4 1-4disc.dat
The determinant is zero, which BTW causes POVRay to halt
("singular matrix"). L3P has to fix these matrices or POVRay
would not render many parts at all!
As part of certifying a DAT file I believe this kind of subfile
reference should be fixed as well, like into
1 16 -4 0 0 0 1 0 0 0 4 1-4disc.dat
"L3P -check -w3" will help spot the problems.
> Another one is that some of us are lazy enough to mirror our
> subfiles in stead of writing two copies.
Mirroring is not a problem. It causes a "negative determinant matrix"
which can be detected and adjusted for (by toggling winding).
So matrix-inversions are not evil.
/Lars
|
|
| |
In lugnet.cad.dev, Lars C. Hassing wrote:
> Mirroring is not a problem. It causes a "negative determinant matrix"
> which can be detected and adjusted for (by toggling winding).
> So matrix-inversions are not evil.
Matrix-inversions are not evil. But for some reason, using them to actually
invert subfiles is evil (as opposed to using INVERTNEXT to invert subfiles).
If I reallly needed an answer to this, I'd go read past messages. But I *do*
remember:
a) I originally thought INVERTNEXT was redundant, because inversions could be
handled by inverting matrices.
b) I was later convinced that INVERTNEXT was needed.
I don't remember *why* INVERTNEXT is needed. But I am sure it is needed.
Steve
|
|
| |
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.
|
|
| |
> > Mirroring is not a problem. It causes a "negative determinant matrix"
> > which can be detected and adjusted for (by toggling winding).
> > So matrix-inversions are not evil.
>
> Matrix-inversions are not evil. But for some reason, using them to actually
> invert subfiles is evil (as opposed to using INVERTNEXT to invert subfiles).
>
> If I reallly needed an answer to this, I'd go read past messages. But I *do*
> remember:
>
> a) I originally thought INVERTNEXT was redundant, because inversions could be
> handled by inverting matrices.
> b) I was later convinced that INVERTNEXT was needed.
>
> I don't remember *why* INVERTNEXT is needed. But I am sure it is needed.
I do, it's because of those cases like an hollow cylindir DAT file is
referenced by another DAT file. Since the cylinder is supposed to be
define outwards, but you can use it to make the inside/outside of a stud
(for example) and the if the renderer corrected the inverted matrix, it
will clip the inside cylinder since it would seam to be facing outwards.
Actually this is needed for backwards compatibility, and expecially
because of our laziness in doing the correct editing, and NOT mirroring
things.
Another fact is that INVERTNEXT is NOT to correct for the Matrix with
negative determinant, but for the lego cad builder to inform the renderer,
I want to use this particular DAT file inverted (NOT MIRRORED) i.e. Every
face which was facing outwards will now considered to be facing inwards,
and viceversa, and upwards has downwards and viceversa.
Actually what we are saying is:
"now all the unclipable polygons will be clippable, and viceversa"
But all this has been debated too many times, and a long time ago already,
so make up your minds.
Either we support the INVERTNEXT to support our laziness, or we don't, and
we will have to have 2 versions of the DAT files we eventually would like
to use inverted (inside-out).
See ya.
Rui Martins
|
|
| |
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
|
|
|
