Re: Bug in E3Triangle_InterpolateHit

[Dair G. <da...@re...>]

Roger Holmes wrote:

>There is a bug in E3Triangle_InterpolateHit when it is asked to return
>a normal vector.
>
>It should return a normal in world coordinates, and if there are no
>normals in the attribute set of the surface, nor in the attribute sets
>of the vertices then all is well.

A normal is a vector, so it doesn't have a coordinate system as such.
But I see what you mean, the normal is from the surface before it was
transformed to world coordinates or after the transform.


The docs for QD3D say the result here is:

    The surface normal of the picked object at the point of
    intersection with the pick geometry.

Are the docs incorrect? I.e., what happened under QD3D was actually:

    ...with the pick geometry, transformed by the local->world matrix.

At the moment we do have a problem in that we're being inconsistent
(we're returning the supplied normal as-is if it exists, but will
calculate a normal from a transformed triangle if not), but which is the
correct way to adjust the results?

Should the normal always be of the surface in its own coordinate system,
or taken after the surface has been transformed?

The surface point is always returned in world coordinates, so it does
sound plausible that the normal should be from the transformed surface
too.


>I have fixed this in my version of Quesa by passing the view into
>E3Triangle_InterpolateHit and then calling Q3Vector3D_Transform where
>appropriate. I also have to include E3View.h in E3Utils.c so I can get
>the transform using E3View_State_GetLocalToWorld.
>
>Is this OK? Should I pass in the matrix instead? Should it return a
>flag to say if the normal is in world or local coordinates and then
>fix it in the calling code (2 places)? Should it pick it up in some
>other way?

Best approach would be to pass in the view I think, as that's also
passed in to the next routine in line (E3Pick_RecordHit as it also needs
to record the local->world matrix if the caller wants that info back).

I wouldn't try and stash an extra flag somewhere, we should just mandate
that the normal that comes out of here is consistent with the thing that
E3Pick_RecordHit will save for the app (so either before or after the
transform, but always the same, depending on what QD3D did).


>Also, when the normal is calculated from three vertex normals, it can
>result in a normal which is not normalised. Is there any good reason
>for this or can I normalise it?

The normal is normalised by e3pick_hit_initialise - we defer doing the
normalisation until we know that the caller really does want that bit of
info back.


-dair
___________________________________________________
mailto:dair+refnum.com       http://www.refnum.com/