Jump to content
J_rom

setprimattrib not working properly

Recommended Posts

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 by J_rom

Share this post


Link to post
Share on other sites

you need a Solver SOP for that

Share this post


Link to post
Share on other sites

So the point wrangle sould be inside the solver sop?

I never understand how the Solver SOP works :huh:.

 

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

Edited by J_rom

Share this post


Link to post
Share on other sites

pcfind returns the indices of points, not primitives. 

Share this post


Link to post
Share on other sites

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.

 

cubes.gif

Edited by J_rom

Share this post


Link to post
Share on other sites

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.

Untitled3.png

Share this post


Link to post
Share on other sites

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 :D

hope it helps

dm_simpleKeepColorSOPSolver.hip

Edited by 3dome
  • Like 1

Share this post


Link to post
Share on other sites

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 ..

 

Share this post


Link to post
Share on other sites

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 :D

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 :D



 

  • 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

×