algorithmic modeling for Rhino
I've added another Agent Based Modelling plugin called Nursery to Grasshopper that provides a framework for producing more complex simulations than most of the existing (simple and fun) plugins floating around. It consists of a set of tools for creating Agents and Behaviours and executing these behaviours on a multithreaded simulation core. Implementations of distance fields, spatial trees and common particle based behaviours are also provided to reduce the need for extensive coding on behalf of users wishing to work with common models such as cellular automata or boid systems. Nursery is built on a set of generic interfaces and can be used for almost any agent-based modelling. It is intended for users with some coding or agent based modelling experience.
Nursery is still in development (and I have some hesitations about releasing it as aspects are not very 'grasshopper-ey' , occasional hard crashes etc) but I would appreciate feedback on whether the community finds it clear and useful and how to best improve it for subsequent iterations.
You can find a link on food4rhino http://www.food4rhino.com/app/nursery
Tags:
This is fucking awesome, a million thanks! I'm going to have fun like a kid with this. :)
I hope I can send you some feedback soon. Is there any reason for not to put a reset parameter in the simulator (sim)? I would even implement an internal timer to avoid needing the gh timer. Also I was struck by the amount of components that are with so few parameters, could not join any of them? Another solution could be to create gh_components with dynamic parameters according to the type of data supplied, for example, a single deconstructor, where the outputs change according to the input data. Or include user objects with frequently used component sets, to configure agents such as boids or ants (at least in their simple implementation) in a single component.
Have you managed to create emergent behavior with non-classical agents? If so, could you show it?
Thank you for this!!! :D
Hey Daniel - thanks for taking a look at the plugin.
I will implement the internal timer - that is a good idea. The sim doesn't store its initial state so the reset button might be a bit trickier - right now to reset most simulations you just change an input downstream and grasshopper data flow handles the rest. There are a few cases where resetting gets more tricky though so I'll try and come up with a clearer solution.
A generic deconstruct is a good idea. I'll implement that one too.
Creating user objects shouldn't be a problem. But I quite like illustrating the commonalities between a lot of these different use cases e.g. most of the examples use the same set of components - and I think one of the issues with existing GH plugins is the underlying algorithms are blackboxed and not so easy to learn or manipulate. In an ideal scenario users could create behaviours from clusters (by making Nursery run the cluster as a separate grasshopper doc) but can't implement this with any kind of decent performance at the moment.
By non-classical do you mean non-particle based? There are a few examples included that create substitution systems from text using behaviours, or manipulate rhino meshes as a proof of concept - but both of these are too simple as they are to exhibit the emergent behaviour you are probably interested in. In theory there is nothing stopping you literally combining these definitions together - the lsystem text might start manipulating the mesh, that in turn might effect particle behaviour... I will leave that up to the community to see what people can come up with. You might also notice that the KDTree becomes an agent in most of the examples in order to run a behaviour that updates the positions of the internal point collection.
Thanks,G
A) Have you considered doing a solver like anemone, taking the beginning and end of the loop, rather than a single final simulator? I think it is more appropriate for systems like these, or at least, more intuitive, because you formulate the definition of one iteration to the next, instead the global system, you can have dynamic behaviors without having to be the same instance, or store the history of the agents. In short, more control that can help simplify things.
B) Does it somehow compensate for operating with the same instance instead of making copies as gh does? Using approach A you can internally copy the objects to isolate the instance for simulation from the initial instance. The input component of the loop can internally store the copies that will be used in the loop, and the output component can also access them. I think this approach would allow you the advantages of the current approach but without its problems.
C) Perhaps a log as output of the simulator would help debug the algorithms. And maybe a visualizer of the energy of the agents, to help find the balance of parameters in the system.
D) I have needed to know the length of a graph or springs, is there a component for that?
E) You could customize the text conversion of the AgentList so that it can be displayed if it is a list of agents of particles, or varied/compound several types ... When you see the volatile data of a parameter and says that it is AgentList, you do not know which agents it contains. Perhaps the AgentList can be added attributes like name, generation, family, etc.
F) My initial experience was to be very lost. Everything is very atomized, the icons are cool :) but they do not help. It is too complex (many elements and many interactions between elements) even if one knows about agent theory. This paradigm is simple, the interesting comes when you create complex behavior, so I think it would be better for the user and plugins to compact it as much as possible, to allow only to bother to create complex behaviors, the rest should be easy and fast to implement, because it is always the same. User objects allow you to know the internal composition for those who want to go deep, or you can also create snippets like Metahopper or brickbox plugins does.
G) Do you plan to upload it to github? I encourage you to do so. This field of modeling can grow a lot.
H) With non-classical agents I meant those who have not been studied tens of thousands of times, such as the classic boids, the classic colony of ants, the classic game of life, etc.
I) It would be interesting to add a field from mathematical equations using the GH parser, the parameters are text with equations for x, y, z.
- Creating graph from curve seems to add one more point with a closed polyline (duplicate first and last).
- FixParticle allows to change the position of an anchored particle?, or is it that I could not?
- In the first input of Repel you have set "seperation". :P
- GraphTopology seems to return only 0s.
(changing a bit the Nursery_DifferentialGrowth example)
The source is on bitbucket - https://bitbucket.org/gwyllo/slowrobotics/ I'll put a link on the plugin page. Since the project is still in development don't expect total polish!
The Anemone approach is a really interesting idea - it would definitely be more grasshoppery. Are you imagining that it would be a clearer logic if agents are defined before the simulation loop, with behaviours defined inside of the loop? In order for behaviours to be dynamic would they need to be copied with each iteration of the loop? If there isn't a significant performance overhead then I can see how this would be pretty appealing.
Simulator log / agentlist output is on the todo list.
If you can be bothered writing some code the Documentation provides an overview of how to access graph or spring properties. I think there is spring method for length.... so to get the current length of all springs in a graph you could write a pretty straight forward linq expression like Graph.Edges.Sum(e => e.getLength())
I guess you could call most of my experimentation with generative algorithms 'non-classical' - I've been developing a bunch of tools for combining rigid body dynamics with constraints of assembly processes (joinery types, material profiles etc). I've also tried to write a couple of 'non-classical' CA systems based off of principles of resource scarcity.... though the examples in Nursery are trying not to be so esoteric. The basic principle of Nursery is that agents are type agnostic, so it would be just as easy to develop novel agent systems as familiar tropes though would obviously require more creativity on behalf of the author.
on F) - would it be simpler to have many of the current behaviours, fields, utilities as separate downloads (or even plugins)? The core of Nursery is already pretty simple I think.
Good idea to implement a field function. You could also look at the docs and try this yourself - the fields are also a framework and should be reasonably (touch wood) straight forward to extend...
Thanks also for the bugs - will patch those up. I presume there are many...
Diff growth looks cool. You should be able to generate some pretty interesting things by combining it with the boid models or fields etc...
G
Great work Congratulations..!!! Whats with the sign language on the nodes ;) ?
Welcome to
Grasshopper
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
© 2024 Created by Scott Davidson. Powered by