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.


  • Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by Farmfield

  1. I have no clue what this was about, though - that was 13 months ago, I gotta download and check the file.
  2. I was so close doing a wrangle when I remembered - there's wheels already, no need to reinvent one.
  3. With a copy stamp, random vector per point (per frame) would solve it.
  4. No prob's, I've been bad at helping out here for a while, trying to get better though. And I have a lot of scene files like this posted on my Vimeo feed, lots of "tricks" and smaller techniques I stumbled onto, doing RnD, etc, so that's also something to check out if you're into getting to know Houdini...
  5. Yeah, then you got full control over the flame itself. Now I didn't do research last I did this or now, but if I was asked to do this in production, I'd do some proper research into how the patterning inside works, how the size and frequency of those patterns change with the burn rate, how the flame density and temperature drives coloring, etc - here I just faked the sh!t out of the look, hehe... And note that this is not the setup I used for the Fusion setup - that I did inside Fusion - but it was basically the same setup as this one. Also, this is just the mesh, for the shading I'd convert the elements to volumes and create a set of custom volume attributes to drive the shader density, coloring, etc... exhaust_flame.hiplc
  6. Creating flame and gas/exhaust as the same object might not be the best approach, it all depends. For a rocked or a jet exhaust, it's likely I would personally split it into one volume - as in non simulated volume - for the flame itself and then create a separate fire/smoke effect on top of that for the secondary effects from that flame. Now, there's probably situations where it would make sense doing a real flame in Pyro, though I haven't run into that kinda need so far. This is all made in Fusion but the principle kinda is the same, the exhaust is a particle system, but the flame itself was a 3D model...
  7. Use two DOPs, one for thew FLIP and one for the Bullet, and create the interaction manually. Check my bullet to FLIP setup here for some ideas on how to set something like that up.
  8. Well, you got the scene files linked, just dig into it.
  9. I've been messing with faux soft bodies using Bullet constraints just to get around the interaction stuff... But you can also stack DOP's and create interaction that way - though this will of course get computationally expensive, quickly...
  10. Well, personally I don't work like this, or at least not in production, it's like, well, this doesn't work, and you move on, hehe, find what does... So stuff that doesn't work is a bit of a non issue, if you get why I mean. I don't allow myself to get stuck fighting windmills, so to speak. FEM to me is for FEM only stuff and if it starts to cause issues, I just move on, because as I said, it's a solver that doesn't play nice (or at all) with other solvers. And I've used grains a lot, it's awesome because they are POPs, and FLIP and Bullet are point based as well, so all the POP stuff us available as well as you can do anything with it in a SOP solver. Oh, and though there are SESI staff running here, it's more likely to get them into s thread in the SESI forum than here.
  11. No, doesn't seem like you can, or at least not easily - as in, messing about inside the DOP solid object- and finite element solver subnets. So grains is the more controllable choose here.
  12. But even here, you get to a point where it breaks. You can up the steps, and that will of course help, but still, there will always be some point where it breaks again.
  13. Naeh dude, this is all in H13.5... This one: [link] Edit: ^the link is for 16.0.633, latest production build, I just wrote 13.5 to confuse PS a bit more - it's friday, I deserve some entertainment, right?
  14. The timestep is 0.25, the DOP substeps are 1 and the solver substeps 2 and collision substeps 2, and it works great for me. (the green stuff are encoding errors from imgur) flask.v1.Odforce.FF.hiplc
  15. Time to submit this ticket? //SideFX Software Inc//Bug report//2017-16-09//Houdini 16.0.600//Softbody simulations doesn't calculate correctly if the software is run south of the equator// And my personally status is of course Alpha = 1.0
  16. I'm digging into it now, but to be honest, I wouldn't use this solver because you don't have access to anything on SOP level (as in a SOP solver in DOPs) so my normal workflows are out the window - thus F it, not using that crap if I can avoid it. The whole point is control, imo, and seems you don't have any in regard to FEM... And yeah, long time since I dug into FEM, but it's annoying the crap out of me, it's not a black box, but it feels like it could as well be if I need to start unlocking the subnets in DOPs and start messing inside them - something that in itself seems to make Houdini extremely crash prone... Did I say I was annoyed? Grrrrrr...
  17. Delete
  18. Well, if you put enough pressure on something, on the collisions, stuff will start interpenetrating no matter what solver. These solvers are made for VFX, they balance performance and precision - thus they'll work up to a point, then stuff start to error out. As an FX TD your job is to work around it and I truly don't think this is an issue at all. Wedge 25 sims with some tweaks between them and have the client guide the process, it's how this stuff works in practice. And sure, this might be something where grain performs better, but you gotta test it out and compare. I've been messing with bullet softbody setups (like this and this) for a while to work around limitations with grains and FEM, it's all trial and error, there's no one specific solution that'll work for this or that, it all depends on what you need. If you wanted the pressure from the balls to break the flask at some point, you could do this all using bullet and constraints.
  19. Just removing the overlapping in the beginning and it all works fine for me. flask.v1.Odforce.FF.hiplc
  20. Just opened your scene and I'm pretty sure your issue is you are forcing interpenetration - in my experience, if you create intersecting meshes, the solver will allow that interpenetration from that point - and I might be completely wrong, but that's my experience.
  21. If your DOP doesn't contain a SOP solver, you're doing something wrong. #thetruthisoutthere
  22. Yeah, there's absolutely need for something either more clever or more sophisticated. I wonder how well it would work to actually set this up in FLIP using a combination of the surface tension and the strain (elasticity) micro solver - I fear it's one of those types of setups where it's easy to get stuck in tweaking hell trying to get it working/looking "right"...
  23. It all depends what you wanna do, but just doing a quick, unsophisticated method in SOPs, here's one way to do it... And you could easily apply a wire solver sim in the middle instead of my faux gravity setup there... sticky.hiplc
  24. The only thing I can complaint about is your logo has no legs to stand on! Great stuff. I really gotta do a couple of those dancer setups, I basically just pushed it aside and forgot about it...