setprimattrib not working properly

[J_rom]

Inside a point wrangle node, I've added this vex code:

vector pos = prim(1, "P", 0);

int prims[] = pcfind(0, "P", pos, 3.0, 200);

foreach(int prim; prims){
    setprimattrib(0, "Cd", prim, {1,0,0}, "set");
}

 

This should change the primitive color for which passed the pcfind test, right?

Well, the color changes to red while inside the radius pcfind, but it changes back to the original color as soon as it leaves the radius.

 

What to do to keep the color red permanently?

Edited October 28, 2018 by J_rom

[3dome]

you need a Solver SOP for that

[J_rom]

So the point wrangle sould be inside the solver sop?

I never understand how the Solver SOP works .

 

The wrangle works fine, I just can't understands why setprimattrib() not working outside the wrangle.

Edited October 28, 2018 by J_rom

[symek]

pcfind returns the indices of points, not primitives. 

[J_rom]

Thank you guys.

I get this result, from the code above.

The problem is that setprimattrib() function is not working outside foreach loop.

Is there a way to keep the color red after they get out of the loop?

 

I don't know how to use a Solver SOP as suggested, and I'm not sure if my problem with pcfind.

 

Edited October 28, 2018 by J_rom

[J_rom]

I tried VOP SOP rather than Point Wrangle, but I get the same result.

Cubes colors change back after the loop ends. same as previous Gif attachment.

 

I don't know how to setup this in Solver SOP, but I'll try.

[3dome]

i set up a quick example for you. As symek said, pcfind (just like any pointcloud operations) return point numbers/operate on points.

anyway, for each point (which is what pointwrangle does) having to loop through all points returned by the pcfind function (which is what your code is doing) can get quite heavy so in my example i'm using the most efficient way I could think of while having my morning coffee

hope it helps

dm_simpleKeepColorSOPSolver.hip

Edited October 29, 2018 by 3dome

[J_rom]

WOW!

Thank you very much!

 

Sorry for the late respond. I had some life troubles to handle.

Anyway, I want to ask you so much questions, starting with What kind of coffee do you use? that's amazing really.

I used to pick nodes randomly hopping for the best, but you! you know how to make magic.

Great.

Say, if I want the particles to keep emitting for longer than 50 frames (which you set in the timeshaft node, I wonder why?), how can I do it? I tried $F, and 1000 but ..

 

[3dome]

haha, no worries!

Well, it might seem like magic for you now - but with a few years using Houdini processes like this become as standard as creating a sphere

But back to topic: why the timeshift?
Some of the following stuff you might already know, but anyway..

The SOP solver is actually a dopnet => simulation, as you probably know or have guessed from the 'reset Simulation' button.
Simulations depend on the data from the previous Frame (or more general: previous timestep).

So if you feed the solver a geometry with changing pointcount (as in my file), the Solver just takes what he gets from the first input on the first frame of the simulation. It has no idea that on the next frame there are more points in the first input because on that frame it works only with the data it already has (which is what it got on the start frame).

This is why I'm using the timeshift. The idea is to set it to the frame where all the data is available (if you dont kill any particles that would be the last frame of your sim). For demonstration I just decided to take frame 50 and have that as my data that the solver should operate on. (so frame 1000 should work..) Let's call it static data - so input 1 wants to have static data or it will take 'a copy' of the dynamic data on the start frame of the sim and by making 'a copy' of that data on that frame is becomes static.
To get the actual motion of the particles back, I update the static data from 'previous frame' with dynamic data fetched from input 2.

 

Oh and my coffe is currently Puro Fairtrade Coffee