Jump to content


  • Content count

  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won


Posts posted by Farmfield

  1. On 12/4/2018 at 2:07 AM, toadstorm said:

    wouldn't it be more straightforward to use `maketransform(v@v, v@up)` rather than computing a dihedral that rotates one vector onto the other?

    i mean if it works, it works... just seems like an unusual approach.

    I do non straightforward stuff using unusual approaches all the time, funny enough. It served me well. ;) 

    On 11/30/2018 at 5:17 PM, dyei nightmare said:

    diedral?   im interested on how you used diedral for this case. 

    The scene file is linked in the video - and Toadstorms code works as well, and it's one line instead of two, haha...

  2. This is immensely annoying, haha... So I set this up like 3-4 years ago in H14, but I can't for my life seem to recreate it today. I thought it would be as simple as calculating a matrix from the velocity and then using setprimintrinsic to transform to that matrix - but I just can't get it working. Any ideas?


    Oh, and I'm not at all excluding that I did the above using something way simpler, like using some POP node - that's maybe even more likely than me doing it in a VOP or using VEX...


  3. In DOPs and solver SOPs (which are DOPs, hehe) I usually just create some random attribute and add to it, sometimes as simple as...

    if(something something) i@myage += 1;

    ...or alike. I think mane people get stuck trying to use stuff that's there - and if it is and you know about it, cool, but it really is as simple as setting this up purely arbitrary - though kinda depending on what you do, you might want to not stack up and pass on too much data with your geomery. Usually this isn't an issue, but if you're doing huge particle setups or FLIP fluids or something, and you have 10 random vector attributes piped into the sim, that'll quickly start eating memory if you have high point numbers - but in regard to how to control stuff, you can just make s**t up as you go along, hehe... :D 


  4. There are a couple of breakdowns on this out there... But beyond these, you probably need to check actual research papers and if you go onto Amazon I'm sure there are math books on the subject that goes into this way deeper...


    • Like 4

  5. I just use the outputs from the DOPs as collisions and/or use SOP solvers on the bullet solver to do stuff like attribute transfer of velocity, etc... And I won't share the above scene because it's an absolute PITA to work with but here's an example of "looping" DOPs and using SOP solvers on FLIP and bullet solvers - the scene file is linked in the description. I'll check it myself now because it was some time since I set that up and I don't really remember exactly what I did, but the foundation of it should be helpful, hopefully... :)


  6. When I've done stuff like this I've been looping DOPs in and out of eachother - with varying success - but there's no straightforward way to set this up, as far as I know... This is FEM trees, grains and bullet boulders set up like that - but it's a horrible setup to work with...


    • Like 1

  7. Not sure what you mean, but just generally in regard to binding this kinda stuff to surfaces, doing extrusions or offsets, what I would do - and to make it work on any object - is remeshing the surfaces in the solver (slow as F, though, as it's a single threaded SOP) and then using the normal from the underlying surface (transfer it to the output from the solver, or inside the solver) to transform it off the surface, like using @P += normalize(@N) * some multiplier in a point wrangle... :)

  8. Man, it's really badly threaded, though, checking the performance monitor, the relax node isn't multithreaded so it'll just drag the whole thing to a crawl... I really would recommend setting this stuff up in POPs instead, using either the POP interact or the grain solver, it's just so much faster as they are multithreaded.


    And what expression? In the transform? That will fetch the information for which iteration you are currently on which is a detail attribute of the node I pointed to. :)

  9. Thanks, much appreciated. And just to be clear, I don't remember how Entagma set this up, I actually don't remember 90% of my own setups I posted on Vimeo, I have to go back and check all the time what the hell I did on one setup or another when people ask me how I thought, etc... :D


    • Haha 1

  10. That looks really cool, Jonas, and loops are tricky sometimes, depends on what you're trying to do, but post the scene file with the loop and we can see how you thought - and I'd love a scene file either way, that thing looks really cool... :D


  11. Oh, ok, I think I understand the perceived problem, and then I'm with Matt, it's really nice to be able to set that up on a static object and then apply the animation on tip - of course depends on what you want to do....


    • Like 1

  12. There are several tricks you can use for the sticking, like forcing it by raying the closest particles to it, but the stringiness I suspect you are looking for might be tricky to get without diving a bit deeper into the solver crap and play with stuff like gas elasticity - though you might be able to tweak it into existence balancing surface tension and viscosity, or at least that's what my instincts are telling me, hehe... ;)

  13. On 12/13/2014 at 4:57 PM, eetu said:

    The better and smarter you want your packer to be, at the limit you will end up with something that's pretty much the equivalent of a physics solver.. 

    Ran into this thread by accident now but yeah, the grain solver works great for doing packing - random points, increase pscale per frame until it collides with something and beyond that it's just making sure it doesn't birth new seed points inside current spheres. In this case I just locked the setup to a surface and used intersection analysis and the polypath to create the circles, but if you birth the points in a volume you have sphere packing and if you want to use more complex objects, you just set this up with the bullet solver. :) 


    • Like 4

  14. There is no deception used here, it's just quite simple, hehe... :D

    It's just a habit, rather than scattering a single point on a surface, I usually just use one off the surface, so a sort randomly and then delete everything except point 0. Here I sort by Y and then delete everything but the lowest one. So the bottom most point is there and I feed that into the POP.

    The convert line SOP converts every primitive to lines between it's connecting points. If I didn't delete the surface, the minpos function would ray the point to the surface, but here I just want the structure of the mesh for the particles to follow. And I didn't need the restlength, but I just didn't bother about unchecking it, doesn't have any influence at any point here accept eating a small amount of memory.

    And yes, the minpos function moves the point to the closest surface position of the target, in this case input two where I piped in the line structure of the half sphere. :)

    And finally the wrangle where I normalize velocity and multiply it by 0.1 to force a constant velocity of the particle - else its speed would be controlled by the noise function of the POP wind, with wouldn't be very fitting for particles representing some kind of information flow or alike. If you want different speeds for each particle, you could use something like multiplying the velocity with rand(@id).

    • Like 1