Jump to content


  • Content count

  • Donations

    0.00 CAD 
  • Joined

  • Last visited

Community Reputation

0 Neutral

About mdunkley

  • Rank

Personal Information

  • Name
  1. CHOPS question

    Hey Tom, see attached, should do the trick. edit: oops, looks like dennis beat me to the punch. this file, i think, is fairly similar to his, just using 2 expression chops instead of a trigger and vop. projectileTest_v02.hip
  2. get attribute at UV position.

    Hey Dany, don't think its exactly what you're looking for, but I'm attaching a primitiveattribute-based solution (for 12.5 only), so you can at least see what they're talking about, and see if it might start to work for you. Note that the primitive attribute vop *does* pull point attributes, but the lookup is based off parametric UV's and not texture UV's. There are some new vops in 12.5 (in particular xyzdist) make it much easier to derive parametric uv's if you don't already have them. parametric_UV_resample.hip
  3. point on surface position VOPS

    Hey John. The "intersect" VOP is the vops version of ray. It will give you back the worldspace position and parametric UV's of the hit. I think parametric UV's are the closest thing to what you're talking about - store those on your intersected points, and you can use them later in another vopnet thorugh the "primitive attribute" vop to , for instance, reevaluate the "P" attribute for your test geometry if its transformed later in your sop network (ie - stick the intersected points to moving geometry).
  4. moving/offset keyframes

    Hey Jim, in the channel editor its also possible to select all your keyframes that you want to offset and then in the "frame" text entry section at the bottom, enter "+" followed by the amount that you want to offset by ( eg "+ 10" or "+ -10" - note that its the "+" that qualifies it as an offset value; entering "- 10" will not work).
  5. POP Solver jitter

    Autofreeze doesn't work because the individual particles don't have dop-object-level transform information that the tool can read. Try increasing the substeps on either your doppop or your dopnet, should do the trick.
  6. Seems like Francisco's suggestion is the current "best practice" (or at least convention) for what you're suggesting - Source Volume DOP using the "pump" preset should do just fine. Or if you're bored with that you could always use a field force, which works with either volumes or point attributes.
  7. Sticking Particles & Dops

    Hey Lyonz, I had a comparable issue to this when i was looking into wetmaps for autofracture. Didn't find a perfect solution but got something that ended up working well enough for our purposes - heres the thread I tended to find that that UV-only solutions aren't that successful, as the autofracture process wreaks havoc on UV attributes. But I may have overlooked something. End of day though, Woodenduck is probably right: its a point count issue, and prefractured geo would probably be the most direct approach. hth
  8. Wetmaps for autofracture geometry

    Hey guys, just to follow up: SideFX was kind enough to look into this issue a little bit for me, and found a fix for my file that I had stupidly overlooked. Basically, the substeps on the solver node need to match the substeps on the dopnet - do that and all of the fractures should be properly represented.
  9. Wetmaps for autofracture geometry

    Yeah, we have a method that works well for unchanging geometry, but ultimately its looking like we'll have to use autofracture to get the shatter results we're going for. Either way, that end of things isn't really up to me - some other guys are working out the shatter method and I'm working out contingencies for wherever they end up. I'm still secretly hoping they go back to prefractured, but for now I want to be ready for anything.
  10. Wetmaps for autofracture geometry

    Hi guys and gals, I'm currently in the process of trying to work out a method of generating wetmap pointclouds for flip fluids on autofracturing geometry. Wondering if any of you all have attempted this before and come up with anything? I've currently got a solution that works some but not all of the time. Its a peter-quint-esque scatter approach that uses using the "FracturedGeo" geometry generated by the autofracture process for a wet attribute handover when the actual fractures happen. This method seems to work so long as the rbd sim isn't substepped - when it is I've been having issues getting a full representation of the current fracture from the "FracturedGeo" - I assume its happening on subframes and therefore isn't being pulled on full frames? Not entirely sure on that point, still sort of researching. I'm posting my test file here - its like an 85% solution, but I'd love to make it more consistent over substeps and/or less personally confusing. Note that substeps are currently at 2 and pieces will pop dry. autofracture_wetmaps_odforce.hip I'm also going down another road, trying to rebuild the fractured sim in reverse from its final pieces, then using a more traditional primuv sticking method on the unchanging geometry. The idea seems promising but the rebuilding is proving fairly tricky to work out and will probably take a little time, at least the way i'm thinking about it. I guess I'm just wondering if any of you guys have any insights or solutions to this stuff that I've overlooked? I don't have a ton of experience with autofracturing or the data it creates and am not eager to mess with the autofracture solver myself (though i would if you guys think it would help...?). Maybe you all know of something in there that I can use? I'm a bit worried I may be over/under-thinking this or trying to reinvent the wheel. Thanks in advance for any suggestions, pointers, or scene files you may have for this!
  11. Hey Ryan, haven't seen the vid, but sop solvers aren't 3rd party - they're a totally in-the-box part of dops, and are the best way of doing geo with feedback / history in houdini. Peter quint has some good videos on how to use them: https://vimeo.com/6660287 Feedback can also be faked with for-each sops, but the logic tends to get a little more fiddly.
  12. That error is pretty common i think, nothing to worry about though slightly annoying. My experience is that sopnets are shy and don't like to run correctly from the inside. I find that the only way to guarantee proper results is to run them from the dopnet they're a part of or levels up from it, or, as you already did, always be ready to manually resim.
  13. POP in DOPS little problem

    The culprit seems to be the "advection type" on your curl noise. Change it to "Update Force" and you should be fine.
  14. Motion Vector Pass ?! (rsmb)

    Hey Manu, looks like a two-part issue. First off, you'll have to transfer the particles' velocity attribute to your sphere geometry in the copy sop. For this, just click on "use template point attributes" in the Attribute tab. Now that the spheres have a v attribute, you'll have to enable "geometry velocity blur" on your Obj, under the Sampling tab. This tells mantra to use the v attribute in calculating motion blur for that object. Fix those things and I think you should be set. Hope that helps, mike
  15. roping and rendering image automatically?

    Hi Ehsan, you should be able to get this all happening automatically with render dependencies in a single rop network. What you're describing is basically what rop node connections are there for. If you plug the rops to write the sim files into the input of your pop rop, and then that into your image rop, it should all shoot out in that order. If you're on a farm, your farm setup would need to specifically support these types of dependencies, but either way local wouldn't be a problem. If you have two tasks that need to happen concurrently (as opposed to sequentially), then you can use a merge rop.