Retreiving iterations from a simulation

Lets say you would want to extract the interim folding/calculation steps of a simulation like this:

So far I have found two unsatisfying methods:

  1. attach a recording component → not good as the step size / angle size can not be fixed.
  2. copy/pasting the simulation n-times, which creates a messy hairball.

Is there a more elegant solution to this, @DanielPiker?

Would be amazing if all the iteration steps of the solver where kind of sorted as a list and could be inspected afterwards.This would also be very handy, if one is running longer simulations, where you don’t have to watch it for 5mins and instead could let it run, take an Espresso and rewatch what happened afterwards…

Hi,

Have you tried using a Zombie Step Solver inside an Anemone loop?
You could set the loop end component to record data, which should give you each step of the iteration in a separate tree branch. I’m not exactly sure whether this works or not, but I guess it’s worth a try. :wink:

If you want total control, you’d probably have to script the goals and solver (i.e. Python, C#), using the kangaroo.dll, which is a Windows dynamic link library that also in some cases like this work on macOS. It’s equivalent on macOS would be a .dylib, which - I believe - is a dynamic loaded libary. It’s basically compiled C code.

2 Likes

Also, if the simulation is only about few elements like that one in the picture, you totally should be able to make a direct calculation of its position. With trigonometry or sphere intersections…

2 Likes

Hi @rudolf.neumerkel

For simulations where you need to capture a number of iterations you can use the StepSolver, and supplying it with a series of values will make it calculate a given number of frames (with a given number of iterations between each) which you can then scrub through.
Here’s a basic example -
steprecord.gh (12.3 KB)
However, this currently only works for simulations where the goal inputs do not change over the course of the simulation.

For recording animations you can connect a slider to the StepSolver and use the GH slider animate function. You should also be able to connect the same slider to a parameter such as the angle for your folding so it advances at a consistent rate per frame (and you could combine this with the data recorder to store the geometry per frame).
It would also be possible to script this - either by making a script which calls the solver, or by making a custom goal for a hinge with angle dependent on iteration count, then connecting that to the StepSolver like in the example above.

I agree though, it would be nice to have easier ways of recording full sequences when the parameters change during simulation (without scripting). I’ll see if I can come up with another solver option to allow this.
Ideally though I think this would be achieved through some sort of timeline editor where slider values can be set with key frames and interpolation, but that’s a bigger conversation with implications beyond just Kangaroo.

1 Like

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.