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

    77
  • Joined

  • Last visited

  • Days Won

    1

Community Reputation

28 Excellent

About vtrvtr

  • Rank
    Peon

Personal Information

  • Name Vitor
  • Location Brazil
  1. Well, it depends on a lot of things. Mainly on how far is the camera. Because the difference between doing it with shaders in a general sense and doing it to each "grass" is enormous here. The former is relatively easy, the latter would take some fiddling For doing it with shaders, that is, it would be a camera very far from the grass, you can simply use some kind of noise and/or geometry to transfer an attribute that will drive the shader from "healthy" to "burned" Then you can use the same idea to drive any simulation (e.g fire and smoke) to complement it Take a look grass_odf.hip
  2. Absolutely. It's a similar setup as I explain in this thread here: There I'm moving the spheres, but you can, for example, control the offset of some noise inside a pop vop with it (or any other parameter). In fact, if you really just want to move the noise in a single parameter, you don't even need to bother with the copy chop, a single channel would be enough
  3. FLIPs are largely POPs. If your method works for POPs, it probably works for FLIPs too. The biggest challenge here is the material/uv, but that would be a problem too with pops
  4. That's not possible. At least not properly. .sim files are the files to "cache" simulations You can use your current flip sim as a initial source of another flip sim, but results may vary
  5. What about some chops? odf_growing_line.hiplc
  6. It's your fluid source sop RocketLaunch_v13_t1.hiplc
  7. Fairly sure you can do this with VDB morph. Although in my experience you'll really need some heavy machinery to work in a high quality, depending on your hardware it might not be the best option For how you would do it it's simple, you just need to animate both meshes separately, that is, the pyramid and the shoe doing their things, and then find a timing in the vdb morph that you're happy with
  8. I thought you were on Linux Still, the Windows daily version still isn't the same as the launch either
  9. That's the newest build
  10. Scene collapsing is pretty common. The problem is basically that you don't have enough particles, so they "succumb to their own weight". Possible solutions are: 1. Add more particles 2. Turn the substeps up 3. Turn up the particle scale 4. If you're on 16 you can try the new "Fill Volume" something in the flip solver, as well the "waterline" options (although now looking at your scene I know this wouldn't work unless you change it) Mind you that 1) and 2) will increase sim and render times significantly and 3) will probably make you flip look "bloby" Now, that aside, take a look how you collisi on mesh looks Not quite what it's supposed to be, right? Now with some collisions from vdb, it looks like this Also, the way you're making your particles isn't wrong, but it's a bid hard to work with because your particle separation and your scatter aren't really connected. By using a points from volume sop you can match them. And that's it Advert.hipnc
  11. If you check the newer threads, you'll see that both here and over the sidefx's forums there are at least a couple people complaining of something similar, which indicates it's probably a bug. You can try updating for newer daily builds That said, I don't have this problem on W10 Indie 16.0.504 (which is the release version I think) with a 1080/6700k
  12. I can't look at your file, but I suggest you try the actual subnet. It's much more stable in my experience Don't forget to have an unique iteration name with each foreach subnet, otherwise it will likely break
  13. You want each "plank" to have a different voronoi? First, shouldn't you consider using the new shatter tools in H16? They are almost tailor made for this situation! Second, answering your question, are the pieces separated in some manner? I suppose they are. If that's the case you can put a connectivity sop and then a for loop subnet. Inside the subnet you can vary any parameter based on the iteration number. That way each piece will be different I don't have H16 right now, so I can't open your file
  14. You don't really need the impact analysis Check the hip impact_glue_interaction.hip
  15. Check this thread