Wow!!vvvvery interesting so far!
mention to:
as xd_nitro said i think a lot of users are very interested, including me, but hardly can contribute anything new.
anyway, the thread is very helpfull and i try to integrate the ideas in a data visualisation based on particle systems.
another project i am working on is to integrate biological model systems of swarm intelligence in social insects such as army ant raid formation in some modules.
hope that this work will be helpfull too.
last i noticed that dottores 3D boids patch is very cpu intense. i wondered if you guys have any idea how to optimize it in a way. would be incredible to see hundreds of thousands particles behaving as a swarm. is it possible to do the equations for alligning, mate finding and so on by the GPU?
@gregsn: amazing possibilities, not only for particles behaviour.
Maybe it has non sense but, could a similar technique be used also for calculating recursive patterns like this?
http://www.generative-gestaltung.de/P_2_2_2_02
It needs to know the information of the drawn lines to change the direction of the agents.
thanks
ari
@gregsn I’m checked your approach and i think this is great idea. As you mentioned, i’m also not like serialization-deserialization approach, hope framedelay issue will be fixed soon.
@dottore I’m added you to skype for faster communication. Currently i’m trying to convert your modules to dynamic plugins, using gregsn interfaces. But i’m stuck at beginning because core logic is hard to understand, so it would be greate if you can describe it to me or share base sources or docs.
pfiou… what a thread !
particle demo is a real good way to understand how to work creatively with them. i have learned more in your demo about how to deal with them than anything ! Very clear, understandable, and woaw ;-)
@alg: here is an update that works without framedelay and without all the serialize code. therefore the code is much cleaner now. the setstate/getstate approach combines s/r and framedelay functionality. @translating patches into code: i am not so sure if this is the easiest way of approach. maybe it is better to start from the mathematical definition of the typical BOID operations(?) ~ or from other textual code and just translate them to c# nodes …?
@dottore: can you provide the links to that material?
@karistouf: good to hear!
@lasal: i am pretty sure that you can do stuff like this with a similar approach. it might even be easier, but with the approach sketched in here i would say you can do ANY frame&state based behavior…
you also can do it without a own particle class, but you would need to have more framedelay feedback loops.
@Desaxismundi: well. thinking about it again. i would postpone 1D and 2D for now. many particle operations depend on operations like Pythagoras or angle operations, which work pretty different for different dimensions (1D, 2D, 3D). code might get a little confusing…
@tekcor: check dottores GPU particles!!
Particle Demo.zip (22.5 kB)
sorry guys, i was/am totally full of work and couldn’t even find time to check this thread… :(
@alg: i didn’t used any document or source to create those modules but probably there’s something about similar things on the web. if you contact me on skype i can try to expose you the modules and the logic behind them. :)
@gregsn: nice update! :)
loving it gregsn. exciting stuff
I like this approach a lot, would love to see this blossom further.
I gave the question of non-essential attributes some thought.
If we associate a “particle description” (could be an xml or json file, or something similar) with all attributes and their type (string, color, vector, etc) to every Particle-Channel, highly dynamic SetAttribute and GetAttribute nodes would be possible. Internally these attributes could be saved in a Dictionary within each MyParticle instance.
oh, and SetSlice (MyParticle) would be really nice to avoid huge value-based spreadcounts if you’d want to change the velocity of only a few random particles.
just before node i think this thread needs a bump.
would you guys like to do a brainstorming somewhere at node just about this fine topic?
while there is no framedelay for custom types i have been working on a different approach that tries to circumvene the necessity to a lot of framedelaying and has its perks with modular multithreading.
also i have some ideas on how to do implement a more dynamic alternative for VVVV.Utils.Animation.Particle. would like to have some discussion about this
Sounds like a great idea, maybe after the particle madness workshop?
anyone who wants to join the discussion, please join us then
I’m interested. Will be there on Friday.
I have good reason to revive this thread, but first let me revisit node13.
The particle madness workshop left but all participants boggled. I had the misfortune of not participating in the workshop itself, but the hype was on: GFX particles with DX11. With good reason I thought, but kept pondering the idea of a CPU based Particle. This thread was one of the reasons: to prototype and control the state and lifecycle of a particle of various needs is just asking for a higher level model. Higher level models are something CPU is more destined to, of course at the expense of particle count.
Months later I stumbled over Behavior Trees (BT).
Let me summarize what a BT is: Conceived during development of commercial games (halo, spore) they proved themselves helpful when designing AIs competing against the player. The AIs were called Autonomous Agents or short Agents. These BTs offered a similar freedom as HFSM (what vvvv can clumsily model as a patch of framedelayed Automata (Animation))), but were a lot easier to modularize and kept stable even at more complex structures of behavior, in realtime and in teams of interacting Agents. Also, timed motion could be streamlined with the Agents decisions and actions.
It is true, a Particle and an (Autonomous) Agent seem different concepts, but Behavior Trees with their Agents are essentially the blueprint of an hierachical behavior graph that can be easily patched with nodes. I stuck to the name of Agent, because it might help you to understand its underlaying principles: The implemented Agent in this framework can adopt to any mask, or what I call a Face, from the very simple (just a name) to the almost physical (IGravityAgent).
Gregsn suggested to use interfaces to standardize some of the attributes, to allow different developers to write compatible plugins. To make that idea work I used some tricks like duck-typing and currying.
Every Agent has its very own blackboard to scribble data freely and generically on it (that’s the dynamic part of it), all to maintain its own physical state (int Health, Vector3D Position), its prior perception of the current world (Vector3D EnemyTarget, double DangerLevel) and its memory on decisions of what to strive for next (Bin PathToTarget, Time NextTimeToCheckForEnemies).
Faces
Start a new c# interface that is public and inherits IAgent and you can define meaningful subsets of memory fields for basic Agent operations, which you can use strongly typed in your plugins. I prefer to call such an interface a Face, because thats what it is: one of many possible Faces of an Agent.
The modularized approach of these Faces helps to keep complexities in check. I have scribbled some basic Faces, boids and game-related, which you can combine with your own custom Faces or start a whole new generation of artistic particles. And for the quick hack, you sure can add attributes at runtime. Thanks to vvvv you can also create your own new Face at runtime too. Rescan the Faces enum list anywhere to clear the cache, all basic operation can be done without an external ide.
If this still sounds like .net mojo to you, just remember this: Inside the agent stays dynamic. The Face is just the mask, use it and sometimes another skillset comes with the mask. Dynamic is faster in execution terms, but with a proper Face you find problems in your code and patch a lot quicker.
The Nodes
Which brings me to patching, the only reason all this exists. We want the plugins to be efficiently patchable, or they are of no use to us.
There are some examples, templates and abstract plugin classes for actions, conditions and decorators.
Actions
are the leaves or topmost nodes of the behavior tree. In reverse understanding, Actions act on the Agents, they describe what the world does to the Agent. If something happens that prevents the action from execution it can either fail or remain running until it either fails or succeeds- for each individual Agent.
Merke: In this implementation Actions can only have one child. As a dev you can implement its Behave() function on all incoming Agents. Use the ready-made Templates for cloning.
Decorators
are nodes you can link in between. They can do stuff Before() and After() the Action’s Behave(). If you choose not to link an Action, it will call both and act as a some kind of two-method-action. Considering them the eyes and senses of the Agent helps to conceptualize them.
A condition in BT terms is something that can filter Agents before executing the Action.
I found the differenciation a little confusing, because any condition can also be a decorator, it only depends on what you do inside it with each Agent. It is simple, if you change the ReturnType to Running or Failure in Before() you either interrupt or prevent the action and the After().
Just three primary plan groups sequence, selector, parallel should help you to manufacture crazy complex behaviors. All of them perform from the left to right pin.
Sequence
will only continue from one BehaviorLink to the next only, if the ReturnCode on the node above has been Success.
Selector
will continue until the first pin has been successful.
Parallel
here the order does not matter. All pins will be called, until a set condition is met.
intolight
As a bonus I took inspiration in the earlier dottore Server-Client experiments and coded a Pot-Lid combination, that allows you to purely patch Actions (that also work as Before()-Decorators).
It bridges the workflows of patching and coding seemlessly, which helps prototyping for any vvvv user. Yes, I hope, this pack can be a useful contribution for prototyping and finding a useful standard, that can eventually foster higher level gpu behaviors.
The main idea of this thread and of this framework is the same: to patch and/or code behavior modularized and recombinant. A lot of work went into making this framework easy to access. You be the judge.
It requires some understanding of BT and some fearlessness with c# is good, but I am certain that the play’n’feel of vvvv can accellerate you along the learing curve of the algorithm science behind it. It operates unlike anything you have seen in vvvv and yet you should feel right at home.
This sounds fascinating, I’m unto my eyeballs at the moment, but keep us informed, and hopefully in a month or so when I get a day, I’ll try and remember to check it out!
+1… no text …
this is some great stuff that might be helpful for many things! i hope i’ll have some time soon to dig into this.
(and i do believe that this deserves its own thread…)