Re: Bug in E3Triangle_InterpolateHit

[Roger H. <rog...@mi...>]

On Thursday, July 29, 2004, at 09:56  pm, Dair Grant wrote:

> 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.

Yes, its a sort of floating coordinate system, it does not have an 
origin
but it does have directions for its axes.



> 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.

I looked in the blue book and can see no description of the normal.
As you say, QD3D certainly transformed it by the local->world matrix
and hence so should we. We can clarify it in our own documentation
and maybe we should warn our users just in case their programs
are only happening to see the broken version, and hence will break
when we fix the broken case to be the same as the unbroken case.

I don't think many people use picking at present so I think it is best
that we fix it before it becomes more popular. If it worked properly
that might make it more popular too.



> 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?

Am I being simple in thinking that multiplying by localToWorld will do 
the trick?
Probably, the rotational component is fine but will non uniform scaling 
in
X,Y & Z and shearing mess things up? Come to think of it I think I had 
to
write some special code in my renderer for transforming normals.
I will have a look before I write any more.

OK. In my UpdatePipeline routine I calculate  a localToWorldForNormals
matrix. I set it to the localToWorld, then set the bottom row to 
0,0,0,1 and then
set it to the inverse of its transpose. A comment refers to 'Computer
Graphics principals and practice' page 1108.

So I guess that's it, but it is a heavy bit of calculation. Should we 
be doing it
when we get a 'hit' or every time we change localToWorld? I guess there
are typically not many hits, and it would be easier to put the code in 
the
existing routine. Or is this matrix calculated somewhere already?

>
> 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).

Good.

>
> 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).

OK

>
>
>> 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.
>

Oh good, I can take it out of my version of Quesa then.

> -dair
> ___________________________________________________
> mailto:dair+refnum.com       http://www.refnum.com/
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source 
> Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>