SteveSayer

Thanks both for your suggestions. I've actually made good progress with my second approach: I managed to set up a SOP Solver node to copy a point into a geometry container at each moment of impact. Those points persist and, since they're being created in a SOP that is riveted to the shield animation, they update their orientation automatically and correctly. Then I just copy the arrow geo on to them, and kill off the original colliding particles that created them. Fathom, obviously if I got your solution working it would be more robust, since it would allow me to attach to deforming surfaces, and not rely on rivets and rigidly-shaped colliders. Artem, I'll download your scene and have a look--thanks so much for taking the time! Also, if we're worried about overcomplicating things, we shouldn't be using Houdini, now, should we?

Hi, folks. I need to set up a simulation where dynamically-generated arrows fly, then collide with a deforming surface and stay stuck to that surface (shields carried by moving soldiers). Importantly, the arrows should NOT just align along the prim normal on collision; they should protrude at the angle at which they collided. This is a topic that's come up before, but I haven't been able to find a satisfactory answer about it. Some suggestions don't quite hit all the elements I need; some are for older versions of Houdini and so might not be as relevant/accurate (I'm on H14). The approaches I've considered are: 1. Particle-based arrows that stick. It's easy enough to copy arrow geo onto a particle sim, and have the particles stick to the collisions surface. However, then the particles have to start inheriting the orientation of the collision prim as it continues to move. This could be handled two ways: The collision geo is deforming. In this case I'll somehow have to calculate how the collision prim has transformed from the moment of impact to the current time. The collision geo is transforming. In this case I'd use rivets to attach non-deforming stand-in geo to the moving collision objects (which don't change shape). Not ideal, but it might make it easier to work with the orientation values? 2. Particle-based arrows that create geo. Having already grown sick of the mathematical jungle of quaternions, matrices, and dihedrals, I wondered if a better approach might be to make each particle spawn some geo in the colliding object's network instead (presumably using a SOP Solver?) , then die. This would hopefully eliminate the need to continuously update orientation. 3. RBD-based arrows with constraints. Moving away from particles altogether, I wondered about using simple Bullet geo for the arrows, and dynamically creating constraints to pin them to the shields when they impact. An advantage of this method would be that it would allow realistic stick-like collisions and bounces for loose arrows--something particles can't really do. If anyone has any thoughts about which of these methods is most promising, or has any specific advice about how to implement them, I'd be extremely grateful to hear. Thanks in advance!

Thanks, Kevin, Paul, and Cody. Sounds like they're trying to address all the main issues; definitely worth a look!

Thanks for all the replies and suggestions, folks. I'll keep digging and be sure to update if I find anything.

Is there any more recent info on this topic? The pdf linked above doesn't exist anymore. I've been investigating using the Amazon Cloud to run some fluid simulations that my home machine isn't powerful enough for, then render the results. I've done successful tests rendering frames using the cloud service, but I haven't yet been able to accomplish a simulation/rendering combo. Here's the ideal process I'd like to be able to implement: Set up my simulation and do low-res tests on my home machine. Increase fluid resolution to production quality. Upload the scene to the cloud, and have one powerful machine with lots of RAM simulate it. Have a group of less-powerful cloud computers render out the resulting frames. Download the finished renders--but NOT the fluid cache files (which will be hundreds of gigs all told). Is this possible? Anyone know the ROP structure I should use? If this 'ideal' process isn't possible, I suppose the next best thing would be to have a single powerful cloud machine perform both the simulation and rendering tasks, but I haven't successfully set that up either. One of my tests resulted in the fluid cache being downloaded instead of the rendered frames (in fact the frames didn't render at all). Anyone have any experience with this sort of task? It seems like it must be a fairly common one, given the advantages of cloud computing. If there's a step-by-step guide somewhere it would be immensely helpful. Thanks, all.

Hah. Point taken, marty--and probably quite correct in this case (read on). Good note, Tomas, thanks. I had been keeping my playback rate in sync with my DopNet substeps, as I found I was experiencing (other) errors otherwise. I'll look into the Interpolate Display Data route instead. Thanks again. As to the inconsistent playback... I think I tracked it down, at least partway: I had been using an expression to control the Impulse Count of the POP Source creating the trailing particles. When there are more primary particles, I needed a higher volume of trailing points being emitted in total. So this expression factored in the point count of the primary particles. To do this I was using npoints() on the primary particles' DOP I/O node in SOPs. For some reason, that seemed to be causing the problem (admittedly not sure exactly why--any thoughts?). Replacing the expression with a constant restored correct emission behaviour. So, I dug a little deeper to find the appropriate expression to get the pointcount of a particle object directly in DOPs. Since switching to that workflow, playback has been consistent--touch wood! I'll keep an eye on it and check back in if I figure out anything new. Thanks for the help, folks.

Thanks. Yeah, I'll try to post a pared-down version of my hip file soon. I just wondered if it was something that was a known issue and could be flagged quickly by someone with more experience than I. It seems to me that for fast-evolving effects it would be pretty common to use oversampling and/or non-integer frames for increased control... it'd be surprising and frustrating to find out that such basic functionality is missing. Thanks again.

Ah, good find, Tomas. I've always wondered exactly what the difference is when you have the option of several different types of vector. Guess this is one of the major ones. I'll have to experiment with it. Thanks!

Hi, Skybar. Thanks for the reply. No, switching to integer frames doesn't solve the problem. I'm using the 0.5 playback rate because I'm using the 'all points' emission type, and I need twice as many particles to be emitted as I'd get if I used integer frames. I experimented with a few approaches, and this seemed like the cleanest and most reliable way to have extremely precise control over the number of particles emitted.

Folks, this issue is driving me crazy. I've got a scene in which one POP solver creates some primary particles, and then those particles leave trails of other, secondary particles behind them. I'm playing the scene at a non-integer frame value (0.5 frames). The POP solvers are all using 1 substep. But playback is very inconsistent! Sometimes the secondary particles just don't show up during playback. Sometimes they do. It's maddening. I'll play the scene a dozen times and only the primary particles will be visible. Then I'll toggle a bunch of settings--like substeps, DOP network visibility, particle display mode--and sometimes, seemingly at random, the secondary particles will start showing up properly. But I can't for the life of me figure out why it's so inconsistent. Nor can I figure out a bulletproof, reliable series of changes to make things work properly. I've tried sourcing the secondary particles through DOPs as well as through SOPs, The same problem occurs. I'm at my wit's end--it's very difficult to be productive when half the time my scene won't play properly. Is this a known issue? Can anyone suggest a workaround? Things improve if I cache the original particles first, but that isn't exactly the most efficient workflow when I'm trying to tweak behaviour. Thanks for any suggestions.

Answering my own question... in case anyone else can benefit. The solution seems to be to use a 'transform' node in a volume VOP to transform the vectors from world space into object space. Feels a bit convoluted but seems to work.

Hi, Diego. Thanks for the suggestion. I'll have to dig in and see if I can figure out his approach. From a quick skim I'm not sure if he's rotating (or animating) the VDBs. I'm interested in the more generic solution, too, though--eventually I'd like to advect not just particles but one smoke object with another. So think, like, a wisp of smoke is rising from an ashtray... and I want to move and rotate my previously-simmed fan effect so that it sweeps through that wisp and blows it away with appropriate motion. Other suggestions therefore still very welcome!

Hi, all. Hope someone can help out with this--I've hit a bit of a wall. I am working on a fan-type effect, where I want to cache out a smoke object, then use that cached simulation to advect some particles. But I want to be able to animate the position and rotation of that fan. So I want to simulate the 'airflow' of the fan at the origin, cache that, then move the resulting cache around in my scene and have it blow the particles around appropriately. However, just transforming the cached velocity fields, then reading them into DOPs with the gas advect particles node doesn't have the expected effect. At a guess, it seems like the container is being transformed, but the cached velocity vectors aren't being transformed. So turning the fan to face left instead of right makes the particles to the left move, but they move in the wrong direction. I've attached an image that illustrates what happens--which is quite strange. This happens whether I rotate the object at the object level or the SOP level. Any thoughts on how to approach this? Thanks for any suggestions!