Farmfield

Instead of simply applying the transform, apply it as a force, that will give you way smoother behavior and it's how I would solve it.

I do non straightforward stuff using unusual approaches all the time, funny enough. It served me well. The scene file is linked in the video - and Toadstorms code works as well, and it's one line instead of two, haha...

Don't know if I ever posted this one but this is a cool effect as well...

Yeah, already solved it using the dihedral of v and up piped into a setprimintrinsic.

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

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

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

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

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

...and a variant of the above... Scene files to both setups in the link in the description - and that's an open post on Patreon, just so that's clear.

Very clean scene file for distance based growth - scene file linked in the description...

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

Yeah, it's a lot of fun and you can do really cool stuff. Here's a setup I'll go through in my upcoming course, whenever I'll get that out - but yeah, it's in the works.

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.

Oh, I forgot about this one, yeah, really simple, and gives a great behaviour. And this is how you'd use the foreach for the copying. diff_line_growth.FF.hiplc