I think you might be running into an issue with transforming vectors, and normals in particular, as opposed to positions. The 3D vector type is really a triplet because it can be used for more than just true vectors like force and velocity, but also for positions and even Euler angles or non-uniform scaling factors.
The difference between a true vector and a position is subtle and can be ignored in many situations. But in some cases the difference will jump up and bite you. Transformations and changes of ref frames are one such situation. Think of it this way. Suppose the wind (a true vector) is blowing 1 m/s to your left. As a position, that's a spot 1m to your left - let's put a pebble there to mark the spot. Now suppose that I am standing 3m to your left, and facing you. Where's the pebble? 2m in front of me. Which way is the wind blowing? 1m to my back, *not* 2m forward. So the moral is: true vectors can be scaled and rotated, but not translated. Scaling and rotation combined can be represented by 3x3 matrices, and scaling, rotation, and translation can be represented by 4x4 matrices using what is called homogeneous coordinates. ICE will let you multiply a 3D vector/triplet by a 4x4 matrix, something which you are not allowed to do in linear algebra class. Under the hood, it's treating the triplet as a position and converting it to a 4D vector with W = 1. There are two ways to get around this and force ICE to treat the triplet as a true vector: either multiply the vector by a 3x3 matrix with only scaling and rotation, or convert the 3D vector to a 4D vector with W = 0, multiply by the full 4x4 transform, and convert back. But all that is for ordinary vectors like force and velocity. Normals are a special case if there is any non-uniform scaling involved. In that case, you need to multiply by the transpose of the inverse of the object transform. (If there's no non-uniform scaling, then the object transform is equal to the transpose of the inverse of itself, so this is not an issue.) Also don't forget to turn on Use Global Coordinates for Display when showing values for debugging, or you'll go crazy trying to figure out what is wrong. gray From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Ponthieux, Joseph G. (LARC-E1A)[LITES] Sent: Tuesday, August 13, 2013 10:49 AM To: softimage@listproc.autodesk.com Subject: RE: just not normal I tried this already, but it didn't work. Rather, it works but not how I need it to work. So.... I've got two point positions, a vector is derived from these point positions. Because the positions are constantly moving the vector is changing. This vector draws correctly on screen. This vector is derived from global positions and drawing relative to world space. I'm then trying to get the normal of a surface and get the difference in angle of this vector and the previous vector. I originally attempted to get this from a location. But the surface is planar so any normal will do. The problem is that the normal, when acquired, is oriented relative to an object different than self. As a result it seems that ICE then compares it to self and reorients it relative to self. Not sure why. The values are technically correct when looking at everything in local space. But I want the value to be relative to world space. I tried using the technique you suggested for both the object and self's matrix, and neither produce the correct results. I did however solve the problem by manually creating a normal from a cross product of vectors derived from surface points that were converted to global space and this works perfectly. I think the wrench in the comparison is the original derivation of the vector from raw global point positions. This seems to have the effect of providing a vector which is non-relative to anything but global space. Whereas the normal just can't seem to be unassociated with either the object it was derived from or self. If that makes any sense. Thanks -- Joey Ponthieux LaRC Information Technology Enhanced Services (LITES) Mymic Technical Services NASA Langley Research Center __________________________________________________ Opinions stated here-in are strictly those of the author and do not represent the opinions of NASA or any other party. From: softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com> [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Alan Fregtman Sent: Tuesday, August 13, 2013 9:49 AM To: XSI Mailing List Subject: Re: just not normal Absolutely possible. What you're experiencing is that self.PointNormal (and I think maybe all or most preexisting iceattributes) are in the object's local space always. If you get a "Multiply vector by matrix" node and feed it your self.PointNormal and a getdata of self.kine.global into the matrix, you should be getting stuff in Global space. Beware that some of the ICE visual debugging when it comes to per-point data can appear to come from the points when that may not be the case, just because it usually draws the vector starting from the point origin when it's a per-point context. You can Build Array From Set from your attribute and visually debug the result, as it will be one big array per object instead of one value per point, and thus won't try to draw it starting from each point. On Tue, Aug 13, 2013 at 9:38 AM, Ponthieux, Joseph G. (LARC-E1A)[LITES] <j.ponthi...@nasa.gov<mailto:j.ponthi...@nasa.gov>> wrote: Howdy, I'm trying to get a vector which is the normal of a surface relative to world space, not local space. The object is moving. I managed to get the vector using both PointNormal and SurfaceGeometricNormal. Sometimes the calculations work and sometimes they don't. It appears when I display the vectors that normal is being reoriented relative to the self object(the object that the ICE tree is on). So from a global perspective the angle is wrong. Its being compared to a normal which is generated from the point position of two objects. What I need is the normal direction of the surface or point on the point relative to world space. Is that possible? -- Joey Ponthieux LaRC Information Technology Enhanced Services (LITES) Mymic Technical Services NASA Langley Research Center __________________________________________________ Opinions stated here-in are strictly those of the author and do not represent the opinions of NASA or any other party.
<<attachment: winmail.dat>>
