ziconic
-
Content count
23 -
Donations
0.00 CAD -
Joined
-
Last visited
-
how to access collision data of DOP network for a geometry Wrangle node and sopSolver
ziconic replied to tagosaku's topic in Effects
In the Geometry Wrangle case, you can set up a Field Binding to access the value of the collision volume in the wrangle. Go to the "Data Bindings" tab, add a Field Binding for the "collision" field and set the VEX parameter to "sdf". In your wrangle code, remove the f@sdf = volumesample(...) line (since @sdf is now already bound for you). Also, change @sdf>0 to @sdf<=0 because, well, DOPs uses a different convention for designating where the "inside" of a collision volume is. As for the sop solver case, you can duplicate the existing dop_geometry node and change its Geometry Data Path to "collision" to read the collision field as a volume. You'll still need to add a wrangle to check if a point is inside or outside of the collision volume though.- 3 replies
-
- 1
-
-
- sop solver
- delete insdie of collision
- (and 3 more)
-
Many workflows you may consider "fundamental" have changed since many of the courses were made, e.g. copy stamping is now discouraged, VEX is much more widely used now. I would recommend learning Houdini using current tutorials so that you know how to get basic things done, and then go back to older tutorials as needed to pick up the occasional production tip or trick.
-
Btw I don't recommend watching any of the Houdini fxphd tutorials that aren't tagged "Recent Release" if you are just starting out with Houdini. Most of their Houdini courses were made years ago, and many of the core nodes used in those courses have changed substantially since. (On the other hand, many of their Nuke courses are still current and quite good.)
-
Using the Bullet solver should work. Make sure that you aren't using packed objects though, as packed objects cannot interact with the FLIP solver (https://www.sidefx.com/docs/houdini/nodes/dop/rbdpackedobject.html). Also make sure that you have set Feedback Scale on the FLIP solver to a non-zero value.
-
[SOLVED] Emitting multiple vellum objects with custom velocity
ziconic replied to curv.u's topic in Effects
Umm you are assigning a random velocity to every point on your geometry, which will average out to a forward-ish direction for the entire pig head as soon as the sim runs. What you want to do is set the same random velocity on every point of the geometry. To do so, change the attribute class on your Attribute Randomize node to Detail. Then add an Attribute Promote node immediately after it and "promote" the v attribute from Detail to Point. Now, every time a pig head is emitted, all the points on the pig head will have the same velocity, but will be different for each pig head. -
Getting bad results with rest on Fluid Emitters (Texture Mapping Fluids)
ziconic replied to HappehLemons's topic in Effects
Well you'll probably want to use one of the UV sops like UV Project to convert your rest position to uv, rather than setting @uv to @rest directly. To do so, you'll have to save @P to some custom attribute, copy @rest to @P, use your UV sop of choice to generate your uvs, then restore @P from your custom attribute. -
The Debris Source node works by scattering points over your pieces, and, for each point (ptnum), finding another point (__otherid) on a different piece to track. Once the distance between the two points exceeds a certain threshold, debris is emitted. If both points are the same, then debris is never emitted from that point.
-
Getting bad results with rest on Fluid Emitters (Texture Mapping Fluids)
ziconic replied to HappehLemons's topic in Effects
Well if your fluid shape doesn't change drastically after the rest attribute is set, you'll get better results. For example, if you change the emitter to a tube instead of a sphere, the uvs will look better as the fluid flows downward since it's a better match for the fluid shape before it hits the ground. You should also look into reducing Frames Between Reset on the FLIP Solver so that you aren't trying to smear out your rest position over a surface that looks very different from what you started out with. -
In your simplified example, the reason debris isn't being emitted is because you set the rest frame of the Debris Source node to a frame that doesn't have any geometry. You need to pick a frame where all your pieces are present and still stuck together. @__otherid needs to be set to something other than @ptnum for debris emission. @__otherid is the point the distance to which is tracked to determine if debris should be emitted. When @__otherid is the same as @ptnum, it means we failed to find a corresponding point to track for @ptnum.
-
It doesn't look like your sim even works without the constraints, so I would suggest fixing that first. You are missing a SOP solver attached to the rbdsolver that will change @active to 1 when @activeFrame is reached and set the @v and @w values you defined outside of the sim. The SOP solver attached to the constraint network can do the usual thing of using a primitive wrangle, examining the attributes on both points that are part of each constraint, and deciding if the constraint should be broken by setting @group_broken = 1.
-
Hard to tell for sure since you didn't include any geometry in your file but one place to check is whether your search radius for the Debris Source node is appropriate for the scale of your geometry. It is possible that Debris Source wasn't able to find a nearby point that it can use to determine if two adjacent pieces have separated. Check the output of the "find_closest_from_other_piece" node in Debris Source and see if @__otherid is actually being set to something other than @ptnum.
-
Lol that's a weird looking sim. Your buoyancy scale didn't end up becoming negative, did it? It would probably help for you to post your hip file.
-
You are running a pyro sim, which by default aims to make the velocity field divergent free. The velocity field that you have set up is clearly not non-divergent. You are trying to push all the smoke toward the center (i.e. the field's divergence is strongly negative in the middle). So when the pyro sim tries to make the velocity field non-divergent, it has to modify the velocity field near the middle to push the smoke out and away from the center. What you did by specifying the target divergence field is correct. You are telling the pyro sim to make the velocity field's divergence negative in the middle, rather than zero everywhere, which will give you the effect of pushing the smoke toward the middle.
-
Thanks for sharing your setup! One thing it made me realized was that, in addition to having a sufficiently small particle separation, turning *off* "Solve Pressure With Adaptivity" can help prevent air bubbles from collapsing. Btw what was your motivation for using the gas vortex confinement DOP? Was it to help break up the bubbles even more?
-
If you are looking for something out of the box, you can try the "enable air incompressibility" option in the FLIP solver, as described here: https://www.sidefx.com/docs/houdini/fluid/bubbles.html Note that I had to turn on viscosity and surface tension to prevent the air bubbles from collapsing right after they are born.