Just as ICE will give you position and vector values local to the self's ref frame when getting data at locations, it assumes that the input positions and vectors for geometry queries like Point in Volume or Raycast are local to the self.
That's why it worked like that when there was no input - the default value (0, 0, 0) was interpreted relative to self, not the world. So if a value is in global coordinates, you'll need it to the self's ref frame. If it's in another object's ref frame, you'll need to convert it to global first, and then to local self. gray From: [email protected] [mailto:[email protected]] On Behalf Of Ponthieux, Joseph G. (LARC-E1A)[LITES] Sent: Friday, August 16, 2013 11:38 AM To: [email protected] Subject: Goemetry Peculia-Queries I've got a question regarding geometry queries. Specifically regarding Point In Volume but the same question applies to Get Closest Location as well. What I have discovered with Point in Volume is: a. I have a cube and a null. The ice tree is on the null. b. If I query a simple volume using the cube as volume to be detected, but connect nothing to the position input, everything works as expected. Position is assumed from self(the null) and computes accurately relative to self. c. If I apply an external position input from either self or a different object, the calculation appears to be incorrect. d. If I use the global position of self the volume is detected halfway into the volume. This would technical represent ΒΌ of the volume where detection is active. I am aware using self as position is redundant since it already operates on self, but it serves as a useful comparison to illustrate that things don't evaluate as expected. e. If I use the global position of a third object, and self is at a position which is non-zero, then detection occurs in the opposite offset of self's position. Volume is detection is accurate by volume, though offset in space, so while it detects the correct amount of volume, its not in the right place relative the cube. Now I realize I can negate the offset in example E by subtracting self's global position from the third objects global position and volume detection operates as expected. I also realize I can correct the difference in example D by multiplying self's global position by 2, multiplying that vector by the cubes matrix, then adding the cube's global position to that. I'm not looking for an answer on how to correct the unexpected results. I am curious as to why there is this assumed modification on detection position by self, internally to Point in Volume, with no apparent documentation to this effect. I see similar results with Get Closest Location. What advantage is there to this kind of self-centric evaluation? Why not just take a verbatim position? -- 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>>
