You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi there all. I'm wondering if I have uncovered a small bug in H 18.5.
I am using the intersection analysis node to identify poly lines that cross in the zx plane.
The node has the ability to output the primitive numbers of the prims that intersect at each of the points found.
The attribute is stored as an array of 2 ints. One for each of the 2 prims that intersect at the given point.
The bug I believe I have found is that for a pair of prim lines that cross I would expect the first and second prim numbers on the sourceprim attribute would be the same as the prim numbers of the lines. For example [0,1] would suggest that an intersection point was found between prim 0 and prim 1.
What I am finding is that the second of these numbers is correct for the prim that I can see crossing but the first is out by 1 unit.
Is anyone able to test this behavior for me, or confirm if this is expected behavior?
I think I ran into the same thing, and I think what you're (and I was) getting back in fact are indices of triangulated versions of the geometry (the node itself gives a warning to triangulate your geo IIRC). Try to do that (pre-triangulate your geometry, e.g. with a Divide SOP) and then it should work as expected.
It could worth logging though, I might do that at some point. Oh and I was in 18.0 so good to know they still didn't fix this by 18.5
The text was updated successfully, but these errors were encountered:
Hi there all. I'm wondering if I have uncovered a small bug in H 18.5.
I am using the intersection analysis node to identify poly lines that cross in the zx plane.
The node has the ability to output the primitive numbers of the prims that intersect at each of the points found.
The attribute is stored as an array of 2 ints. One for each of the 2 prims that intersect at the given point.
The bug I believe I have found is that for a pair of prim lines that cross I would expect the first and second prim numbers on the sourceprim attribute would be the same as the prim numbers of the lines. For example [0,1] would suggest that an intersection point was found between prim 0 and prim 1.
What I am finding is that the second of these numbers is correct for the prim that I can see crossing but the first is out by 1 unit.
Is anyone able to test this behavior for me, or confirm if this is expected behavior?
I think I ran into the same thing, and I think what you're (and I was) getting back in fact are indices of triangulated versions of the geometry (the node itself gives a warning to triangulate your geo IIRC). Try to do that (pre-triangulate your geometry, e.g. with a Divide SOP) and then it should work as expected.
It could worth logging though, I might do that at some point. Oh and I was in 18.0 so good to know they still didn't fix this by 18.5
The text was updated successfully, but these errors were encountered: