Jump to content

toadstorm

Members
  • Content count

    195
  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won

    10

toadstorm last won the day on June 16

toadstorm had the most liked content!

Community Reputation

128 Excellent

7 Followers

About toadstorm

  • Rank
    Initiate

Contact Methods

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

Personal Information

  • Name
    Henry
  • Location
    San Jose, CA

Recent Profile Visitors

3,727 profile views
  1. IF condition result makes no sense

    yep, you're right! the point expression syntax doesn't work the same way as VEX. generally speaking, in VEX when you're trying to grab data from something that's not directly connected to your given node, you need the op: syntax to signify that you want to fetch the underlying data. for example, the point() function's help shows that the first parameter is <geometry>, not a string. the op: syntax signifies that you're trying to cook that operator and return the geometry data. similarly, you use op: syntax to fetch pixel data from COPs when you want to use a COP as a texture input rather than a file on disk.
  2. IF condition result makes no sense

    Try adding "op:" to the beginning of your path string.
  3. IF condition result makes no sense

    You're trying to fetch the X component of your point's P attribute, but you're just going about it the wrong way. P is a vector, and you can't just fetch a piece of an attribute... you have to fetch the whole value. So instead of "int point_to_compare" you'd need to use "vector point_to_compare", and just fetch "P" instead of "P.x". (Incidentally, P.x would be a float, if you could fetch it that way.) Once you have that vector, you can just compare "point_to_compare.x" against 0 and the rest of your code should work as expected.
  4. Houdini rendering Geo, renderflag

    your question isn't exactly clear. if you want to render something, put the render flag on it. you can separate it from the display flag if you need to by using ctrl+click on the display flag.
  5. Vector maths basics

    The dotted blue line is mathematically correct. The result of adding those two vectors results in a third vector, but it's still going to be relative to the parent space of those two vectors, meaning relative to the origin.
  6. Uknown shading artefacts from Mantra rendering

    have you isolated which AOVs/image planes the noise is showing up on? have you tried rendering with simpler materials (fully diffuse or simple non-glossy reflective)? with a simpler light setup? if it's happening everywhere regardless of lights/materials, do you maybe have coplanar surfaces in there? that would explain the ray bias parameter changing the results slightly.
  7. Copy Stamping using the new ForEach workflow

    I don't think you can copy the results of a solver and expect to vary the simulation seed post-copy. It might be possible with stamping, but I don't recommend it. Instead consider either caching out multiple seeds of your solver and then copying the cached sequences to your points, or have your solver run post-copy on everything at once.
  8. Installing MOPs [linux] issue

    There currently aren't any MOPs at the object level. Try jumping into a SOP network and testing there.
  9. Render Cd in Packed prims

    If you're using Mantra's Classic Shader, just enable "Use Packed Color". If you're rolling your own shader, use a Render State VOP to grab the attribute "packed:Cd" and connect the output to whatever material input you need.
  10. Polywire SOP.. non uniform line radius possible?

    Polywire also natively supports variable width; just made a float attribute on your points and use it as the "wire radius" value (e.g. @width)
  11. had to fudge the values a bit, but this should get you pretty close. switched your VOP for some VEX, it's a little easier to read. there wasn't any need for an Attribute Transfer since your number of points was exactly the same as the number of prims, so I just read the attribute directly from the matching prim number. forums_area_to_pscale_toadstorm.hiplc
  12. Slerp is also always going to find the shortest interpolation between two quaternions, so unfortunately you'd get a similar effect when trying to interpolate between angles past 180 degrees. You'd have to either find a different way to store your rotation information (e.g. radians around an axis) and use that to figure out your second normal, or you'd have to get a solver involved that computed the difference between the vectors (using arc cosine of the dot product of the two vectors, or maybe using the dihedral VEX function) and figured out the second normal per-timestep.
  13. Desktop spec for FX

    You want twice as much RAM if your focus is on FLIP and pyro. You'll run out of 64 GB surprisingly fast with FLIP especially.
  14. the maximum value of an attribute

    not easily. just use attribute promote sop for this.
×