Adding points to nearest Group? (Vop or Vex)

[Mokiki]

*Edit* Sorry! I just noticed I posted this in the wrong forum section. Could one of the mods please move it?

This might be pretty simple but I have a hard time wrapping my head around adding points to groups based on a specific requirement.

I have 4 point groups and amidst those groups new points are being generated that don't belong to any of the groups.
What I want to do is having the points that are being generated check for the closest group they find, join that group and stay in it.

Currently trying to build this system in a pointvop but I have a hard time understanding the logic I have to use. Even the first step of identifying the points to work on is a problem for me. I can easily check with "InGroup" for those points not in any of the groups and get a bool statement out of that but it is not really clear to me how I can reverse this information and get the pointnumber of said points.

Hopefully somebody can help me and point me in the right direction.

Cheers!
 

 

 

Edited March 3, 2017 by Mokiki

[anim]

do you have an example scene?

but overall if you want points to stay in groups you'd have to do it in solver or DOPs

and you can use nearpoint() to get the closest point within specific subgroup of points, which in your case will be * as you want to check closest from all groupped points

then you can parse through all point groups and find the first one found point belongs to

however to make this easier for you, you can use int attribute instead of groups, then you know it's non-overlapping and you can directly take the number from found nearpoint()

Edited March 5, 2017 by anim

[Mokiki]

Hello Tomas,

thanks for taking the time to help.

I cleaned up a file to hopefully make it clear what I am trying to do.
I also included the first few frames from the particle sim. 

Explanation:
The file shows 4 particle spawn locations and each location is basically represented by 1 group. Each one has a different color which I later need to work with.
The problem is that during the sim new particles are created to fill the holes, which don't fulfill my grouping requirements. In this example it is a different viscosity value but in the real work file it's just the emitter location.
So I want those newly created particles to join the closest group around them and stay in the group they joined.

The biggest problem is that the simulation that I have to manipulate wasn't done by me and I have no way to distinguish between the different particle groups except their emitter location. All particles are in 1 alembic sequence
and have the same parameters.
So I don't have any attributes to mark like in the example I uploaded. Luckily I already solved that problem,  but I didn't take into account the particles that spawn within the fluid to fix holes, so they can only distinguished by their spawn location. (e.g they didn't originate where the others came from)

 

Cheers,
Oliver


 

odforce_adding_to_nearby_groups.rar

Edited March 5, 2017 by Mokiki

[anim]

here is basic point wrangle that runs over !* to get groups from closest groupped point:

int pt = nearpoint(0, "*", @P);
string grps[] = detailintrinsic(0, "pointgroups");
foreach(string grp;grps) {
    if(inpointgroup(0, grp, pt)) {
        setpointgroup(0, grp, @ptnum, 1);
    }
}

but that will get them live every frame, since your current setup is just live in sops

what you may want to do is run it through solver and put pointwrangle inside that runs over !*

and has Input_1 node as a first input and Prev_frame node as second:

int pt = idtopoint(1, @id);
int geo = 1;
if (pt == -1) {
    pt = nearpoint(0, "*", @P);
    geo = 0;
}
string grps[] = detailintrinsic(1, "pointgroups");
foreach(string grp;grps) {
    if(inpointgroup(geo, grp, pt)) {
        setpointgroup(0, grp, @ptnum, 1);
    }
}

here is the file

rf_adding_to_nearby_groups_odforce_fix.hipnc

[anim]

but I guess the main question is

since you are getting groups from different viscosity values, why is the tool producing the filling particles not inheriting viscosity from surrounding points? You may want to discuss that with artist creating that sim as that will for sure have influence on the look of the fluid and as well your troubles could have been avoided if all the new particles had the viscosity of it's stream

Edited March 5, 2017 by anim

[anim]

just for comparison, here is the same setup, just using stream attribute instead of groups, which may be not only easier, but more efficient

rf_adding_to_nearby_groups_odforce_fix2.hipnc

[Mokiki]

Huge thank you for your help Tomas.
Since my vex knowledge is pretty much zero. (Will study your examples once I am back at my workstation)
But just for my understanding. Is the disadvantage of the live setup that it's computationally more expensive? Or that it might switch the points it already placed into nearby groups again when the 4 streams collide with each other?
Sorry for asking really basic questions.

I think I avoided using the solver because in my previous tests I had problems with changing point counts. But that was when I tried to make groups by bounding box stick via solver and get my animation back by copying the point positions which resulted in weird jittering, while it worked completely fine in non changing point count situations.

To answer your question I  had a small discussion with the artist last week. And from what he told me he is using a few different scripts to get a certain look for the fluid in realflow. Downside of said scripts is that the fluid tends to get unstable if they affect multiple emitters so all emitters are injected into 1 container. All newly spawned particles have the settings of the container.

The different viscosity values were just something I did to get some quick tests done.

But I agree it's too much of a hassle for the effect I am supposed to do. The goal is just to mix the point colors once the particle groups collide with each other and get some quick and dirty paint color mix effect.
On the plus side I learned a lot during the last week thanks to this community.
It seems though that I have to give vex a closer look sooner than anticipated. 

[anim]

9 minutes ago, Mokiki said:

... Is the disadvantage of the live setup that it's computationally more expensive? Or that it might switch the points it already placed into nearby groups again when the 4 streams collide with each other?
...

sort of both

1. more expensive if you really consider just points without group or stream within the solver, as those will be just filling points from newest frame, compared to all filling points created so far

2. and of course they will get group or stream live every frame, so they will switch group or stream if closer to other one

3. on the other one if you are ok with both previous disadvantages, the live setup will not necessarily need to be recached while solver one will 

but really it's mostly the 2. that you should be concerned about so if that bothers you, use solver method

 

but once you want to mix the colors, definitely use solver method and do mix within, so far ids coming from sim seem to be ok, so as long as that's the case you will not have problem with changing point count since you can be matching by id as in the example

Edited March 5, 2017 by anim

[Mokiki]

Thank you. You definitely gave me a lot of information to work with. I really appreciate it.