Jump to content
Sign in to follow this  
Jsmidlow

POP proximity to group

Recommended Posts

Hi everyone!

I have a very basic POP setup. The side with positive P.x belongs to group "right". With a "POP proximity" node I check nearest particle. My goal is to fins if particles from "left" have a nearest neighbour from group "right" and if they have color them red. In my opinion it should be simple. The nearest attribute gives you a number of a nearest point and you use it within "inpointgroup" to check if nearest belongs to this group. If it belongs color red the point that has a current nearest as its attribute.... But it doesn't work. 
I tried to put the same code in in a "geowrangle" but it wasn't working also there. (in general what's the difference between "popwrangle" and "geowrangle"???).

Proximity.thumb.PNG.101da021544089bc5dabfdd343730bc8.PNG

I trief to solve the problem avoiding "inpointgroup" by assigning the attribute ntest to particles from the right and checking in popwrangle within "point(0,"ntest",npt)" if a nearest has the ntest attribute equal 1... but again things aren't working... Apparently "point" doesn't work that way in POPs or I use ot wrong... don't know..

ntest.thumb.PNG.017de7eaa442d771ca6286ad335c99f1.PNG

Share this post


Link to post
Share on other sites

I think the problem is your inputs. When you deal with any kind of wrangle in DOPS you have to manually set the inputs in the "inputs" tab.
In SOPS these are set for you automatically where the first input is 0 and the second is 1 etc but in DOPS you have to manually assign this. Try going into the inputs tab and set "first context" to "myself" and see if that changes anything.

  • Like 1

Share this post


Link to post
Share on other sites
56 minutes ago, underscoreus said:

I think the problem is your inputs. When you deal with any kind of wrangle in DOPS you have to manually set the inputs in the "inputs" tab.
In SOPS these are set for you automatically where the first input is 0 and the second is 1 etc but in DOPS you have to manually assign this. Try going into the inputs tab and set "first context" to "myself" and see if that changes anything.

Thank you for the reply and advice. It worked... but worked in a strage way. It colors in red particles that are not part of a "right" group.

Blue marker is ID of a point and white marker is id os a nearest. Somehow they are colored red though the nearest point doesn't belong to the "right" group.
I include the file POPS_studies.hipnc
cut.thumb.PNG.364ff7d661b30821d436ca72ffad3e46.PNG

Share this post


Link to post
Share on other sites

I think I found the issue. By default, the "pop proximity" node gives the "nearest" attribute a value of 0 and it just so happens that point 0 is part of the "right" group so it falsely triggers and changes the colors of points that are nowhere near the middle line. I've made a hack to fix it, basically just saying that if "nearest" is 0 then set it to -1. This means that we don't get any false positives because there are no points with the point number -1. However, this also means that if a point is actually right next to point 0 then it still won't trigger because we are just blanket saying that if "nearest" is ever 0 then set it to -1. Maybe you can find a better way around this but this was my super quick fix, a solution might be to write it out in vex rather than using the "pop proximity" since you should get a value of -1 by default in VEX if it does not find anything instead of 0.

POPS_studies_mnb.hipnc

  • Like 1

Share this post


Link to post
Share on other sites
17 minutes ago, underscoreus said:

I think I found the issue. By default, the "pop proximity" node gives the "nearest" attribute a value of 0 and it just so happens that point 0 is part of the "right" group so it falsely triggers and changes the colors of points that are nowhere near the middle line. I've made a hack to fix it, basically just saying that if "nearest" is 0 then set it to -1. This means that we don't get any false positives because there are no points with the point number -1. However, this also means that if a point is actually right next to point 0 then it still won't trigger because we are just blanket saying that if "nearest" is ever 0 then set it to -1. Maybe you can find a better way around this but this was my super quick fix, a solution might be to write it out in vex rather than using the "pop proximity" since you should get a value of -1 by default in VEX if it does not find anything instead of 0.

POPS_studies_mnb.hipnc

Thanks a lot! SOLVED!))))

  • Like 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×