Jump to content


  • Content count

  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won


Everything posted by madebygeoff

  1. FLIP-Fluid and a vellum interaction, how?

    Similar thread a few weeks ago. His project might be a starting point.
  2. RBD issue: How can I bring them to stop?

    Really recommend Jeff Wagner's talk on RBD collisions. I switched from VDB to surface and lowered the collision padding a touch to .01. That seems to work. RBDs_02.hipnc
  3. RBD issue: How can I bring them to stop?

    Are you sure your collision box is set up properly? The default setting uses a convex hull operation to simplify the incoming collision geo. Normally that will create a solid box, so your objects (which are inside the solid box) are constantly intersecting with the collision geo creating a solve that is mathmatically impossible, creating jitter. Try setting the collision type from "convex hull" to concave. Search "Houdini RBD jitter" for endless discussions of this. There's also a good masterclass that Jeff Wagner did a while back all on collisions that is very helpful.
  4. How to break one vellum constraint from a batch

    Vellum Constraint Properties has a group field at the very top. Just set a constraint group for the lapel constraints. You can do that in the "output group" field if you setting them will a Vellum Constraints node. Or you can select them directly by piping a primitive group SOP before the second input of the Constraint Properties. Then just set the group field in the Constraint Properties SOP.
  5. Guided Ocean vs Wave Tank?

    I'm not an expert on oceans, but I've been trying to get up to speed for a new project. The way I understand it: Guided Ocean - waves are formed primarily from the ocean spectra with a FLIP sim of a thin layer of particles riding on top of the ocean spectra. This means that the spectra take priority in shaping the look of the ocean and the depth of the sim is limited. That's why the link above says it is best for shallow objects like a boat (or a sea otter) moving through an ocean, where the ocean waves are the primary thing determining the look of the ocean. Flat tank - is a completely flat FLIP tank where you can add back in some of the high frequency spectra at render time to blend the sim with the surrounding ocean. Best for interactions where the interaction of the sim and colliders is the dominant thing determining the look of the ocean in the area of the sim. Say a monster (or a radioactively enlarged sea otter) trashing about in the water. The waves are pretty secondary here in determining the look of the sim compared to the monster thrashing. You might just add back in some of the high frequency ocean spectra for blending but its your monster (or giant otter) doing the work. Wave tank - is a FLIP tank where the initial state is derived from the ocean spectra and from there it's a full-blooded FLIP sim (although you can blend back in spectra as above if you want). A big wave crashing into a lighthouse is what I think of here (no ideas how to use an otter with this one).
  6. Any luck? On my laptop I get 50-60 fps on playback with or without the blend turned on. Seems ok to me. The frame rate only drops for me beginning with the fullbody IK. But that's because the full body IK is fairly expensive.
  7. how to connect skin in houdini rigging

    Parker Coleman has been doing some useful tutorials on Kinefx. So has someone named Brundlethwaite. https://www.youtube.com/channel/UCyyag6ACaTjcZrdHzfl-q4g/videos?view=0&sort=dd&shelf_id=0 https://www.youtube.com/channel/UCyyag6ACaTjcZrdHzfl-q4g/videos?view=0&sort=dd&shelf_id=0 But I'll say if you are new to Houdini, I'm not sure I'd recommend using it for keyframed character animation. Personally I think kinefx is exciting and is a welcome change to how to think about rigging. But it's still in the early stages and SideFX has concentrated initially on the motion capture workflow. You can build rigs and animated by hand, but it's not very intuitive yet and takes some deeper knowledge of how Houdini works to get it to work properly. Plus, since it's new so as you have probably found out, there's not a ton of great tutorials. There's the two above, Jeff Wagner did a good masterclass and Rok Andic has been doing some good tutorials. Good luck.
  8. Not exactly sure what you're after, but there might be a simpler way. Can you explain what you are trying to do overall? Is this something that might be better accomplished with something like a point deform? Could you use the point cloud or whatever mesh you are simulating as your point lattice and the original geo as your deform mesh? If it's the movement you're trying to keep, that might be simpler. And why are you feeding just points into the vellum solver? Maybe there's a way to fix your original mesh to give you want you want?
  9. Divide SOP to create single point in Quads

    Run a primitive wrangle: int npt = addpoint(0, v@P); setpointgroup(0, "center", npt, 1); For each primitive, add a point (npt) at the current primitive's position (which is the same as its center point) and add that point to the group "center"
  10. vellum sim causes jumpy faces

    Generally jumping like that is because the solver is trying to solve two conflicting settings that make a stable solve impossible. The two most common: The thickness of your cloth is too high. If you turn on "visualize thickness" you should be able to see the size (pscale) of your individual points. If the spheres in the visualization are overlapping, the solver will try to move those points apart, but since you have a really high stretch stiffness, it can't, and you'll get jumping. Change your thickness settings until they don't overlap. Another reason could be that your cloth is settling down on itself and compressing various parts of the mesh and the high stiffness isn't allowing it to settle properly. Usually this requires lowering the compression stiffness. A bend stiffness that is too high can do something similar in areas that are bending and creasing, but you've got yours set pretty low, so I don't think that's it. But it could also come from some other constraint like a pin to target or attach or stitch constraint that is conflicting in some way. The best thing to do is go through the visualizer and try to see what might be conflicting.
  11. Vellum fluid and cog wheel

    Yeah, you'll have to get a little creative with the COG. A few thoughts off the top of my head: 1 -- The first is to add a static collider that fits inside the interior or the cog. Make a hole in the center of the cog and then run a tube through it, kind of like an axle running through. Then make that a collision object. It'll work, but now you've added another object to your sim, adding time and an opportunity for simulation weirdness. 2 -- Vellum respects pretty much all the POP attributes. There's called "stopped" that will control the movement of points. If you set it to 1 for instance (i@stopped = 1 in a point wrangle), your point will rotate, but stay fixed in space. Maybe you could make another object, let's say call it "cog_pin", make it a single point and set i@stopped = 1 on that object/point. Then constrain your cog to that point. But getting the constraints to work properly, so that the Cog still turns, but doesn't fall. would probably be a pain in the butt. https://www.sidefx.com/docs/houdini/vellum/vellumattributes.html 3 -- Now that I think about it, maybe if your cog geo had a single point at its center, you could stop just that point. The fluid would interact with the rest of the geo, that point wouldn't translate in space, and the shape match would hopefully hold the whole thing together?... Or your simulation may explode with conflicting forces 4 -- Once again, I'd probably just animate the wheel to do whatever it is you want it to do and then sim the water on top of that... Not the answer you are looking for, but it'll work.
  12. Vellum fluid and cog wheel

    There should be, I think, but I haven't had time to really play with the new vellum constraint types in 19 so others might have better tips. And right at this moment, configure fluid seems to crash Houdini... but... Obviously, you could hand animate the cog and then use it as an animated collider object. Honestly, that's probably what I would do unless you are doing something fancy with the way it interacts with the fluid. Easier to fake it. But, if you want them to interact, you *should* be able to add the cog as a rigid body to the simulation and they should interact. Instead of wiring it in as a collider, add a vellum constraints SOP set to "shape match" after your polyfill and then merge together both the GEO and the CONSTRAINTS with those coming from the vellum fluid and add the results to the solver. You'll probably have to play with the masses and find a way to pin the cog so it doesn't fall down. But it should work...
  13. facet vs normals?

    The normal SOP really does one thing and one thing only. It calculates normals and sets the cusp angle. I think of the facet SOP as more of a multi-purpose clean-up tool. First and foremost, it allows you to control how points are shared or not between polygons. Are points shared between adjacent polygons or are they kept unique per polygon. It then adjusts the normals based how you would like them to be calculated. Normals is primarily about calculating normals. Facet is primarily about consolidating or unique-ing points and calculating normals can be done before or after that process. That said, there is a lot of overlap.
  14. Redshift alpha problems

    Also, take a look at the sprite node: https://docs.redshift3d.com/display/RSDOCS/Sprite+Node It's meant for exactly this. You'll get better performance than jacking up the max trace depth and avoid some potential artifact-ing.
  15. Bullet pieces "shivering" without stop.

    Interesting... In addition to scaling up the geometry of the scene, you'd also multiply all the forces in the scene (including gravity) etc.? I'll have to try this.
  16. Bullet pieces "shivering" without stop.

    Scaling the sim can help (since by scaling the scene you're bringing your velocity levels up above the default thresholds), but it comes, obviously, at the cost of changing the scale of your scene. You're now running a sim on a scene 10 times as large and it will look it. Sometimes that's fine and for stylized stuff it might be preferable. But it's not accurate. It might be fine, but just be aware. If realism is the goal, it's usually better to run sims of scenes built to the proper scale and to find the right velocity threshold and sleep pieces below it (which I think is what is the video above).
  17. Houdini 19 Resample SOP issue...

    The Resample SOP hasn't changed. It's the curve tool that changed in 19. It now draws Bezier curves by default, which have curves defined by the tangents of their handles. It looks like the Resample node is respecting those tangents and trying to match the incoming curve and as a result the various resampling modes have less of a difference than before. If you want the Subdivision Curves setting to work like it did before, you need a curve without the Bezier tangent info. You can create the curve in "Polygon" mode. Or convert from a Bezier curve back to a polygon (polyline) with either a Convert SOP or low-freq Resample. Then the Resample SOP should behave like you expect. Resample Curve.hipnc
  18. In kinefx, joints are just points. You can do anything to them that you can to points. It's a bit different approach than other programs, but liberating once you can wrap your head around it. So one way is simply to use the world transforms of one hand as the world transforms of the other. In the file below, I just take the world transforms (the position and rotation in world space) of one hand and literally set the other hand to use the same transforms (with an optional offset) in a VOP. Then just use that as the goal for a simple IK chain. In this example the hands are a bit far apart so the arm gets a little over-extended, but you should get the idea. Finally, for good measure, I run it through a full-body IK. For the second, there's lots and lots of ways to do that. You could use a motion clip SOP to convert the mocap into a static point cloud and then just use various SOP tools or CHOPs to smooth it out. But if you want to try to clean it up by constraining, you could try something similar to the approach above. I just grabbed the pelvis joint (which was pretty stable) and constrained the hand to that with another offset. You could do all kinds of things like taking a few points and averaging them or using the points of a curve as targets or bring in a totally different clip that doesn't have the jitter and blend them together... Anyway, hope this is a start... The mocap I used is the Thriller Part 2 dance from Mixamo if you want to pipe it in. kine_constraint.hipnc
  19. Renderman breaks KineFX?

    Just to clarify. It's actually ONLY the skeleton node. Nothing else. Rig Pose and Rig VOPs viewer states seem fine.
  20. Renderman breaks KineFX?

    Have RM24.2 installed with 19.0.383. When RM is installed, you can no longer fire any of the python states in kinefx nodes. For instance, if you select a skeleton node and hit enter in the viewport, nothing happens. As soon as I remove RM, it works normally. Anyone else experience this or know a work around? I read that in the past some people had problems with Octane disabling some KineFX nodes. Not sure if this is something similar.
  21. Offset Bone Animation in a KineFX Rig

    I came back to this working on another problem. It's simple, but deceptively tricky, and is really useful for understanding how kinefx uses the world transforms and local transforms and how to go about manipulating them since the rig VOP, in particular, is a bit counter-intuitive. So in addition to the above, I also updated: -- A rig VOP running in its "proper" detail mode. It uses a for-each loop to add in the rotation of the first joint to each child joint using the very handy "Get Descendant Transforms" VOP. You can also use a for-each transform loop, but you have to hack it a bit to get access to the rotation of the first joint inside the loop. -- In addition to the Rig Wrangle driven by a value, I added a version driven by the rotation of the first joint. I cheated a little here by manually setting the loop to run over the child points only. -- And finally, I added a version that has a recursive FK rig where each joint's rotation is added to all its child's joints. This is a pretty common setup in other programs, but took a bit of work to get it functioning as expected. It's not a production-ready set up, but it has the functionality. tail_v03.hipnc
  22. I don't think the point count is shifting. It looks stable to me. Unless, I'm misunderstanding your question, the problem is that you are only transferring the curve normals in your attribute transfer. You also need to transfer the up vector. Right now N is being updated, but the points are keeping their original up vector so you start to get flipping as the points move around the curve when those vectors become the same vector. The other thing that is contributing to the steppy-ness is the low point count on the curve you are using for the attribute transfer. If you resample the curve you'll get smoother motion. pointsTest03.hipnc
  23. Can you explain where you are running into problems? Or post a small scene? Both the Labs Measure and regular Measure node do what you are asking. See file below. The regular measure node outputs a curvature attribute from 0 (concave) to 1 (convex). The Labs node outputs 2 separate attributes: one for convexity and one for concavity. measure.hipnc
  24. This is getting into the dark rabbit hole of how Houdini stores its capture weights and I admit, I don't fully understand it. One thing you can do to start to reverse engineer it is just make a simple capture set up with the bone proximity node and then unpack it and take a look at what happens. Try adding a capture layer paint and mess around with the weights and then see what happens after the unpack. I attached a simple scene below. I think that 20 element array is a weird 4x5 matrix that is holding info about the skeleton points and their associated capture regions. It's basically a 4x4 transform matrix of each point/joint in the skeleton, plus an additional 4 elements that hold information about the size of that joint's capture region. Since in Matt's example, he starts with 18 points/joints all at the origin with the same orientation, the matrix is essentially the same for each joint. If you want to dig further into it, you can check this out: https://www.sidefx.com/docs/hdk/_h_d_k__geometry__capture.html Or maybe @mestela can weigh in? I'll try to dig into it a bit more tomorrow and see if I can help more. simple_capture.hipnc
  25. show trajectory

    ^^ That's a cool use of the motion clip. The nice thing about that is that then you can actually use all kinds of things to make procedural changes to the animation path. Kind of obviates the need for CHOPs in a lot of situations, which I have to admit, has always kind of baffled me. But based on your comments above, I'd try the rig pose trick for more manual animation. It does exactly what you're looking for and has a few handy animation tricks: you can add/delete and move keyframes as well as adjust the curve all from within the viewport. It makes animation in SOPs more similar to what you'd be used to in another app. If you mix it with the trail SOP or the motion clip trick above, you've got a mix of motion paths and onion skinning as reference... or you could turn on onion skinning in the "misc" tab of the geo node. It will still show up when you dive back into SOPs. Unfortunately right now you still have to copy your geo back to the animated point/joint, but that's not the end of the world.