coltonmil

My mistake! I always forget that expressions key with bezier() anim as well, but my method was flawed from the beginning as I was doing + as opposed to * anyways. If you go to both keyframes of your rising anim and change the + to a *, and copy the value from frame 24 to 1, it should fix this problem.

You had all the pieces, just needed the glue to get it together I used your ID attribute that you generated to control the isolation of the points on a specific frame number. This ID effectively acts as a generation frame, so current frame minus this gives you an animation frame that starts each time a point is generated. All of this is controlled through copy stamping, no additional For Each is needed. I also provided a solution in the file for additional randomized Y scale. initialize_anim_H16_v2.hip

You had the right idea with the solver! I did exactly as you were thinking additive velocity that controls a copy stamp that affects an upstream timeshift SOP. Your use of alembic frame is interesting and new to me; I don't have your test abc to see how that works, but you should be able to adapt my setup to work with yours. animation_playback_by_speed_v3.hip

For a fast explosion and thin collisions 10 substeps is actually not super crazy. It'll really be the only way you can get accurate collisions at that level. You can set the max substeps and play with the CFL so it's only doing the full 10 substeps at the beginning of the sim where it needs the detail. If you're looking for a dirty trick, you could make your roof much thicker in the +Y direction for the first couple frames of the explosion, and as the fire ball begins to slow as it breaches the roof, start to scale it back to normal. This may cause some strangeness in the smaller pieces, and negatively effect the way the fireball would wrap around the roof as it blows outwards.

Is it significantly faster to sim with a larger number of simple convex hulls than one complex concave?

Adding density field and using the temperature as density fixed the issue as well. cmil_debug_refl_v001.hiplc

Sorry about that, forgot I'm using a custom vdbfrompolygons, if you just swap in the standard one you should be good!

Got a closer shape using the ideas I posted above! With some overall warping, and playing with the VDB meshing, you might be able to massage this into something like the ref. vexGeoTest_v01.hipnc

Sorry man, I haven't had a lot of time to try out some of the ideas I had, but here's the basis of what I'm thinking: Use this method to create polylines: Do a nearpoints like shown, but then don't connect points that are at the same "level" as each other (or distance from center), so you end up more with these 45 degree connections going inwards like in your ref. Then convert to geo and blend using VDB to get the nice smooth connections like the ref. I'll try and flesh something out more, but this is a great tut to go through regardless

I think it might be more controllable using poly-lines and creatively grouped points to connect everything as opposed to just metaballs like the method I'm doing. I'm trying a couple other things to see what I can come up with, but I'm certain a Houdini genius can swoop in here with a solution readily available We really need a bat-signal type light with a giant H for these guys

Something like this?

You'll need another attribute that has the frame at which the points activate, so you can compare current frame and activation frame, and then remove them when they exceed 1.5. Something like: @corrosion = (@Frame - i@activationFrame) * .1; if (@corrosion > 1.5){ removepoint(geoself(),@ptnum); } For user-friendliness it'd be nice to replace those hard coded numbers with sliders though @corrosion = (@Frame - i@activationFrame) * ch("FrameStep"); if (@corrosion > ch("KillThresh")){ removepoint(geoself(),@ptnum); }

Hey Kashmere, This may be way off-target, but maybe it'll still help! I know you're going for a mainly vex focused approach, but if you're just trying to get a single point attribute of the nearest point between two pieces of geo, using an attribute transfer might be the way to go. Set an attribute like "nearpointid" to the ptnum, and then attribtransfer that over. Edit: On second thought shouldn't a simple implementation of nearpoint in vex do what you're looking for? Maybe I'm completely mistaken. i@nearestpoint = nearpoint(1,"",@P,ch("radius"));

I originally mined a bitcoin back in mid/early 2011, when it was possible on a single personal machine! I gave up, as it took about a day and a half to mine one coin, and they were worth about 4 bucks. I had that coin kicking around a wallet.dat for a while that I promptly forgot about, and then in 2013 the price spiked up to $1000. I scrambled to find the wallet.dat, luckily, found it and quickly sold it on Mt. Gox. The same week the Mt. Gox hack/scandal happened... Still in their bankruptcy proceedings, apparently I will see that money some day hahaha. If only I knew!

I have an imperfect solution, but it's very close, and should at least be workable. This is using a tool from the Qlib toolset called group_edge_loop. First group an edge ring of the tube (Select first edge then hold A and middle mouse click to select the whole ring). This part could use proceduralizing, I'm not sure the best way to do this though. Then use group_edge_loop_ql SOP to create groups of every loop. Promote to point group and then use pack SOP to get a centroid point for each loop. The group_edge_loop_ql SOP doesn't seem to resolve the loops on the caps correctly, so I'm removing the end points from the line. FindthecenterTest_v02.hipnc Edit: In regards to Aragatory's question above, this will only work with a tube.