Attr VOP --- Vs --- POP VOP : (animated Ramp problem)

[sultan]

Hello all

 

Kindly have a look at the following setup:

 

My query is:

 

When i use AttrVOP and use animate Ramp, it works fine.

But if i dont use AttrVOP and create the same logic in a POPVOP, it does not work.

 

any idea ??

 

[woodenduck]

It's really helpful if you can upload a scene file. It's often easy to overlook a tiny detail that someone else might spot.

[anim]

in dopnet  you are in simulation environment and computing Cd based on Cd, therefore that will be evolving every frame, so different result is expected

[sultan]

Following is the file:

 

Question_AttrVOP_Vs_POPVOP_AnimatedRampProblem_v00.hipnc

 

Please have a look.

 

its a simple setup. But m not getting the reason of why animated Ramp does not work in POPVOP, whereas same network/nodes works in AttributeVOP.

 

 

[mestela]

Sops look at upstream nodes to calculate their inputs. Dops only do that on the first frame, then they use the previous frame.

 

Ie, the attribvop works because every frame it gets Cd from the scatter, which gets it from the point sop. Cd is reset to be $BBX every frame.

 

Your pop setup only look at upstream nodes on the first frame. On frame 2, it looks at the result of Cd it calculated on frame 1. You've set Cd black everywhere, so the ramp outputs black as well. Frame 3 looks at frame 2, which is black, outputs black. Frame 4 looks at frame 3, which is black, outputs black etc.

Edited August 17, 2015 by mestela

[sultan]

Sops look at upstream nodes to calculate their inputs. Dops only do that on the first frame, then they use the previous frame.

 

Ie, the attribvop works because every frame it gets Cd from the scatter, which gets it from the point sop. Cd is reset to be $BBX every frame.

 

Your pop setup only look at upstream nodes on the first frame. On frame 2, it looks at the result of Cd it calculated on frame 1. You've set Cd black everywhere, so the ramp outputs black as well. Frame 3 looks at frame 2, which is black, outputs black. Frame 4 looks at frame 3, which is black, outputs black etc.

 

Ok.

 

In SOPs, i am assigning new values to Cd as the frame progresses, which is taken correctly in next frame as Cd is stored in previous frame.

In POPs however this is not the case (as seen the GeometrySpreadsheet and as you said).

But then how do we use Animated Ramps in POPVOPs ?

(i.e. how to get the same results in POPVOP ?)

 

 

[sultan]

in dopnet  you are in simulation environment and computing Cd based on Cd, therefore that will be evolving every frame, so different result is expected

 

i understand Dopnet is a simulation environment, but then can't we animate Ramps in it to get activation (assign colors to points/particles) of certain areas with respect to color as the frame progresses ?

 

[anim]

simply base your ramp on attribute you are not changing in the same sim

 

Question_AttrVOP_Vs_POPVOP_AnimatedRampProblem_fix.hipnc

[sultan]

simply base your ramp on attribute you are not changing in the same sim

 

Great it worked !!!

Thanks anim

 

Hmm.. So instead of assigning initial color to Cd using PointSOP and later reassigning it again in POPVOP, we have to create a separate attribute with initial values which can be then used to drive Cd in POPVOP later.

Now i got it what you meant in your post anim

 

Have created same result without using AttributeWrangle SOP( have to learn using AttributeWrangle as well )

Question_AttrVOP_Vs_POPVOP_AnimatedRampProblem_FixedByUsing_CreateAttribute.hipnc

 

Thanks again anim

[sultan]

Initially we had static color values which we now can pass to POP and animate in POP level using a POPVOP.

 

Now, if we have animated Cd values from SOP level, then how to pass it to POP level ??

 

Following is the file:

Question_TransferAnimatedColorValues_fromSOP_toPOP_v00.hipnc

 

 

Please have a look and guide me.

[anim]

you will have to update it yourself

the safest way is to store original ptnum before sim, then use it to lookup the attribute values in popnet input

Question_TransferAnimatedColorValues_fromSOP_toPOP_fix.hipnc

[sultan]

you will have to update it yourself

the safest way is to store original ptnum before sim, then use it to lookup the attribute values in popnet input

 

Great anim Thanks

 

So, first we have to store the point numbers ("ptnum") in a custom attribute ("original_ptnum"), just like how we are storing the animated values in a custom attribute ("colorme").

Then, in POP, we have to get values of "colorme" by using point() function & the "original_ptnum" which we pass in POP.

Pheeww...   this requires experience to get a hand over this logic.

 

So point() function- "Imports a point attribute value from a geometry"... and since its VEX, so for every frame this function will call to get the latest value of the attribute passed in it, here "colorme".

 

But:

1). when i middle-mouse button till AttributeTransfer i dont see any point attribute called "ptnum".

     So how did you pass "ptnum" to a custom attribute "original_ptnum" when there is no "ptnum" ?

     i know that "ptnum" is a Global Variable, but then how to see its value (& other Global variables) in GeometrySpreadsheet ?

 

 

2). Also, doesnt "id" and "ptnum" means the same ?

     Because their values are different (as seen in GeometrySpreadsheet) inside POP.

[anim]

... So, first we have to store the point numbers ("ptnum") in a custom attribute ("original_ptnum"),...

well, you don't necessarily have to do that if you are sure that @ptnum or @id of your pop geometry will always match input geo, which may be your case currently, but it's usually not

 

1. @ptnum is by default bound to point number, you can find the list of bound data here:

http://www.sidefx.com/docs/houdini14.0/vex/snippets#attributes

 

2. no, @ptnum is the index of point within the geometry, always starting at 0 with constant increment of 1 until @numpt-1

@id is an attribute, which is generally added by pops (or anything) it is simply a value that is meant to be unique even after you delete particles or add a new one, however that's not always guaranteed as you can always change that with any tool or merge 2 geometries with same ids

but overall, @id value usually sticks with particle while @ptnum will change with changing pointcount

[mestela]

Yes, vex @ptnum is hscript $ID, ie, the first column of the geometry spreadsheet.

(Edit: sorry, saw anim replied way before I did....)

Edited August 18, 2015 by mestela

[sultan]

well, you don't necessarily have to do that if you are sure that @ptnum or @id of your pop geometry will always match input geo, which may be your case currently, but it's usually not

 

1. @ptnum is by default bound to point number, you can find the list of bound data here:

http://www.sidefx.com/docs/houdini14.0/vex/snippets#attributes

 

2. no, @ptnum is the index of point within the geometry, always starting at 0 with constant increment of 1 until @numpt-1

@id is an attribute, which is generally added by pops (or anything) it is simply a value that is meant to be unique even after you delete particles or add a new one, however that's not always guaranteed as you can always change that with any tool or merge 2 geometries with same ids

but overall, @id value usually sticks with particle while @ptnum will change with changing pointcount

 

Thanks anim

 

So:

@ptnum = attribute of geometry, already present whenever geometry is created, represents point number and changes when geometry is modified.

@id = attribute of pop and created by pop itself by using the incoming geometry and its value not necessarily match with @ptnum.

[sultan]

Yes, vex @ptnum is hscript $ID, ie, the first column of the geometry spreadsheet.

(Edit: sorry, saw anim replied way before I did....)

 

Right mestela

@ptnum is the first column of GeometrySpreadsheet.