RE: Goemetry Peculia-Queries
Yeah I know. I understand that and given the discussion recently about reference frames I was able to figure that out. But documentation offers no insight on what to expect: http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/index.html?url=files/iceref_Point_in_Volume.htm,topicNumber=d30e332561 The user is left assuming that this node only operates on verbatim point position as external input. Only to discover that internally self is being evaluated and adjusting any externally provided point position. This is unintuitive that its not explained better. I don't mind that it works this way, it would just be useful to know and to know what advantage it provides over not evaluating self. That way the user can be prepared for the adjustments necessary rather than spend hours trying to figure out what is actually going on. -- 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] On Behalf Of Grahame Fuller Sent: Friday, August 16, 2013 11:50 AM To: softimage@listproc.autodesk.com Subject: RE: Goemetry Peculia-Queries 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: softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com> [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Ponthieux, Joseph G. (LARC-E1A)[LITES] Sent: Friday, August 16, 2013 11:38 AM To: softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com> 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.
RE: Goemetry Peculia-Queries
Just to add for your last point, keeping everything local to self makes everything consistent. So for example, you can raycast from Self.PointPosition along Self.PointNormal and everything works as expected with no need to convert ref frames manually. gray From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Grahame Fuller Sent: Friday, August 16, 2013 11:50 AM To: softimage@listproc.autodesk.com Subject: RE: Goemetry Peculia-Queries 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: softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com> [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Ponthieux, Joseph G. (LARC-E1A)[LITES] Sent: Friday, August 16, 2013 11:38 AM To: softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com> 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. <>
RE: Goemetry Peculia-Queries
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: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Ponthieux, Joseph G. (LARC-E1A)[LITES] Sent: Friday, August 16, 2013 11:38 AM To: softimage@listproc.autodesk.com 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. <>
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.
