basic semi-broken things

[AlexMcLeod]

Per-frame units makes it very simple to understand how spinner values correspond to particle motion over time.

Yep, I understand that from an animation point of view, but all the papers you'll find on fluid dynamics, rigid-body dynamics etc. and all the third-party physics libraries are going to be in metric units, so any time you feel like incorporating the latest & greatest simulation methods, you'll have to rework them to use your time & space units instead. I've made that mistake before when writing simulators, and I'm just trying to keep you from getting locked into the same mistake for too long, because fixing it later requires breaking things.


Maybe you see having per-frame stuff to be intuitive because you've been using PFlow for so long? But even PFlow breaks the 3dsmax convention of allowing changes to framerate without affecting the look of the animation (much like you can change the scene units), because PFlow doesn't allow retiming without a lot of mucking around. It's not often that we have to change framerate mid shot, but tying information to frames (which can be any fraction of a second) instead of actual seconds means that when a shot does have to be overcranked for slow-mo, or just for troubleshooting, the effects animation would have to be reworked.

tyFlow accumulates velocities within particles over each timestep by iterating over operators and adding their resulting force values to each particle's velocity channel.

Yep, but that's probably why the Particle Physics operator produces weird results, and it means that we'd have to add those channels and do our own back-of-the-napkin calculations for every Script operator. Especially because none of this is in seconds, so none of this is in Newtons, or ms^2 and so on.

Storing accelerations and then adding those to velocities simplifies all sorts of particle stuff, and makes it way more flexible, too. Highly recommended.

Slow by surface should be combined with follow surface

Not quite sure I understand this one...

Say you've got a great big space monster moving through a great big cloud of space stuff, and you want the particles near the monster to be dragged along with it. If you use Slow by surface, the particles just stop while the monster drifts past - they're being stopped in world space, rather than being dragged by the monster's velocity. Or say you want a passing car to disturb leaves on the ground.

A combined surface drag operator would just mix the velocity of nearby surfaces into particles' velocities (preferably as a force, so that it stays somewhat physical).

Air force... I'm not quite sure what you mean by this...some kind of grid that forces are fed into?

Not a grid, no. Just procedural, like the existing Force operator (or the Composite texture, for that matter), in that it takes a list of other forces as inputs, and at any given point in space it just sums the results of those inputs and returns a vector. But that vector wouldn't represent a force, per se - it'd tell you the speed of the air at that location, in metres per second (or miles per hour, or inches per frame, or knot-gallons per fathom-furlong, or whatever velocity units you end up with when you don't use the metric system).

Then particles that with little mass but lots of surface area (soap bubbles, for example) would almost immediately take on the velocity of the air around them, but denser particles like rocks wouldn't be blown around at all. The Air object would be an optional background - a light breeze, or a user-driven whirlwind, or a draft near an open window, or lightly churning water, or a Phoenix or Fume sim - and any event could just receive the local air-speed and accelerate its particles accordingly.

Currently, the built-in Wind will accelerate particles indefinitely, which is a non-physical carry-over from the legacy particle systems, which were written completely naively with regards to real-world physics. We could just use something like a Drag warp to cap that acceleration, like we've always had to do in Max, but that's a non-physical hack that we've been stuck with for 20 years, and it'd be nice to finally be able to make a proper wind with a proper wind-speed. Some of the old Blur spacewarps came closer to getting this right, but they were still just a slightly better hack.

A grid for advection would be neat (Stoke had that - whatever you fed it, it could store it in a grid and strip out the divergence) but it wouldn't be necessary just for making more plausible breezes. A grid just for visualising the air-speed would probably be handy, though.

Interparticle friction doesn't preserve angular momentum, scale with dot product.

I'm already doing this in my friction model, I think the artifacts you're noticing are simply the result of using a position-based integrator with high friction values. Although if you have a specific algorithm I could take a look at that you're referencing, I'm always open to improving things!

None of the viscosity models in SPH, PBF etc. exhibit that kind of angular damping, even with viscosity cranked all the way up to peanut butter levels, so any particle fluids papers would be good for reference. But of course they'll all assume you're buffering accelerations (or at least double-buffering velocity), and they'll all be based in physical units like seconds...  

With no forces acting on it, a particle system should produce no net motion

If you have a test case where the opposite is occurring, let me know - because it shouldn't be. The only time the solver itself introduces motion is if it's separating inter-penetrating particles.

The artifacts I'm seeing are the kind of artifacts you get when you try to manipulate interdependent values like velocity directly, instead of manipulating their derivatives or double-buffering them.

Test case attached. With gravity on, you'll see the kind of rotational damping I'm talking about (the lump can't be induced to tumble), and with gravity off, you'll see the spurious net motion, which changes direction when reseeded.

The scripting language is C#, which is an inherently case-sensitive language. The reason for capitalization in function names is because I'm adhering to the language standard (upper case for function names, lower case for variables).

Is there anything like #define or typedef for type aliases in C#? Can we #include? Then we could just paste a list of lower-case keywords into every script. Without autocomplete etc. it's going to be hard to remember to capitalise things that aren't usually capitalised in other languages, like crosses and dots and getters and setters.

I'll see if I can manage a Maxscript to filter all detected keywords into the correct case, but it's gonna be hacky.

I use a partitioning approach you can read about in a lot of recent literature. The accumulation approach you mention has the downside of requiring a huge number of steps to properly converge.

In my experience, storing the displacements in the constraints (and applying them, as a separate step in every solver iteration) requires the same number of steps to converge, because the math works out the same - but it avoids the race-conditions and doesn't require partitioning. Mine was set up with GPU in mind (or for lots & lots of threads), where partitioning has rapidly diminishing returns, anyway - but my most recent version was with XPBD, and I haven't tried it with regular PBD. It worked fine for Velocity Verlet and semi-implicit Euler integrators, though.