04-04-2019, 11:52 PM
(04-04-2019, 05:46 AM) pid=\439' Wrote:What tyFlow lacks in a traditional seconds-based timestep, it makes up for in not having to do napkin calculations for hundreds of force spinners across all of its operators.But... your way, anyone else who does their physics in seconds has to do those napkin calculations you're avoiding, but in the other direction. The rest of the world (physicists and simulation researchers and FX TDs in particular) has already standardised on the metric system, in which the unit of time is the second.
Using an arbitrary timestep also means we can't just use real-world values for acceleration, velocity etc. without always having to guess how they'll scale in tyFlow, or even what unit parameters like "strength" might represent (or even what order of unit, like is it displacement, velocity, acceleration or force?). It'll mean having to find fudge-factors for every setup - especially for scripts - which could be 24, or 1/30, or 4800, or the square root of 9.82, or just about any other number, and that's before we even have to consider spatial units. With the metric system, instead, the fudge factor would always be 1.0 or a power of ten. That's what makes the metric system so easy & reliable.
And while it's great that you've built in physics-like behaviours and stellar performance overall, it's still not-quite-physical, when with a little refactoring, it could be physically accurate (or at least state-of-the-art accurate), even more flexible, and with the same or better performance, because higher-order integrators allow larger timesteps without jiggling or exploding.
Anyway, the friction example I tried to post shows a wad of particles with Particle Physics friction that should be able to spin & tumble together, but instead it shows unnatural rotational damping. I've seen that before, when I messed up some friction calculations of my own. Using Particle Bind instead, the wad tumbles as expected (with only the minimal damping you get with PBD), which suggests you're only missing that dot-product friction scaling in the Particle Physics operator. If you treat interparticle forces as the summation of damped Hooke (or neo-Hookean) springs between particles, you can conserve angular momentum, and you can get all sorts of cool squishy behaviours to boot.
Don't get me wrong - you've done an amazing job putting this whole thing together, but you've copied a lot of the design flaws from PFlow (where "it sorta works" seems to have been Oleg's guiding design principle), and going forward, those decisions are only going to cause you and your users trouble. Straightening them out isn't complicated, but it'd break some existing setups, so... better done in the beta stage than after the 1.0 release?