Jump to content


  • Content count

  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won


Posts posted by Farmfield

  1. Funny enough, this was again asked in the Houdini Artists Facebook group and I had completely forgot about asking this back in April... Either way, here's two other SOP based solutions to this problem, the second one a bit of a joke, of course - though I have no doubt that method can be useful for some things as well... :D

    v1: https://drive.google.com/open?id=1mjJd0vd9KUSFW79ksRc5fioeMxXnu6Bu

    v2: https://drive.google.com/open?id=1mjJd0vd9KUSFW79ksRc5fioeMxXnu6Bu

  2. 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...

  3. 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...




  4. 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...  :)



  5. 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...


    • Like 2

  6. 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. :D

    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. 

  7. 4 minutes ago, Pancho said:

    Didn't have the chance to open the scene yet, but I'd like to check whether there's a way to control the maximum forces of the tetrahedal mesh inside of the spheres.


    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. 

  8. 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? :D

  9. 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 :D

  10. 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...

  11. 21 minutes ago, Pancho said:

    Nice work, Johnny! But your scene suffers from the same problems at the end (lower left). My objects were all created on the first frame without interpenetrating each other. That CAN'T be the reason for the interpenetration later. At least not alone.

    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. :)

    • Like 1

  12. 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.