Jump to content


  • Content count

  • Donations

    0.00 CAD 
  • Joined

  • Last visited

Community Reputation

0 Neutral

About bentway23

  • Rank

Personal Information

  • Name
    Mark Reynolds
  • Location
  1. Thanks for your reply! Unfortunately, the FLIP is, I'm guessing, partially incidental--what I'm looking for is a rigid torus dropped on top of a deforming mesh--I don't want any fluid animation. I included the FLIP elements as I'm assuming that somewhere in there is the source of why it's not working. Also, in the "real" project, the fluid-like solid mesh is done, big and dense and pretty, after a four-day sim. I am out of FLIP-land and into crass ol' geometry-land now. I did mess with the density of the RBD torus, but that didn't really do anything as the collider itself is a non-density object. The quest continues. (Your example was great guidance on combining FLIP and RBD, though!)
  2. I have a meshed FLIP sim (cached out, .bgeo files read back in) that I want to use as a "solid" object and have a rigid body rest on top of it (the idea is that something solid "ripples" psychedelically and the objects resting on top of it move as the ripples go underneath--but the original object is still a solid, and the objects don't sink into it). I just can't get it to hold up, however--when the RBD object is initially "dropped" onto the fluid mesh, it bounces and settles as expected, and does okay with simple early movement, but eventually the collisions become less and less precise and the RBD object just sort of sinks in. How can I get the mesh to read as just a run-of-the-mill deforming object? I've tried RBD solver, bullet solver (obviously doesn't work with the shape of the mesh), volume and surface collisions, jacking up collider volume resolution to make sure all the little waves are getting captured, and boosting the substeps, but the result has been pretty consistent (except more substeps = super jittery RBD as it's reading all of the little pre-big-movement mesh ripples). On the attached setup (a simpler version of the project giving me trouble) I even ran the meshed surface through a "clean" just in case any of the lingering velocity attributes were throwing it off, but that didn't help either. I'm wondering if the fact that the topology itself changes so much might be the problem, but if so I'm not sure how to fix that. Thanks for any suggestions! flipmeshtest.mp4 meshtest.hiplc
  3. Create group of edges by angle for creasing?

    Thanks! Turns out the problem was that the object I was working with was imported as an .abc, and I just had to run it through a convert node--then the edge angles options in a group node did the trick. That procedural shading is something I'm going to dive into, though!
  4. I apologize if the answer to this is somewhere obvious--through Googling I've found some of people asking this over the last 15 years, but no answers that work. I have a model that I need to crease before subdividing. Manually selecting the edges is impractical--too many round buttons with flat tops. How can I automatically select/group just the edges joining faces with right-ish angles? I've tried the "include by edges" and setting min and max edge angles, but that doesn't appear to do anything unless you chose "Edge Angle Uses Angle Between Edges," in which case it selects pretty much everything. Thanks!
  5. Absolutely 100% what I was looking for. Thanks!
  6. I'm trying to create a custom velocity field for a FLIP tank (so I can "pin" part of it down with 0 velocity, while part of it sims all over the place). I'm following this tutorial: https://www.youtube.com/watch?v=xm404aavXrY --but it's from a version or two ago, and when he brings in the volume he created with the velocity attributes into his DOP network, he uses "source volume" and brings in the fields via SOP to DOP bindings (at about 12' into the video). I've crudely sussed out how to use a Volume VOP in the bit where the volume is created to add noise, but not how I could add the velocity at that level (if in fact that's how it's done). Following this model: https://www.youtube.com/watch?v=8UaDetbvMAs I have had success--grouping the FLIP particles in a SOP Solver and using a wrangle to set a custom velocity--but to my knowledge doing it that way won't produce a falloff--it's a very clear line in the tank between the 0-velocity particles and the non-custom particles. Thanks for any help!
  7. Increase FLIP viscosity with particle age?

    Yup, someone pointed that out on the SideFX forum. Beautiful, and big and obvious and staring me in the face the whole time. Thanks!
  8. Increase FLIP viscosity with particle age?

    Also, someone on the SideFX forums pointed out that you can add an age attribute right there on the FLIP solver. Hidden in plain sight.
  9. Increase FLIP viscosity with particle age?

    Thanks, gents! Evan, your example was great. I replaced with viscosity wrangle with a simple f@velocity = @age * [a number] and it did just what I wanted. Don, I missed something on yours, but I can tell the error is mine. I've got screenshots of the node trees. I can tell the Geometry VOP is added in correctly--if I crank up the offset value (the parameter I added going into the add) it does alter the viscosity--but trying to multiply the age * the bound viscosity * a parameter multiplier isn't doing anything. What did I miswire? fliptest.hip
  10. How would one increase FLIP viscosity based on particle age, to get a thickening/coagulating effect? My searching only found one how-to from 2012, which doesn't work in H17+. I understand setting viscosity by attribute, but it appears FLIP particles don't have an age attribute, so I'm not sure how to shoehorn one in there. Thanks!
  11. FLIP colliders flickering

    That did the trick, and the colliders seem to actually be cooking faster (but that could be my good mood talking). Thanks!
  12. FLIP colliders flickering

    So after a very lengthy FLIP sim I'm finding that my colliders are arbitrarily flickering in and out and disappearing altogether. I had done various tests--this happened a lot with lower res settings but seemed to stabilize at the final sim resolution--until frame 240 (of 250). The problem appears to be in the static object itself creating the collision geo. It's set to use volume collisions, mode is volume sample, division method by size at 0.005 division size. The object is an animated person at scale (about two units = 2 meters tall), this setting was about as large as I could go and not lose details. The .abc itself is imported and unpacked. The same object is used elsewhere to drive a pyro sim and it's working fine there. How can I ensure that my colliders don't just disappear?
  13. In case someone else chance's upon this--the redoubtable Tanto responded on the SideFX forum, thus (quoting without permission, but with much gratitude): In the Regions tab of your Particle Fluid Surface SOP, you can specify a bounding box, flatten the surface near the edges of the box, and then extend the edges using Pad Bounds and Extrude Polygons.
  14. I have a FLIP tank with some action going on. It's just someone diving, so the part of the tank that requires a lot of computation is small, but it's an underwater camera, so with a small tank you see the edges of the simulation. Is there a way to either focus the simmable area in a tank/make particle separation dramatically smaller in one area, to accommodate a huge tank with not much going on so the render times aren't crippling? I've seen tutorials on using lo-res sims to drive hi-res, but that is sort of the opposite of what I'm looking for. I've also seen some endless ocean tuts, but since what I need is an underwater dive, and the breaking of the surface (and the water still beforehand), I haven't found a way to make that work. Thanks for any help!
  15. Maya not reading alembic UVs

    Just in case anyone runs into this down the line, another forum gave me solution: The boolean/convert was squashing UVs. The trick was to create a "path" attribute on the twigs, and assemble the hierarchy in the ROP alembic. At first I created this attribute after the copy/stamp--which was fine--except the copy/stamp was set to pack the geo, which setting paths doesn't like. Unclicking "pack" did the trick.