Jump to content


  • Content count

  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won


madebygeoff last won the day on May 15

madebygeoff had the most liked content!

Community Reputation

21 Excellent

About madebygeoff

  • Rank

Personal Information

  • Name
    Geoff Bailey
  • Location
    Brooklyn, NY
  1. Fun! My dog would love it... tetherball_v01.hiplc
  2. IK solver mayhem

    It's a bug or something related to your project file and for the life of me I can't figure out what. If I use your project file, even if I rebuild the joints with a skeleton SOP I get the same (lack of) behavior. If I start a new project and do the same thing, it works. Changing the rest angle mode to "Compute from targets" should snap the curve shape to the original shape. For some reason it isn't working in your project. And I have no idea why. Sorry I can't be more help. You might want to reach out to sidefx directly and see if they can locate the bug. It's not directly related but in the past I have had conflicts with parts of KineFX and other 3rd party frameworks. For a month or so the skeleton node didn't work whenever I had Renderman installed. Worth talking with them. There's still some ghosts in the machine with KineFX.
  3. Should work as Atom said. Maybe post a scene file if you're still having trouble.
  4. IK solver mayhem

    What version are you using? I seem to remember something in one of the masterclasses about an update to the IK Solver VOP. When I try it in 19.0.383, I get the behavior from your file. When I try it in .531 or later, it works.
  5. IK solver mayhem

    This isn't a full solution, but I tried it in a new file and the solveIK VOP works. It gets a little unstable as the number of joints increases (I'm getting flipping as the joints compress). But it works. The weird part is that when I try to duplicate the same thing in your file, it doesn't work. I'm not exactly sure why yet. Still looking into it. But try opening up my file and see if you get the behavior you expect. IK_multi_joint_v01.hiplc
  6. Drive bone rot by another bone rot

    And thanks to a little help from @mestela, here's a pass at a VEX version. I was lazy and just looped through each joint and applied the previous joints transform according to a single bias. If you want each joint to have its own bias, you could code things a little different. Again, I haven't tested it fully, but hope it helps: #include <kinefx.h> int start_ptnum; int pts[]; float bias; matrix parent_localxform; matrix parent_rest; matrix descendant_xforms[]; matrix descendant_localxforms[]; matrix descendant_efflocalxforms[]; matrix offset; start_ptnum = chi("Start_point"); bias = chf("Inheritance_bias"); parent_localxform = point(0, "localtransform", start_ptnum); parent_rest = point(0, "rest_transform", start_ptnum); offset = parent_localxform * invert(parent_rest); updatedescendanttransforms(0, start_ptnum, -1, matrix(), matrix(), pts, descendant_xforms, descendant_localxforms, descendant_efflocalxforms); foreach (int i; matrix descendant_localxform; descendant_localxforms) { descendant_localxforms[i] *= slerp(ident(), offset, bias); } setpointlocaltransforms(0, pts, descendant_localxforms);
  7. KineFX translating VOPs to wrangles

    Thank you, Matt! I knew I was missing something stupid like that. So many useful functions buried in there!
  8. So I've been trying to convert a few Rig VOPs I've built to VEX. Partly to see if they run faster and partly just to understand what is happening under the hood. But I'm noticing that if you expose the VEX of a certain VOP, there are a bunch of commands that don't show up in a wrangle. For example: blendtransforms(). There's a blend transforms VOP and if you look at the VEX it uses a blendtransforms() command in VEX, but if you add a wrangle there's not such command. Is there some library I need to add or am I missing something?
  9. Drive bone rot by another bone rot

    See if this helps. I've got 2 VOPs in the script. VOP 1 extracts the rotation from the local transform matrix of the parent joint and subtracts it from the extracted rotation of the rest position to get the amount the parent joint has rotated, then scales it and applies it to the child joint. VOP 2 uses the matrices directly. It's a little less obvious, but it's something I did to try to understand better how to manipulate matrices (any suggestions are welcome). It's the same basic procedure but handling the matrices is a little different. In order to the get the difference between the parent joint and its rest position, you multiply the joint's local transform by the inverse of the rest position, then multiply it with the child joint local transform matrix. The bias is set with the blend transform VOP (I haven't found a way to limit the rotation matrix to something like .5 or .25 directly). Haven't tested it fully, but it should be a start. inherit_rotation.hiplc
  10. How can I reverse rigdoctor?

    KineFX uses vertex order to set hierarchy. A reverse SOP will flip the hierarchy. Make sure it's wired in before the first rig doctor. Once you add a rig doctor, additional attributes are added that define parent and child indices and local transforms are calculated using that hierarchy. Adding a reverse SOP after that won't have any effect.
  11. A little more info on what you are trying to accomplish or a scene file might be helpful. There's quite a few ways to do what you ask depending on the final result. Are you looking to animate lots of bones or orient them for rigging? You could simply set a group and in a rig wrangle use the rotate or prerotate commands. Again it depends on how you want to rotate the joints. A screenshot or scene file would help with your last question. If you rotate a bone with a rig pose it usually shows up in the properties window as a local rotation in degrees.
  12. What Is Time Scale, Really?

    Time scale does in fact just change the length of time step the solver uses to compute each frame. So a time scale of 0.5 should run half the speed of a simulation at time scale 1.0. The problem is (and off the top of my head I think different solvers behave differently) you often need to adjust your forces by the same scale to get the same result (only slower). I know Bullet works this way. If you drop your timescale to 0.5 you also need to cut your gravity and any other forces being applied by 0.5 as well. My recollection is (and I might be wrong on this) is that some of the newer solvers like the vellum solver take that into account. If you drop the timescale to 0.5 in vellum I seem to remember that you do in fact get the same sim only slower. I'm not at my workstation to check, but someone can chime in if I'm wrong.
  13. Is there a way to paste mirrored keyframes?

    I don't believe there is anything as simple as the Blender set up. There is mirror rig pose node that you can use with a few stash pose or timeshift nodes to mirror various poses. Since a walk cycle is fairly short, you could probably make it work, but it is not as simple as copying and selecting pasted flipped. Something like that I think would have to be scripted. There was a thread a while back (before Kinefx, so object level rigs here) on a python tool that did this. Could be a decent starting point. https://www.sidefx.com/forum/topic/45527/?page=1#post-207336
  14. You can try a Motionclip Extract SOP. You can set it to create motion trails for each joint, which you can then manipulate like you would any other geo in Houdini. You could smooth the path. You could use a wrangle to set v@P.y = 0 and lock that joint to the ground plane, etc. You can then either MC Blend or MC Update the original motionclip with the updated joint.
  15. Too early for 3rd renderer? (Prob. Redshift)

    Not everyone will agree, but to me renderers are renderers. They're not THAT different, at least when you're starting out. For learning, go for the fastest one you can afford. Redshift and Octane are both solid choices with lots of users (for support). If you're mainly focused on self-education (as opposed to production jobs) and you don't want to spend the money, Karma is also included and is a fast GPU renderer. It's still a little buggy and not fully featured for production, but you can do tons of great stuff with it for free. Once you understand the basic principles of one renderer it's not that hard to transfer that knowledge to another renderer. And over time you start to learn the strengths and weaknesses of each. There ARE differences between renderers, but the are usually fairly specific and exist in small details. At a certain level of work, those details become really important, but for a lot of work, faster is always better.