Atom
-
Content count
3,441 -
Donations
0.00 CAD -
Joined
-
Last visited
-
Days Won
119
Recent Profile Visitors
13,463 profile views
-
As far as I know, there is only one valid case where you actually need to use the Hero RBD object. That case is if you want to have the object float upon the flip surface. If you can work with packed objects, you might want to go with that. I agree with your observation, though. I can't find any way to alter the velocity beyond the initial velocity.
-
Thanks. I was able to get what I need using MOPs, but your solution works too!
-
A simple, robust setup for vellum and bullet interaction
Atom replied to KarlRichter's topic in Effects
While it's not super critical, it does seem like the collision version of the objects lag behind the actual location of the RBD objects in the simulation. I tried adding a time shift $F-1 and $F+1, but that didn't seem to fix it. -
Animating input temperature for pyro source spread node?
Atom replied to bxz4's topic in General Houdini Questions
It seems to work for me. Just make sure that when you animate the box, that the group points are still being created. If you are scaling the box, make sure your centroid is correct. -
If you've worked through a tutorial and want to share your HIP file with the community, post it here. I completed one where Mikael Pettersen demonstrates how to create a Blendshape crowd agent. ap_mp_blendshape_crowd_character_052120.hiplc
-
On the Smoke Object node, disable sparse solving, and enable max size. If you're using an older DOPs system, disable the Gas Resize Fluid Dynamic node.
-
Get random but connected points on a geometry
Atom replied to cur10us's topic in General Houdini Questions
Well, they are all connected, right? You mean connected by a certain vertex count? You could select a bunch of random points, then throw away the ones that fail the neighbor vertex count test. https://www.sidefx.com/docs/houdini/vex/functions/neighbourcount.html -
My guess is that your simulation continuously expands. That means you will always run out of ram. Disable the continuous expansion of the domain and lock down the domain size. This will result in clipping near the edges where density meets the borders. Consider increasing dissipation to remove density before the smoke reaches those edges. I don't think Blender supports motion blur for volumes yet IDK, so you may not need to write vel.x, vel.y, and vel.z to disk. Save some file size and turn them off during final export. Or kick out .sim files first, and try continuing the simulation a frame before the crash.
-
Inspect the geometry to make sure that v@v is something other than {0,0,0}. You may have to unpack it to expose that attribute.
-
Houdini Engine Plugin for Unreal 5 as an alternative to multiple FBX imports
Atom replied to mystyphy's topic in Games
Have you tried Alembic? -
What about something convoluted like this? Use an input to bring in the volume, merge packed results, then pack the result and unpack it at the top of the loop..? Not sure if this technique works, but you can switch based upon iteration. Every iteration past the first one should supply the merged result. Now that I look at this some more, the switch should probably intercept before the unpack, so you can filter the volume with a blast or delete node.
-
On the popsource birth tab type "justborn" into the justborn field. Add a delete or blast node after the popnet and filter by the justborn group. Delete non-selected to keep newly generated points.
-
Try moving the popgrain node after the popwrangle. This way the pscale you have calculated can be taken into account by the particle separation algorithm of the popgrain node. Also, try animating the seed on the popsource so you aren't generating the same point set each time. My guess with your current setup is separation occurs, then pscale is generated. This causes a momentary overlap that the popgrain node repairs on the next frame. This is probably what causes that jumping action. By solving separation after scale, you should be able to avoid or limit that.
-
Hmm, weird. Here is a mantra scene where I am rendering with 10 million pig heads on a 32Gb system. I'm only consuming 8.6 gig of system memory, and no crash. One thing I highly recommend is pressing the D-KEY and lowering the viewport instance number from 100% to 0.1% on the Geometry tab. I also set the Stand In geometry to Display OFF. There really isn't much of a reason to leave a 10 million particle display on, unless you are planning a camera move and need to navigate through them? Maybe the graphics card is being overloaded and is leaking/consuming memory? ap_instance_ten_million.hiplc
-
There may be holes in your polygon mesh, or non-fused points. Try dropping down a polyfill and choose single polygon fill mode before your vdbfrompolygons. After that, if you still have holes, you may need to reduce voxel size on the vdbfrompolygons until they disappear. For a shape like you have shown in your reference, I might be tempted to construct a low poly proxy mesh to serve as the collision object. The higher resolution you need for collision, means the higher resolution you will have to push the fluid simulation. This can increases the simulation time. It's worth the effort to simplify your collider unless the shot specifically requires an up-close interaction with the "hero" collision object.
