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

    92
  • Joined

  • Last visited

  • Days Won

    1

Community Reputation

29 Excellent

About vtrvtr

  • Rank
    Peon

Personal Information

  • Name Vitor
  • Location Brazil
  1. 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
  2. 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
  3. Did you watch the masterclasses for ocean and/or flips? Most of your question are explained there. The short version is that there's a white water solver.
  4. Not sure I understand your question. If you want to keyframe it once and remap it procedurally, it's possible with chops. I don't quite remember the name of the node, but if you go the "time" group of nodes you'll see it. You can then use a copy stamp to apply it randomly wherever you want. If that's the case I can link a specific explanation for doing this If you want to write an expression that converges to some point in time, there are several ways of doing it. The most trivial one being just accounting for it. E.g if your goal is to have 1000 particles in 10 secs, make it 100 particles/sec Sorry if it's neither of those
  5. If you middle click the node, you'll see that you have only one primitive, which makes sense with what you're saying. If you put an unpack sop there, you'll see that you'll now have all points, but still no primitives. If you put a convert node set to polygons, then you'll have the geometry you're expecting (you can bypass the unpack if you so want).
  6. It's literally just putting the attribute there. E.g put a point wrangle and set @viscosity = 1, all particles will have this viscosity. If the solver reads the attribute, it will just work. In this particular case you need to activate the viscosity by attribute inside the flip solver. As for which attributes can be used, AFAIK you have go to the documentation and read it there.
  7. Actually, never mind, the duplicate sop does exactly what you're complaining. I'll come up with an actual way, just a sec Here: odf_copy_straight.hip A little recursive for-eaching. I did the distance by eye, but you can calculate the offset with an expression if necessary
  8. You mean besides using the attribute in the shader? Because if you take a look at the vanilla pyro shader, you'll see that it maps temperature to color, but temperature isn't anything special it's just an attribute mapped to a color
  9. Not really "basic boxes" there. You're generating already interpenetrating boxes from the get go, strange would be if it worked properly That aside Increasing the number of substeps in the bulletsolver drastically reduces the issue (try, 50, 100, 200...). Same for the substeps of the dopnet. At some point it starts exploding, which I suppose is the expected behavior since you're creating a mesh inside another mesh Which is to say, avoid interpenetrating things to begin with
  10. I didn't do it in the hip I shared, but if you go to the cloth capture sop and reduce the radius, it becomes basically real time. As long it's a simple fracture is shouldn't be a problem
  11. Check the hip dynamicShatterTransfer.hip
  12. I'm talking about the subnet sop. Just create one, click the little Gear in the parameter windows, you'll see a bunch of presets, one of them is called "Rolling-Debris" something
  13. I can't see your file. Some points 1. What you're describing IS painting an attribute. In this case you're painting the glue str, but you can do the exact same with the active attribute (which controls "passive" and "active" objects) 2. RBD workflow changed (AFAIK) nothing in H16. What changed was the boolean, but that's not really related to the present situation 3. You can glue anything to anything, which means one way you can make the wall stick the ground is to glue the wall to the ground
  14. Download https://github.com/qLab/qLib Subnet has a preset that does rolling debris It's not that I don't want to explain it, but it's not super trivial This might be an old method, the basic idea is to use the cross product of the velocity and someone other axis to create a proper axis system to rotate around. It's a very common technique in computer graphics even outside this particular effect
  15. 20m seems really far, I don't think you need to worry about the individual grass As for why is it slow. I don't know. It isn't slow on my machine, pretty much real time. There's really not much in it, the most intensive node there is the vdbfrompolygons, try disabling that In order to get a nice fallout you need to have a lot of voxel bands (think of it as layers), which makes the vdb process a bit heavy. There are several other ways to transfer the attribute tho, this is certainly not the most efficient one