anim

if you pack your bottle before feeding into solver you can add attributes i@computecom=0 to disable automatic computation of COM and v@pivot to adjust where the actual COM will be

in your Group SOP you can do @name=wh_* to group all elements whose name starts with 'wh_'

- you can use Vellum Drape SOP or Vellum Solver and Timeshift before your main sim - or append Stash SOP to your sim, stash the geo and plug as an input, in case you are modifying constraints in the solver you may want to Vellum Pack both result outputs and stash that - Vellum I/O save frame you like to start from and Vellum I/O it back as a start frame

use pt.itemGeneratorScript(), pt.itemGeneratorScriptLanguage() and pt.setItemGeneratorScript(), pt.setItemGeneratorScriptLanguage()

but just don't use Python SOP to set keyframes, especially not if the affected node is directly upstream, since Python SOP cooks every time it's being evaluated and in the live network that can be a lot especially if it's dependent on time use Python Expression instead to return whatever value you want depending on the frame or parameters or something

in find_nearpoints replace this i[]@nearpts = nearpoints(1, "!grp", @P, .1, 4); with this string grp = "!grp" + itoa(i@source); i[]@nearpts = nearpoints(1, grp, @P, .1, 4); or alternatively you can completely bypass your set_lines_grp as you don't need to have those groups, because you can use ad-hoc group syntax in nearpoints directly: string grp = "@source!=" + itoa(i@source); i[]@nearpts = nearpoints(1, grp, @P, .1, 4); VEXgrp_01_fix.hiplc

You can't set those groups in the same wrangle as nearpoint is looking at the input geo, the groups have to exist on the input geo so split it in 2 Also when you are setting the group don't use ! in it's name, that's just to negate the matching pattern

yes, exactly as you had it, just combine with the ! as mentioned to negate the group string grp = '!grp_' + itoa(i@id);

please do, one never knows whether it is on purpose so that you have to have FX license to do that or if it's just because grain parameters came in later so they were never promoted to SOP level

like in any other group parameter if group name is 'grp_0' then not that group would be '!grp_0' however it would be inefficient o be creating groups per point, since you can use point numbers directly for a group, '0' and '!0' also if you just want to always exclude current point, then instead of using groups it's better to just find closest 2 point using nearpoints() and then remove first from the array, but again it depends on what you are doing I may be just assuming stuff based on example

I'd recommend coloring it during flip sim (green nodes) as you are using reseeding alternatively you can color it after (blue nodes), but some colored particles will be deleted and the new seeded particles will not have the color until they touch the sphere so would not recommend if reseeding is on Color_Transfer_fix.hip

the confusing part is that once the HDA is unlocked, the dive target doesn't work so you have to navigate manually to the forces node which is not obvious nor convenient

well, yes, because I left the one you had inside before, just fixed to work on Geometry and be point, so you can just delete or bypass it if you don't want to set it dynamically vu_GrainsVellumSOP_fix3.hiplc

just unlock Vellum Solver SOP and inside on the Vellum Solver DOP set Attraction Weight and Stiffness to 1 then use f@attractionweight and f@attractionstiffness point attributes to scale them, either as initial values from input geo or dynamically inside of the solver just make sure they are point attributes on the Geometry data not Prim on ConstranitGeometry as you have it now vu_GrainsVellumSOP_fix.hiplc

I mean in DOPs in Sop Solver, or for short Foreach Loop inside of Solver SOP if you only care about processing the geo over several timesteps if you don't care about the actual time evolving then you can just do foreach loop and inside For Feedback loop that will loop over certain number of iterations if it's bullet however then maybe just merge all your setups together, make them separate collision groups so that they don't interact and run them as one sim, since as you noticed you can't run parallel sims without TOPs EDIT: or if you are adventurous you can have a look at Edit LOP Viewport State where the whole Bullet sim is constructed and run within Python, so maybe you can use something like that