Keep point color, once it changed

[chiess]

Hi,

It is probably a simple solution, but I must've lost my brain long time ago

How can I keep the color change of a point, once it changed color?

For example: objectA is going through objectB, during that movement, the point-colors of objectB changes when they collide with objectA's points. Now, as soon as objectA is not "touching" objectB anymore, those colors revert back to their original color. How can I keep that color-change?

I've started using vopsops with the compare node, but I am a bit stuck. I basically just need a point attribute which gets set as soon as that points color changed, but I just cant figure out how to keep it, and stop it from reverting back.

if - expressions apparently don't work, since those output an "else" value as well.

Is there a node or expression I missed or forgot completely about?

Thank you!

[sanostol]

You need to do it in a simulated context

-popnetwork or solver in sopcontext

-sopsolver or popsolver in dopcontext

little solver example

solverexample.hip

[chiess]

Hi sanostol,

Thanks for the example-file.

Can you please explain some of your steps you did? I am not sure why you used that switch to exclude prevFrame in the first frame?

So basically, prevFrame always looks into the frame before it? What I don't understand then, why do I have to import the translation of the object (via the vopsop)? The animation happens outside of the solver anyway? So prevFrame should basically show the situation just one frame behind? I don't think I fully understood that node

Thanks!

[sanostol]

As soon as You use the previous geometry input, it is up to you to update the point positions, but now You have full simulation control over your geometry. if You just use the first input, the solver writes data on the points but they don't get used in the next simulation step. I think You could also import the color information from the previousframe node to the other node to get it working

Martin

[chiess]

Thanks Martin!

I tried to use your solver example in one of my test-files, but unfortunately it doesn't work as intented.

I attached a file with my test.

A sphere hits a grid and changes the "hit"-points into red. Now I am trying to save that color, instead of going back to black once the sphere passed by.

I tried to solve that with the help of your solver example, but I am doing something wrong and I don't know what. I also changed the color to green within the solver, just to see that something happens (which worked). If you can help me out here, that would be great.

Thanks,

Chris

greenPoints.hip

[anim]

you need to accumulate the color in some way, currently you are overwriting Cd on every point with the live input so you are getting the same result as before Solver SOP

here is the example of getting the maximum value of the Cd, but you can as well use any math to combine existing Cd with the live one

rememberColor.hip

[chiess]

Thanks Tomas!

I solved that issue now, by just using the attributeTransfer INSIDE the solver sop. That did the trick and was the solution to "accumulate the color" (or any attribute)

In your example, you created a vopsop inside the solver and saved out the highest Cd value found, right? Hmm unfortunately I am still very confused with this solver sop and the Prev_Frame

Thanks,

Chris

[anim]

it's a simulation environment

you can imagine Solver SOP as a loop over frames

at start frame Prev_Frame node contains geometry from the first input of the Solver SOP

then this geometry is processed inside and whatever is the result this frame will be in Prev_Frame node next frame (or timestep) etc

so there is no longer direct connection to input geometry of Solver SOP so to achieve that you can use for example input nodes Input_1-4 which are just bringing geometry from outside of Solver SOP at current frame, so Input_1 contains geometry of first input of the Solver SOP at the current frame and you can take it's current value and add(or mix in any way) to geometry inside of Solver SOP

if you ever used Sop Solver DOP Prev_Frame is exactly the same as Dop_geometry node in there or if you are familiar with Foreach (with Merge Results off) then it's similar to Each node in there, all of these nodes simply hold result of previous iteration

[chiess]

AH, that makes sense, so basically (thinking in scripting/coding terms), everything inside the solver sop gets iterated through in each frame and "added" to the input geometry.

For example, the outcome of the solver sop in frame 10, gets added to the input of the solver sop at frame 11 (the Prev_Frame node)?

[anim]

it's not added, but it's passed to

but yes

the same geometry which is the result of frame 10 will be in Prev_Frame next timestep (with substeps 1 it will be frame 11)