Jump to content

toadstorm

Members
  • Content count

    247
  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won

    13

toadstorm last won the day on November 1

toadstorm had the most liked content!

Community Reputation

156 Excellent

About toadstorm

  • Rank
    Initiate

Contact Methods

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

Personal Information

  • Name
    Henry
  • Location
    San Jose, CA

Recent Profile Visitors

4,030 profile views
  1. Orient / Lookat for Bullet Objects?

    Yeah you're right, you need to adjust the intrinsics. If you've already got the orient attribute figured out, you can just convert it to a matrix3 using qconvert() and then set the primitive intrinsic: matrix3 m = qconvert(p@orient); setprimintrinsic (0, "transform", @ptnum, m, "set"); You could do this in a Geometry Wrangle or a SOP solver.
  2. Convert grid to individual lines

    Ah, I get what you're saying. Use a Convert Line SOP to separate the edges.
  3. Convert grid to individual lines

    Set the grid SOP's Connectivity to "Rows and Columns."
  4. Vellum loop?

    did this on a job recently. here's the process more or less: split your cache about in half and timeshift / timewarp each half so that the first half becomes the second half, and vice versa. this means that the first and last frames are now identical and will loop. now you just have to blend the middle part. overlap each half of the cache in time so that you have some room to blend. keyframe a blendshape or the equivalent so that the caches blend from one to the other during this overlap period. to make this less jarring, you can animate a "blend" point attribute that wipes across the mesh from 0 to 1. then use a wrangle to blend your point positions from the retimed cache to the blend shaped positions: @P = lerp(@P, blended_P, @blendAttr); this works best if the wipe moves in the same direction as the prevailing ripples in the cloth. you might need to do a detangle afterwards, or do a secondary vellum sim during the blend shape animation in order to detangle parts that end up interpenetrating during the blend. totally depends on your original sim.
  5. Updating RBD constraints from deforming geometry

    Thanks! This is helpful... I'm going to do a little more testing on my own and report back here once I have a clearer idea of what's going on.
  6. Updating RBD constraints from deforming geometry

    I understand how matrices work... my question is more about what "space" RBD constraints expect to operate in. They don't seem to work in world space... it's like there's some kind of local or rest space they exist in that isn't explained anywhere.
  7. I have a tricky problem with RBD constraints that I can't quite figure out. I'm generating hard constraints connecting some packed RBDs to deforming geometry. I can use a SOP Solver to update the @P of the constraint point that's attached to the geometry as it deforms, but I'm not sure of the correct way to update the orientation… I don't what space to transform the constraints into and out of. Simply updating the orientation of those anchor points to match the deforming geometry doesn't work. I'm attaching a test scene to demonstrate the problem. constrain_to_animated_anchors_not_working.hip
  8. Multiple RBD Objects

    http://www.tokeru.com/cgwiki/index.php?title=HoudiniDops#Emit_packed_prims_into_RBD_sim
  9. I wouldn't even begin to know how to resolve collisions like that procedurally... you'd have to do this as a rigid body sim, which is going to make looping difficult. My advice would just be to fake it- either plan your objects and paths carefully so these intersections don't happen, or do some tweaks after the animation/simulation to hide or correct anything that doesn't appear to loop properly.
  10. Check if directory exists with hscript

    Is there a reason this needs to be HScript? In Python: import os msg = "Not Found" if os.path.exists(path): msg = "Found" return msg
  11. Orient packed primitives to velocity

    wouldn't it be more straightforward to use `maketransform(v@v, v@up)` rather than computing a dihedral that rotates one vector onto the other? i mean if it works, it works... just seems like an unusual approach.
  12. Color by group

    convert your groups to an attribute first, then it's pretty straightforward to assign colors. attribute_from_groups.hip
  13. Creating paths projected onto the surface is an interesting idea, and that would certainly make the looping process easier. You could maybe use the Detangle SOP to remove most of the intersections, then re-project onto the surface. To prevent the objects from intersecting with the statue itself... I'm not sure what your statue looks like, but if the pivot point of the objects you're copying is set so that the objects just rest on the surface, you shouldn't have to do anything special there. You can just move your source object in space before copying if you're packing them at the origin, or edit the v@pivot attribute on your template points.
  14. Your file attachment is broken. This is a tricky problem because the only way to *procedurally* move objects along a surface in three dimensions like this is without snapping to have a perfectly parameterized surface... meaning, it's either NURBS or it has a flawless UV layout. If you could hide your UV seams, it might be possible to have your simulation happen in UV space (literally, set @P = v@uv on the mesh after converting your uv attribute to Point), then use xyzdist() to get the primnum and primuv on the flattened mesh for each point, then fetch P and N/up from the original mesh and set your copy points to have that P, N, up. When your objects cross UV boundaries, though, they'll jump. If you were running this in a solver, maybe you could store the original P/N/up of each copy point when the solver starts, and after a specified amount of time start pushing points towards their goal positions instead of just moving in a straight line along the surface? It'd probably take some cleanup work to get them to not look like they're accelerating and decelerating, but in reality on a complex surface it's going to be really hard to get an absolutely perfect loop with no speed changes at all.
  15. http://www.sidefx.com/docs/houdini/copy/instanceattrs.html cubes_orient_to_line_toadstorm.hipnc
×