In Rhino 5 it works … but I would like to use Rhino 6
Hmm, that’s pretty weird. Changing the value (i.e. sliding the slider) should expire the component and thus you shouldn’t need a timer. Afraid I don’t have Rhino 6 yet, so can’t really troubleshoot further.
Edit: That said, try to upload your V6 version and I’ll see if that still opens in V5, and perhaps I can narrow it down.
I discovered another problem with the script in Rhino 5. Changing the number by sliding the slider expires the componant. Once the number is set by tyling it doesn`t !?
That’s because sliding expires twice: once when sliding to a value and again upon releasing the slider knob. Typing in values only expires once upon entering the value.
How could a value be stored and be compared with an new value afterwards? Since I need an " autonomous" workflow for the optimization
That’s exactly what the script does. Perhaps it is more clear if we make a persistent list, instead of just one variable that we keep overwriting like in the examples above:
Hey Anders, could the second exire of the componant be done with a timer inside the script? Cause Input “CurrentValue” souldn*t be a slider but only a number which updates when the geometry changed e.g. the volume/ nuber of vertices etc.
Any Idea how to integrate that?
Any input should work, and you shouldn’t need a timer. If that doesn’t work as expected, please provide a file/example and I’ll have a look.
so this is what I want to archieve with the componant:
The script with the Process works but only for ONE Iteration with Octopus, since the “Balancing as Rigid Body” just gets an TRUE to reset in case the geometry of the Typology Optimization was updated. But after the RESET the Solver keeps been reset.
The attached File mimics just the core problem. So is you just scale the MeshBox in Rhino with the Gumball the Python Componant outputs a True since it expires once. I need now something which “automatically” expires the componant a second time so that it switches back to False. Thats why a timer would make sense?
If Octopus changes your variables, Millipede can give you identical results, and you want to save computation time by not running Flexhopper again?
And while Flexhopper is running everything downstream is frozen until it has converged or reached a certain amount of iterations?
I guess the volume and/ or num of vertices of the mesh will never be identical to the previouse iteration of Millipede. The comparison of the Volume Mesh(current) with the previouse Mesh was just an idea of how to detect an geometry change and therefor to trigger Flexhopper again.
No not yet. But you’re right that needs to be done as well. Otherwise Octopus would start a 2nd iteration after the 1st Flexhopper Iteration. But Anemone has the option “Output after the last”. So there needs to be 2nd “outer” Anemone Loop with Flexhopper. What do you think?
I guess what you need is some kind of Flexhopper Zombie Solver (Kangaroo style), would solve both issues at the same time
I am not so familiar with Flexhopper, but why not take the source code of the engine component and modify it in a way that it just runs straightforward a certain amount of iterations ? Would probably be the safest and also avoid the whole double anemone loop.
EDIT: That would actually be quite easy, if not for some reason some of the custom classes in Flexhopper were not public even though all their fields / properties / methods are
Hi Kaspar, think I missed your reply. You can explicitly expire the component a second time after setting the
foo variable to
True like so:
Which I believe should behave like you need it to. That said, I would agree with dsonntag that the overarching problem here in terms of pipeline logic/dynamics is that Flexhopper needs a “zombie” solve mode, that would enable one to more easily implement it within a search feedback loop with e.g. Octopus, Galapagos etc.
You might consider switching out Flexhopper for Kangaroo2 if possible.
I tried to skin down the engine component and reduce it to its minimum, unfortunately the helper classes (in this case ConstraintSystem) are not public, so not accessible this way, so doesn’t work
One way to work around that would to change that in the source code and compile it again, no idea though if that might create an issue somewhere. I added it anyways here, in case somebody wants to play around with that…
EDIT: I updated the file, there were some stupid logical errors in the beginning creating NullReferenceExceptions. I tested it the way I said (make the helper classes public, compile new .gha file), seems to work. Maybe get in touch with Ben from FlexHopper, maybe they want to include a Zombie Solver anyways at one point…
test_flex_update.gh (6.4 KB)
@AndersDeleuran thank you, that’s the solution I was searching for!!!
I tryed Kangaroo2 first, but ran into the problem that the RigidBody Componant doesn`t accept meshes!
@dsonntag you`re right this would absolutely make sense to do. But I have to admit that I’m not that fluent in writing scripts like you guys seems to be! I will first try how far I get with the double Anemone Looping
Hmm, as far as I recall it should. Perhaps you could upload a file and @DanielPiker might help troubleshoot it.
Edit: It should work:
If I recall correctly, when I updated the rigid body component to take meshes, I left the old version of the component in, but hidden, so old files would still open.
This means though that if you want to take an old example file and modify it to use meshes, you might need to just delete the rigid body component in the canvas and drag in a new one from the toolbar.
any solution for that?
Found this very helpful for my project, thank you!