Atom

Add a switch to your material network and drive it from an integer attribute. There might be a limit on the number of connection you can make.

Another thing I've done in cases like this is to sort source and targets points along the same axis. Divide your VFX points in half to have each crowd group seek only those points. Less crossing another's path and triggering wander/avoid.

I've done this before by setting up a render loop, which is essentially a PopWrangle that executes every frame. Inside that wrangle add code to measure the distance between the current location the goal. Once that distance is small, you know the agent has arrived, and can trigger a new state.

I would suggest your secondary goal needs to become the primary goal after a battle is completed. Wander is a problem, I'd turn it off.

Another reason to place POSTs before TOPICs is that you end up at the top of the thread when you click TOPICs. Personally, I want to see the last reply, which is what POSTs does. When the topic gets long, it's kind of annoying to have to navigate through the pages to get to the end to see the last comment.

My guess is that is the results of ACES color management mangling your output. The simplest fix is just use Karma, which seems to render a 1:1 color result when you specify 8-bit PNG. ACES is intended only for 16 bit half-float EXRs. When rendering to a format other than that, ACES becomes a "looks" package, changing 8-bit output. ap_karma_rgb_test.hiplc

Hmm, I'm not seeing that in H19.5.435. Can you post an example HIP? This HIP generates a high resolution VDB, caches it and then animates the cached frame. I receive no upstream cooks during this process. ap_vdb_verify_upstream_cook.hiplc What if you tried something like this as a workaround. Link a two-state switch to the Load File Cache switch to force everything upstream to essentially be a NULL?

Is there any way to have the right column POSTS show before TOPICS? It seems more useful, at a glance, to see the last reply on top, rather than having it off screen. Moving the number count from TOPICS into POSTS would be a nice addition. Then you wouldn't need that TOPICS right column at all.

Another fun one to play with. If you alter the Gas Calculate to divide the gradient against pressure, the smoke becomes less contained as it becomes more curvy.

@uakinThanks for the setup tips. I've never tried to modify temperature after the fact. What I discovered is that if you omit the temperature field or initialize it with zeros, the Gas Calculate Multiply produces nothing which makes sense. Value times zero. Playing around with the other settings I discovered without a temperature field, a blank one is generated. When I set the calculation method to MINIMUM, the minimum curvature value is supplied as the temperature, and quickly falls in on itself producing a weak bubbling pool or incipient geyser. Could work for bubbling pot, too.

Try the mtlxTiledImage. It seems to work for me.

Unroll the Save triangle under the Advanced tab. Try activating Initialize Simulation OP. That might guarantee an upstream cook. Is your ropFetch targeting the hallwayFlood node?

With FLIP you never use surface collision, that's for RBD. FLIP always uses volume collision. You're viewing your collision wrong. Collision is the purple color, you have to activate it under the Guides tab of the FLIP Object. What you're showing us in your screenshot is the VDB conversion. Flip converts it once more by resampling it to your particle separation value. That's what the true collider looks like and the guides tab will show you.

Cool, it works with fonts too.

It seems to work with animated curve sets as well. lib_flip_curve_follow.hipnc

Extend your popwrangle code to examine the @hitnum attribute as well. Store the time in a new attribute. Time is in seconds, so you'll have to convert it to a frame based upon your current FPS. Something like... if(@hitnum==1){f@first_hittime=@hittime;}

I think your assumption is right. It looks like it is a divisor deciding whether or not to reseed on a any given frame. If you set it to 5, the reseed will only happen every 5 frames is my guess.

If you're just doing vines across a body, you might want to use the ray node to project the underlying curves onto the body, then generate the mesh along those conformed curves. This approach might preserve the volume of the mesh a little better as well.

Maybe check out this link.

This one still seems to work in H19.5.

I worked through the meteor shower tutorial today. The tutorial used Mantra rendering, but I set this HIP file up for OpenGL and Karma output. OpenGL on the left and Karma on the right: ap_tut_meteor_shower_111622.hiplc

Check out the help card on the vellum source node. You can change the emission type to every frame then control activation via modulus just like RBD.

There are a couple of things you can try. In the houdini.env file bump up the max texture resolution. KARMA_XPU_MAX_TEXTURE_RES = "4096" On the Image Output/AOVs (Render Vars) tab set the Pixel Filter Size to zero. I have experienced improvements with these settings, but Karma doesn't give you a 1:1 crispness compared to the original texture.

I installed the two wrangle, and I'm getting some action, but it doesn't really look like my supplied heart shape. Can you recommend any settings for the two wrangles? ap_lib_infinite_knot.hiplc

One parameter you can play with, which drastically reduces the initial mushrooming effect, is Cooling Rate. Try setting it to 1.0. ap_smoke_steam_whistle.hiplc