yeah you're right, sorry for not thoroughly testing my code.
here's an update that now should work fine and also has a offset parameter:
(Edit: that variable name frame_from_one doesn't make sense as it's actually 0 when the first point turns green)
//put $RFSTART into the parameter. Remove the -1 if you
//don't want the first frame to be already counted
int rfstart = chi("rfstart")-1;
int offset = chi("offset");
int frame_from_one = int(@Frame - rfstart - offset);
int speed = chi("num_frames_between_move");
int frames_on = chi("num_frames_turned_on");
int pt_to_turn_on = frame_from_one / (speed + frames_on);
int on = frame_from_one % (speed + frames_on) < frames_on;
if(frame_from_one >= 0 && (on && @ptnum==pt_to_turn_on)) @Cd = {0,1,0};
dm_VEX_Timer.hiplc
have a look at the scene or try my code...not sure if that's what you're after
int speed = chi("num_frames_between_move");
int frames_on = chi("num_frames_turned_on");
int pt_to_turn_on = (@Frame-1000) / (speed + frames_on);
int on = @Frame % (speed + frames_on) < frames_on;
if(on && @ptnum==pt_to_turn_on) @Cd = {0,1,0};
dm_VEX_Timer.hiplc
just a random thing that popped into my mind:
storing the sourceprim a particle was emitted from, using that with primuv() to lookup the shop_materialpath attribute to get the shader assinged to that sourcprim and from there get the texturepath (not figured out that part)
while there are functions like inprimgroup() or inpointgroup(), whenever possible I like to use the shorthand @group_groupname syntax. So if you run over points and are looking for a pointgroup then your code would be
if(@group_inside)
{
f@stiffness = 1;
}
else
{
f@stiffness = 1000;
}
absolutely. only cache the fields you need. If you need vel for motion blur, you could resample the vel VDB to 1/3 of the resolution, that's usually enough for motionblur. Also make sure to save out 16bit fields instead of 32bit
and one more big saving comes from compressing the volume as well as masking the vel field by the density field
I think the vector merge can only merge VDBs, so reversing the order of convertVDB and vectormerge should do the trick
Also, you might want to set the vector type on the vectorMerge to the correct type (i think it's called displacement/vel/acceleration) so it gets interpreted correctly in some other operations
on the scatter, under Output atributes, turn on Prim Num Attribute
then use a primitivewrangle, plug the grid into the first and scatter into second input:
i@scattered = findattribvalcount(1, "point", "sourceprim", @primnum);
interesting. The docs state 17.5 but I think they removed it in 17.5 then and the docs page is just there for legacy purpose (because until it really is removed the operator is just hidden by default)
seems like the particleFluidEmitter DOP ships with some version of Houdini. I'm using 17.5.173 and I do not have it, so must come with a later build
https://www.sidefx.com/docs/houdini/nodes/dop/particlefluidemitter.html
hmm I guess it's guide geometry (like when you create an otl and can spcifiy a node as guide geo, just here it's code in c++) and maybe it's a small bug in the code.
anyway, if you need to see it you could put down a volumevisualize SOP as a workaround
You don't necessarily need a loop, although it might be the cleanest (and if compilable) fastest way.
Anyway, here is a file to show 2 other methods of doing it
dm_surviveConversion.hipnc
I hope I understand this correctly. There's 2 things you could do:
1) Don't use groups, attributes are superior in most cases. Instead of creating groups, create an integer or string attribute and use that as Piece Attribute on the loop, like ThomasPara suggested.
2) The name SOP can build names from groups, from there it's the same as 1)
Iirc the old foreach subnet had the option to run over groups, the new ones does not.