Jump to content


  • Content count

  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won


toadstorm last won the day on January 17

toadstorm had the most liked content!

Community Reputation

180 Excellent

About toadstorm

  • Rank

Contact Methods

  • Website URL

Personal Information

  • Name
  • Location
    San Jose, CA

Recent Profile Visitors

4,356 profile views
  1. 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.
  2. 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
  3. 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.
  4. 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.
  5. 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.
  6. Transfer all attributes using VEX

    You can use the `pointattributes`, `primattributes` and `vertexattributes` intrinsics to get VEX arrays of attribute names.
  7. 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
  8. 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?
  9. How are you handling your instancing? Packed primitives through a copy SOP, or the s@instance or s@instancefile point attributes?
  10. Here's another example file: there's one example material using the built-in Use Packed Color switch that's found on the classic shader. The other example material is a constant material doing the packed color multiplication from scratch. packed_color_example_toadstorm.hip
  11. Just apply v@Cd to the points that represent the packed primitives. Then in your shader, you either need to tell the material to "Use Packed Color" if you're using a prefab shader like the Classic Shader or Principled Shader, or if you're building it yourself, you need to include a RenderState VOP that loads the attribute packed:Cd and multiply that against the base color of the material.
  12. MOPs: Motion Graphics Operators for Houdini

    It's been a while! We finally have a new stable release. If you haven't been following the Experimental releases, there are a ton of new and updated nodes, bugfixes, shelf tools, and UX improvements. Here's the full list of changes: https://github.com/toadstorm/MOPS/releases/tag/v0.1.36 We appreciate any feedback from users! Let us know what works and what doesn't!
  13. find scale difference

    The lengths of the vector components of the matrix (3x3) will tell you the scale factor for each axis.
  14. Od Studios launch

    good luck marc, it's a hell of an undertaking!
  15. SDF's, are they all equal?

    It's the same as the difference between native fog volumes and fog VDBs... VDB volumes are sparse. Voxels that are deemed "inactive" don't have data stored in them in order to save space and computation time. VDBs also have access to all the fancy VDB library of tools for smoothing, filtering, etc.