Hey Alex, you wrote a lot of things and I'll try to address them.
Since offline sims like tyFlow don't have variable framerates, I decided to work in units per frame rather than second for simplicity. I personally am the opposite of you - since I often want intuitive control over particles I don't like having to constantly do back-of-the-napkin calculations figuring out exactly how far my particles will travel if my vel X and my framerate is Y and my unit is seconds. Per-frame units makes it very simple to understand how spinner values correspond to particle motion over time.
tyFlow accumulates velocities within particles over each timestep by iterating over operators and adding their resulting force values to each particle's velocity channel. At the end of the timestep, the velocity is integrated and added to particle positions. Accumulated velocities are multiplied by the frame dt,
Not quite sure I understand this one...follow surface adds velocity to particles that is parallel to a surface. Slow by surface dampens velocities based on surface proximity, two different things.
Lift forces for cloth (which would be applicable to leaves, paper, etc, as well) is on the todo list.
I'm not quite sure what you mean by this...some kind of grid that forces are fed into? Those forces would need to be advected as well, to ensure realism. Similar effects can already be achieved by using a Fluid Force on particles with an input PhoenixFD simultaion (and FumeFX at some point in the future).
Generally such spinners can be given negative values, for opposing effects.
Agreed, right now everything is basic inverse-square. At some point in the future I'd like to either offer different modes, or a literal GUI curve you can manipulate.
There's probably room for improvement here but it's most because the data for them is stored prior to velocity integration. For some markers, it's tough to predict where they'll be at the end of the time step because future operators may change the forces they're based upon. An easy solution might be to make them position/velocity independent and just save some stub of data which can be converted at the end of the time step prior to display...I'll look into doing that.
Spinners that aren't marked with a "%" do not modify values by percentage, but instead by value. For some things this distinction is necessary, so it's important to note where percentage symbols exist in the spinner label, to understand how the spinner will add variation. As for the scale of the percentage variation (being 0-100%, instead of 0-1), that's just a personal preference.
I think displaying units is important for a lot of things. It doesn't actually change the internal data value, but if I'm working in inches for example...I'd like to know my force values in inches to get a better idea of how far they will move my particles relative to the current unit system. Or the radius of something in units so I know how big it will be relative to other things I've built to scene-scale. However, you're right about mass value...that's a mistake and it shouldn't be displayed in world units. That will be fixed in the next build. I'm sure there are other places where this mistake may be visible....I'll keep my eye out for them and if you see any other rogue units showing up (or not showing up), let me know!
This is another thing on the (distant) roadmap that I'd like to implement. I used to have exponents in a few places where I figured they would be used most (and they're still in a few places, like the mass operator)....but eventually I'd like to add them back. It was just cluttering the UI a bit having all of those secondary spinners, so I'll be experimenting with ways to keep things tidier without sacrificing functionality.
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!
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 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).
I can appreciate this suggestion...I'll see about adding class-independent methods for the various math-specific functions at some point.
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.
Thanks for your thorough critique! I appreciate all of the thoughts and suggestions!
Quote:Things should be in units per second and not per frame.
Since offline sims like tyFlow don't have variable framerates, I decided to work in units per frame rather than second for simplicity. I personally am the opposite of you - since I often want intuitive control over particles I don't like having to constantly do back-of-the-napkin calculations figuring out exactly how far my particles will travel if my vel X and my framerate is Y and my unit is seconds. Per-frame units makes it very simple to understand how spinner values correspond to particle motion over time.
Quote:Acceleration, velocity integration, etc
tyFlow accumulates velocities within particles over each timestep by iterating over operators and adding their resulting force values to each particle's velocity channel. At the end of the timestep, the velocity is integrated and added to particle positions. Accumulated velocities are multiplied by the frame dt,
Quote:Slow by surface should be combined with follow surface
Not quite sure I understand this one...follow surface adds velocity to particles that is parallel to a surface. Slow by surface dampens velocities based on surface proximity, two different things.
Quote:Air resistance
Lift forces for cloth (which would be applicable to leaves, paper, etc, as well) is on the todo list.
Quote:Air force
I'm not quite sure what you mean by this...some kind of grid that forces are fed into? Those forces would need to be advected as well, to ensure realism. Similar effects can already be achieved by using a Fluid Force on particles with an input PhoenixFD simultaion (and FumeFX at some point in the future).
Quote:Attraction/Repulsion
Generally such spinners can be given negative values, for opposing effects.
Quote:Falloff curve
Agreed, right now everything is basic inverse-square. At some point in the future I'd like to either offer different modes, or a literal GUI curve you can manipulate.
Quote:Certain display markers lag behind particles
There's probably room for improvement here but it's most because the data for them is stored prior to velocity integration. For some markers, it's tough to predict where they'll be at the end of the time step because future operators may change the forces they're based upon. An easy solution might be to make them position/velocity independent and just save some stub of data which can be converted at the end of the time step prior to display...I'll look into doing that.
Quote:Some spinners are floats, others are percentages
Spinners that aren't marked with a "%" do not modify values by percentage, but instead by value. For some things this distinction is necessary, so it's important to note where percentage symbols exist in the spinner label, to understand how the spinner will add variation. As for the scale of the percentage variation (being 0-100%, instead of 0-1), that's just a personal preference.
Quote:Some spinners show units
I think displaying units is important for a lot of things. It doesn't actually change the internal data value, but if I'm working in inches for example...I'd like to know my force values in inches to get a better idea of how far they will move my particles relative to the current unit system. Or the radius of something in units so I know how big it will be relative to other things I've built to scene-scale. However, you're right about mass value...that's a mistake and it shouldn't be displayed in world units. That will be fixed in the next build. I'm sure there are other places where this mistake may be visible....I'll keep my eye out for them and if you see any other rogue units showing up (or not showing up), let me know!
Quote:Spinners need distribution functions
This is another thing on the (distant) roadmap that I'd like to implement. I used to have exponents in a few places where I figured they would be used most (and they're still in a few places, like the mass operator)....but eventually I'd like to add them back. It was just cluttering the UI a bit having all of those secondary spinners, so I'll be experimenting with ways to keep things tidier without sacrificing functionality.
Quote: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!
Quote: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.
Quote:Case -insensitive scripting
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).
Quote:More forgiving vector/matrix methods
I can appreciate this suggestion...I'll see about adding class-independent methods for the various math-specific functions at some point.
Quote:How are you solving constraints
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.
Thanks for your thorough critique! I appreciate all of the thoughts and suggestions!