Well I still think the seconds-vs-frame critique you offer just boils down to personal preference. 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. If you want a particle to travel a certain distance by the next frame, you just type it in. Since I find myself needing to dial in values on a per-frame basis more than a per-second basis for complicated effects, it's a no brainer.
If a complex sim does need to have its framerate changed for whatever reason, using the retiming spinner makes it a piece of cake. Same for slowmo.
Doing the to/from second conversions in 3rd party libraries/solvers I've integrated has been a simple conversion done at the start/end of the timestep, that the user doesn't have to worry about anyways so it has zero impact either way.
tyFlow's bind solver is position-based, unlike traditional MPM/SPH/etc, so they can't really be compared so well when it comes to the finer details. My friction model is straight out of the literature as well, and you can see similar artifacts with high-friction values in other implementations of similar solvers (see: Flex). These artifacts can usually be negated by just adding some position offset to particles when they're birthed, so they don't immediately form tall stacks.
Autocomplete for the script operator is a good idea...something I've thought about. Right now I have syntax highlighting but a little popup dropdown would add a lot of efficiency.
Your attachments didn't show up so I can't examine artifacts you mentioned unfortunately...I'm still trying to get attachments working properly, for some reason some people are having issues.
If a complex sim does need to have its framerate changed for whatever reason, using the retiming spinner makes it a piece of cake. Same for slowmo.
Doing the to/from second conversions in 3rd party libraries/solvers I've integrated has been a simple conversion done at the start/end of the timestep, that the user doesn't have to worry about anyways so it has zero impact either way.
tyFlow's bind solver is position-based, unlike traditional MPM/SPH/etc, so they can't really be compared so well when it comes to the finer details. My friction model is straight out of the literature as well, and you can see similar artifacts with high-friction values in other implementations of similar solvers (see: Flex). These artifacts can usually be negated by just adding some position offset to particles when they're birthed, so they don't immediately form tall stacks.
Autocomplete for the script operator is a good idea...something I've thought about. Right now I have syntax highlighting but a little popup dropdown would add a lot of efficiency.
Your attachments didn't show up so I can't examine artifacts you mentioned unfortunately...I'm still trying to get attachments working properly, for some reason some people are having issues.