Welcome to od|forum

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.

vtrvtr

Members
  • Content count

    105
  • Joined

  • Last visited

  • Days Won

    1

Community Reputation

33 Excellent

About vtrvtr

  • Rank
    Initiate

Personal Information

  • Name Vitor
  • Location Brazil
  1. Hello. I'm trying to be a modern person and use the new material workflows from H16, however, I'm having a problem. If I mix two principledshaders using a layermix like it's suggested in the webnars and the docs, my rest position stops working (at least I suppose it's the rest). Maybe I'm missing something I made the file below to demonstrate the issue Is this the expected behavior? If yes, how do I work with displacement in this case? Thanks layer_mix_disp_debug.hip
  2. Not exactly what you asked, which is totally possible, but a simpler solution pop_from_wheel_odf.hiplc
  3. Hey Anthony, there's really only one thing you need to pay attention to and that's the name. It's using the name that the sop manages to transfer from and the low geo to the high geo. That means necessarily you need to have the same names in both of them. If you check your hip, you'll see that your high res geo doesn't have any name, let alone the correct naming. Another problem is that because the voronoi isn't outputting the same geo, so the naming becomes wonky. If you isolate like the piece12 from the sim and the one from the high res version, you'll they are different pieces, that's a no go. They need to be same I think the easiest way to fix this is to do only one voronoi, break it and then edit as you want, be making it a high res version or making a low res version. That way you'll guarantee the names are all the same Alternatively, you can use the new "RBD Sphere Objects" from the shelf in your high res geo and it will create a low res version for you with the naming already sorted out. If you gonna do this manually, pay attention to the collision you're getting inside dops, you need to check "use compound objects" or something of the sort in the rbdpacked dop
  4. Sorry if I'm missing something, but you can do this with the simple voronoi. Just break the pieces and glue then together or something of the sort Or you can use the vdb to spheres sop to fix the problem with concave geometry. On 16 it's even in the shelf called "RBD Sphere Objects"
  5. Yeah, I suppose the algorithm used to calculate the normals runs through the whole geometry regardless However, you can simply use the group in a wrangle just below to zero out the what you don't want
  6. I think making HDAs is the best part of Houdini It's just bonkers to see something very (!) complex become a little file that can easily work on a variety of software out of the box. I too like to do it as much as possible.
  7. I'm not sure I understand the problem properly, but you can use a for each on groups and then use this setup for each group. If it works or not, it would be better if you could upload the hip file or a sample hip file
  8. You can sample a volume and deform a mesh accordingly, yes. However, depending on how complex you geometry is, this might not viable. Check out this file deform_with_vdb.hipnc
  9. Sorry, I should've commented the file. I'm creating a smoke simulation, with a tube for the smoke to collide inside. Then I'm using the volume trail node to visualize the velocity of result of that simulation. The Volume trail nodes works by creating a polygon at every point you feed to it based on the velocity of the volume at that point. See this He explains it in the first 5 minutes About the curved tubes, I think so yes, as long as the smoke moves properly. Depending on what you want, you might not even need to simulate it at all, just sculpt the volumes. He does something like that around 30min.
  10. I think it highly depends on what you mean by "simulating". That is, A "getting a look like the one in the picture" or B "predicting the actual airflow to an arbitrary degree of accuracy". A is relatively easy. Take a look at "Volume trails", they will give a look exactly like that. B is probably much harder and would probably involve some deeper research. Check the hip for a crude version of A quasi_airflow_odf.hip
  11. It's because the pieces are interpenetrating so in the first frame they are "fixed". Take a look at the file uploaded. You'll see that the effect doesn't happen because the boolean makes a "perfect" cut I remember reading here there's a way to turn this off in the bullet solver, but I can't see to find the thread and it probably wouldn't help you since the pieces would be intersecting anyway Some reasonable solutions: 1. Use the VDB to Spheres from the shelf. In H16, you can compile that process which makes it very fast 2. Low the collision boundaries in the rbdpacked dop 3. Make the cuts in a way that they won't be intersecting to begin with moving pts odf.hipnc
  12. That's very cool Is it robust? Would it handle a complex setup? For example, relative references, custom hdas etc.
  13. I send e-mail to SideFX and had a chat with one of the employees there. The answer is the following 1. Yes, it is. You just need to use the plane slice instead of the along the lines in a perpendicular position to the flow 2. The option refers specifically to distributing pressure, that is, you can turn that off since the flow itself will "wash" the errors from the boundaries 3. Distributing FLIPs has a worse than linear effect in performance. So, it's likely to speed it up, but not by that much
  14. For some reason they changed the export flag. I also had this "problem" The export flag is actually second one from the left, the orange one there is the output flag
  15. Hello. Is it possible to setup a distributed sim of a river that is coming down some kind of slope? Every example I can find takes some kind of already filled tank and goes from there. In the help there's even a note saying "this option is not needed for flowing rivers" (which might be refering specifically to the distributing pressure setup, but I'm not sure), but why is that? From my limited testing with the tank-like setup distributing the sim seems to speed it up considerably Thanks