Jump to content

Farmfield

Members
  • Content count

    589
  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won

    25

Posts posted by Farmfield


  1. In the end, Scratch had the right approach for this all along - with that said there is of course benefits to keep things in one DOP network sometimes, but if you don't need that, piping POP's into POP's is a fast and simple solution for this setup. A special thanks and apology to Scratch as I had the idea you naturally should keep the complete setup in one DOP, totally missing how well it works doing it as he suggested in his very first post. :D

     

    https://vimeo.com/123357428

     

    @Ian

     

    With that said, huge thanks for the file, it's a great outcome for the question posed, one great approach from Scratch and one explaining file from you on how to work with the streams - something that almost drove me mad the other day, just not having a clue why stuff just stopped working for no apparent reason, well, no I know. Much appreciated. :D


  2. Yeah, I messed about with the grain solver stuff a while back and it's sometimes pretty erratic, hehe, like doing stuff like this... :D

     

     

    But as the position based dynamics is likely to be a dominating part of Houdini DOP's for all kinds or soft body stuff in upcoming versions, it's good to mess around with it and see what works and what doesn't... 


  3. Man, I really appreciate your help, but I'm really not a beginner here and these kind of setups are just not what I'm after at all. And if I get to the point where I would be forced to pipe stuff in and out of SOP's, I'd rather just create the setup inside a SOP solver and do the setup manually with add nodes and VOP's to control it - or I'd do it using the L-systems - but as all this is only about me learning the POPs in DOP's context inside and out, I'm only interested in solutions inside DOPs using the POP nodes and the streams.

     

    And for you to get an idea where I'm at, I'm currently using POP wrangles and VEX snippets for selecting and grouping particles for spawning, but the problem is it's continuously not doing what it's supposed to and/or doing just that but breaking something down the line. And I have real issues with the streams, same thing again, I do a setup, get it running, do something like add a POP replicate to spawn trails, and the setup just breaks - we are also talking streams breaking other streams without any reason - or none that I can think of, at least - basically, for the first time since I started using it, Houdini just isn't doing what it's supposed to and it's seriously annoying.

    • Like 1

  4. No, that doesn't help me here. A simple example would be creating a point, add a POP network, in the pop network, birth 100 particles with an added velocity variation of 1, 1, 1, then attach a VOP and normalize the velocity - you will get all particles moving out from your initial point with a velocity of 1, creating a perfect sphere.

     

    The problem is, that breaks the second you try to make something more complex, like using a volume for the particles to follow a surface. I mean, there just gotta be a somewhat simple way to do a setup like this one I did in Max, it's just a quick demo I did for a guy on how to do exactly this in Pflow - now I'm here asking the same question for POP's, hehe... And jump like 6 minutes in to see the type of spawning I'm talking about.

     


  5. My second question for the day in regard to POP's. I'm splitting them in different threads as they are simpler to find for others looking to solve the same problem. :)

     

    So, I'm looking for a solution to spawn particles in all directions with constant speed, like a shockwave, be it a growing spherical form or for creating something like a ring growing on a surface.

     

    And yes, I can easily create velocities in VOPs for a point and use it in POPs but I'm looking for an in-POP solution, say you spawn particles from another (using POP Replicate) particle or a collision.

     

    Now, you would think it would be as simple as creating a VOP and just putting a constant to the velocity, but noops. Also, why is that? That should just work, imo, or am I missing something?


  6. So when I started migrating to Houdini a couple of months back, I really didn't get into the really simple stuff in POPs because I just didn't think that would be a problem - now it turns out that what I thought would be really simple really isn't very simple at all. or perhaps it is and I'm just too stupid (or too locked into my TP/Pflow thinking) to see it... ;)

     

    Lets say I have a couple of particles shooting out from one point and I want to have particles "spawn" of these particles at random frames, inherit the velocity but shift the direction a tad. Final step is just have all points create trails using a POP Replicate to spawn stationary particles - but that part I get fine. Oh, and solutions using VOPs, wrangle nodes etc. isn't an issue, any solution will do. 

     

    So we're just talking about creating simple growth pattern, something that is ridiculously simple to do in TP or Pflow in Max. Like this setup I did in TP 1-2 years ago, the secondary growth patterns.

     

     

     

    • Like 1

  7. LOL - that's absolutely hilarious. xD (and refreshing from the 1.4 billion Hitler-variants out there)

     

    And to be honest, if I were a gamer I'd be pissed, but as the most advanced gaming I do is Freecell, this really has no impact for me as a comper and FX guy. Well, unless it has, but I won't stress out over that until it bites.

     

    BTW - I wonder what the heck the video is really about, they are seriously dying... :D


  8. P.S.  On a different note, I happened to find this while trolling Vimeo, I think it's yours?:

     

    The main problem you're running into is you don't have a mass attribute on your grain particles, so it's treating them as they have mass of 1.  If you enable Compute Mass on the Grain Source and set the density to 100 to match the rigid body, you'll see each particle has mass around 0.05.  So your grain particles are about 20 times too heavy and are causing instabilities.  (I'm making a bug database entry to get this into the documentation - another user ran into it recently)

     

    Also:

    - The RBD Solver is more stable than Bullet for inter-solver coupled interactions like this.

    - You had Rotational Stiffness really low (0.3), if anything you want that really high (e.g. 4), which will dampen spurious rotations from particle collisions

    - Consider substepping at the DOPNet level as well, since that makes the the RBD / grain coupled interactions solve at higher frequency.  So for example decrease the grain POP Solver substeps to 2, but increase the DOPNet substeps to 5 (note this will take more DOPNet cache memory).

    - You might need to increase grain Constraint Iterations even higher than the 100 I set here to avoid stretching on the first ball / net interaction.

    - If you really just want sphere / grain interactions, you might even use really big grains instead and make it an entirely grain simulation.  See the Variable Radius grains helpcard example.

     

    I attached a more stable version of your test.

     

    First off, tnx for the info on the GPU computational stuff, the VRAM question is interesting, especially since the GTX970 has this weird 3.5+0.5GB setup, I guess I'll notice when that becomes an issue. And btw, what is the normal Houdini out of VRAM behaviour? Error popup or BSOD, hehe? Had a couple of those while rendering with H14, though never sim'ing.

     

    And the sim. Well, first off, it's just a 5 minute shelf tool setup, and haven't really had time to go through the grain solver for more than a couple of "for fun" tests, though the non-existent mass seems, as you say, like something that should have been ticked in the grain source node added in the shelf tool script. But note that I only posted it for entertainment, it's just as creepy, organic behaviour I ever got out of a sim, ever. :D

     

    As for rotational stiffness, checking my orig file, I only had increased the weight for the internal collisions and lessened the stiffness, you set them back to default and increased scale kinetic from .1 to .5...

     

    Finally the substeps, yeah, I didn't want to increase the DOP ones over 2, that's why I tried with the drag to calm it down, but that was before the thing came alive and started to crawl around, I think that came with my increased weight.

     

    Well, I'm going to get way more into this down the line, I only fell into this test after watching Alvaro's FEM breakdown today - real RnD I'd prefer to do on paid time, learning Houdini during my transition now has been way more focused on the more foundational, SOPs, attributes, VEX, the math (!) etc, really getting to know how it ticks... :)

     

    And tnx for this great info and great advice.


  9. Adding another GPU to handle the OpenCL workload won't reduce the CPU usage anymore than your existing GPU has.

     

    Thanks for the quick reply, Luke. So. What I've read is that Houdini cannot take full advantage of the GPU for OpenCL when running the display on the same card, so the question is if you get (noticeably) better OpenCL performance with a dedicated card or not.


  10. Currently I get about 3x the speed running something like Pyro or the grain microsolver on OpenCL, but seeing my CPU's still spike and my (seemingly) GPU doesn't, I'm getting kinda confused... So before ripping a card out of another workstation and benchmarking running OpenCL on a dedicated GPU, I thought I might as well ask here if anyone here knows how Houdini handles OpenCL when using the display GPU compared to a dedicated.

     

    My spec's are a i7-4790K@4.5 Ghz, 32Gb RAM, 1x GTX970 4Gb...

×