Thank you a lot for your suggestions!!!
@diff-arch, as Daniel mentioned, supplying multiple values for the StepSolver works, however only if the inupt goals are not changed. Dircetly accessing the kangaroo.dll sound sensible, however this probably surpasses my current scripting capabilities I guess…
@maje90, the origami shown above was just a simple example, but it turns out that the trigonometric approach worked perfectly - obviously effectively zero computation time!
However there are other cases and projects, where it would be great to be able to use the StepSolver with changing input goals - deflating and folding of a membrane for example.
Would be so cool, if the step solver would support that! Not sure however, how the input logic would work… I guess
Animate inputs and incremental
Goals inputs would have to have the same list length?
I also tried that first, but with the Standard Solver. Maybe I have to experiement a bit more, but in my tests it was hard to get good iteration meshes - will experiment with this more though…
Especially taking into account that one has to first find a proper
SubIteration count, wait for the simulation to finish and get lots of unusable frames saved somewhere on the computer, delete them and start again.
Would be so cool… maybe an optional output and a boolean input in order to decide if “iteration meshes” are wanted as an output.