Jump to content

toadstorm

Members
  • Content count

    297
  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won

    16

toadstorm last won the day on May 9

toadstorm had the most liked content!

Community Reputation

189 Excellent

About toadstorm

  • Rank
    Illusionist

Contact Methods

  • Website URL
    http://www.toadstorm.com

Personal Information

  • Name
    Henry
  • Location
    San Jose, CA

Recent Profile Visitors

4,474 profile views
  1. MOPs: Motion Graphics Operators for Houdini

    Hey friends! It's been another long while since the last Stable release, but I finally have a new one available. The changelist is pretty big so I'll only link to it here, but there are a few new toys to play with, many modifications to existing ones, and a TON of bugfixes and reliability improvements. I hope you'll spend the time to take a look! https://github.com/toadstorm/MOPS/releases/tag/v0.1.52 As always, any questions, comments, feature requests, or donations are immensely appreciated.
  2. Ah I misspoke about qLib, I forgot that they use the nonstandard otls/base, otls/experimental subdirectories. You'd still have to manually define HOUDINI_OTLSCAN_PATH to find these.
  3. animate normal like sea ​​urchin

    you just need to add the scaled curl noise vector to your N, then normalize afterwards. Normal_Animate_toadstorm.hip
  4. You shouldn't need to redefine QLIB or specifically define HOUDINI_OTLSCAN_PATH using this method; because the base $QLIB path includes the /otls, /gallery, /scripts path internally, all you need is the HOUDINI_PATH definition that includes $QLIB and you should be good to go.
  5. Rather than define the individual HOUDINI_OTLSCAN_PATH, HOUDINI_GALLERY_PATH, etc, if your individual plug-ins all have the default internal directory structure separating /otls, /gallery, /toolbar, etc., then you should only have to append these things to HOUDINI_PATH for everything to work together. You're defining HOUDINI_PATH at least three times, without actually appending anything to the path each time (by including the existing $HOUDINI_PATH in those later definitions). You just want one HOUDINI_PATH that includes everything. You can do it with multiple definitions if you like, you just have to remember to append rather than redefine. For example: MOPS="C:/Users/Terence/Documents/Houdini_MOPS/MOPS-0.1.36" AELIB="C:/Users/Terence/Documents/houdini17.5/Aelib-master" QLIB="C:/Users/Terence/Documents/houdini17.0/qLib-dev" MEGA="F:/MEGASCANS/support/plugins/houdini/3.0/MSLiveLink" Then, construct your HOUDINI_PATH by appending all these paths to your existing HOUDINI_PATH: HOUDINI_PATH=$HOUDINI_PATH;$MOPS;$AELIB;$QLIB;$MEGA;C:/ProgramData/Redshift/Plugins/Houdini/17.5.173;& This way you don't need any of those other definitions at all, except of course the PATH variable for including Redshift plugins. By the way, that "&" at the end is a shortcut meaning "Houdini's default search path". It's recommended to include this at the end of your HOUDINI_PATH definition, but only include it once! If you're going to define HOUDINI_PATH multiple times using the append method, make sure only your last definition includes the "&".
  6. Geometry Fracture Pattern from Texture

    Maybe something like this? It's not 100% precise, but I'm eroding your image slightly in COPs, then tracing it, unrolling, fusing, then extruding the resulting edges and using them for a boolean fracture. fracture_from_image.hip
  7. Vellum Pin to Target

    what's up bb this is kind of annoying to do because the vellum constraints sop doesn't allow for many options when using pin to target constraints... at least not in my current build. i'm creating the constraint and then using a sop solver in the simulation to modify the ConstraintGeometry so that any primitives named "pin" or "pinorient" have their stiffness attribute set to zero based on an animation inside the solver. check it out: disable_pins_toadstorm.hip
  8. MOPs Move Along Spline will do what you're looking for. If you're looking for a built-in method besides Attribute Interpolate or doing it yourself with primuv() etc in VEX, I think you're out of luck.
  9. copy to points with rotation of rbd

    I'm attaching a hip file to help explain. There's two things you can do: one is manually extract the transform using VEX as I described earlier... there's a catch in that the Copy SOP also recognizes the "pivot" attribute exported from the RBD simulation, so your boxes won't be in the right place unless you zero that out. The other method is to use the Transform Pieces SOP to copy the transforms over, as long as the boxes have the same "name" attribute as the original simulated primitives. transform_rbds.hiplc
  10. copy to points with rotation of rbd

    Packed primitives like those coming out of a Packed RBD Object store their transform information in primitive intrinsic attributes. The rotation is part of the "transform" intrinsic. You can convert this to a p@orient attribute recognizable by the Copy SOP with the following VEX: matrix3 xform = primintrinsic(0, "transform", @ptnum); p@orient = quaternion(xform); btw MOPs also can do this via Extract Attributes.
  11. Ah, right, I get it now. You could try adding the "vm_cameralist" render property to one of your cameras considered the "master" camera, that would contain the names of all the renderable cameras you want? Then tell your Mantra ROP to render from that "master" camera. That's what the Stereo camera is doing internally.
  12. I don't think there's an easy way to swap cameras in an IFD by name... you'd have to edit the camera properties individually, which would get really tedious. The best way I'm aware of to solve your problem is to cache the geometry you want to render as .bgeo and then load it back in via a File SOP as a Packed Disk Primitive. This means you'll still have to generate IFDs, but they'll store just a link to your geometry on disk rather than embedding it in the generated files.
  13. Transfer all attributes using VEX

    You can use the `pointattributes`, `primattributes` and `vertexattributes` intrinsics to get VEX arrays of attribute names.
  14. This isn't too bad. What you want to do is, for each piece: measure the area of all primitives find the largest primitive (sort by area) compute the primitive normal use dihedral() to compute the matrix that rotates that primitive normal to face {0,-1,0} multiply all points in the piece by that matrix I'm attaching an example file. point_pieces_down_toadstorm.hip
  15. Okay, can you talk more then about what geometry you're instancing? Or better yet, share a HIP? Are you instancing just one geo, or are there multiple types of geometry? What exactly is in the object container(s) being instanced?
×