Yes, a google doc is good.
I’m on holidays right now. I’m reading all the comments currently, but will answer with more details on monday.
5 Likes
It would be very cool if that line you showed in the last image only showed up on mouse-over! That would keep the interface uncluttered but give you enough information when you need it.
1 Like
I think we should just have have an “output” node, one that is always at the end of a tree graph. You would give the output node a name, aka particle type like “exploded”, then all the nodes that came before it would be attributed to that particle type.
I’m going to post a particle graph from Houdini here, but before people skin me alive for posting other software, please note it’s purely for reference, and in no way am I saying “this is how it should be”. I’m hoping we can learn from this and come up with something that works for blender (hopefully something better).For now just look at the bottom of the graph.
(TonR: removed image, not allowed to share copyrighted material from other apps here)
The thing I mainly want to point out is the last node being “output”. Everything leads up to it, always. I think we could rename it something like “Particle Output”, and you could have more than one for each graph. So if you had multiple trees, let’s say one for exploded, one for trail, one for path, all you would have to do is look for the particle output nodes for each tree and you would know that everything that precedes it is part of that particle type. It definitely feels good to have something like that at the end, it confirms the end of a tree so well. This way, you also don’t need a “particle type” node in the middle, and perhaps forces could technically go anywhere? Perhaps that would make things like:
easier.
5 Likes
I think this is a great reference, things don’t have to be exactly like in Houdini, but there is a lot of expertise in Houdini’s workflow so as I said before, looking on how others tackle similar problems could bring new ideas to the table.
How mixing different solvers could work?
this is something totally different, it concerns a musical tracker made with nodes …
I would like you to take a look at it to draw some understanding
“generators” “filters” “modifiers” “composition of effects” on “a compositor-score” ect is made …
have a little imagination, imagine that the sounds are emissions of particles and nodes that influence them "… and imagine the fountains that spray colors and particle effects to the rhythm of music …
^ ___ ^ good vision and good inspiration …
(TonR: removed video, not allowed to share copyrighted screenshots or designs here)
edit:
I forgot to say …
Sunvox is totally free to use and can be downloaded here (to better investigate how it works)
http://www.warmplace.ru/soft/sunvox/
2 Likes
I’ve never used Houdini, but that node tree seems extremely clear. Using left to right and top to bottom seems like a good organization method.
We could also change the node shapes to make things clearer. For example, nodes have outputs on the side that is relevant to how it would be connected.
An annoying aspect of animation nodes is that color to color connection isn’t very clear. For learnability, an easier guessing system would be great.
Also on terms of user experience, the ability to hover over a node inputs and press shift a, should bring forward a menu of nodes that are able to be connected.
1 Like
Nice job @jacqueslucke,
In my opinion, events should be inputs of a particle type.
An event(Promise) should be an array of actions(array of function pointers) to do when a condition happens.
That way:
- The growth is only to the left side.
- Groups are more clear.
- Also we can have some actions affect multiple particle types
i am testing other design idea
the idea is make a simple left to right flow like shaders… the initial particle and emisor are always necessary to have a working particle system, that generates an output. after that you can add forces to the emisor for initial forces ¿maybe distribution texture? the output of the emisor is the particles, you can add to that particles any force and to the output particles you can add any event.
with this flow the user dont need to see the strange solver particle type of the actual system and he have more flexibility to make any particles system. the user could mix particles, use same particle for different emisors,… and user could use some events in diferents particles with differents forces because each particles will have here own output when user adds events or effectors. or he can mix if he wants
2 Likes
Yes agreed, a visual event/logic graph is just a programming language with a different interface. This is a visual programming language, no two ways about that. We shouldn’t compromise on this. Just as every function and class can have a return we should have an output at least optionally available on our node chain/group.
I would prefer the simplest way possible schematically …
generators (also many) -> filters & mixers -> output
Honestly … Just copy Houdini philosophy and workflow and new users will come like mosquitos to light. And that will make it easier for everyone. You, because you you don’t have to invent the wheel, houdini users because they won’t have much to learn to switch and blender users because it’s giving them the “universal” notions.
That’s easier said than done, ultimately it has to be built around blenders architecture. We aren’t dealing with houdini here.
2 Likes
idont see necessary any output.
I still wanting to show more of the proposal. If somebody see some problem only need to tell to search a better way to improve it. But I think that is a more powerfull system than the actual.
This is a more clear mockup of the idea
This an example of how it could work to mix particle flows
Or how to divide it
Of course maybe are not possible this two ideas in actual implementation. But if it could be possible this node system will allow to work in this way, making more flexible systems
3 Likes
Not necessarily harder to mimic Houdini workflow than inventing a whole new one.
Since Jacques is doing it almost more or less from zero, that’s now that best decisions can be made.
And particles properties/behavior are similar in most software, just the workflow flavors change, and nodes are universal enough so Blender can be made similar to the total reference fx software.
Don’t get me wrong, I never said it’s easy to do 
For doing a bit of coding, I have big respect for people doing complex dev.
Trying to to achieve something specific in the system is quite instructive, so I created this system of bouncing particles.
Thinking about how this could be rearranged, I came up with this:
In this version, “Actions” are another input to the particle type node (Which becomes essentially a “particle output” node, analogous to a material output node in shader graphs). Additionally, I still think a “particle type” input node would be useful, particularly for node groups, since otherwise you’d have to go into the node group to change the particle type, making them less re-usable.
In keeping with an action-driven system, I would imagine there should be an “emit particle(s)” action, which could be triggered from certain events, which might replace the “emitter” nodes. This would mean you could vary the properties of the emitter action based on the event that caused it.
Effectors could potentially be connected on the right, so you have a temporal flow: Event->Emission->Effector (I think this may be basically equivalent to this one )
Advantages:
Keeps the node graph as a single unit.
Maintains left-to-right flow.
Disadvantages:
Events become hidden/scattered across the graph, rather than being connected in one place.
(FYI, this is the output of that node system)
3 Likes
I do partially like @Alberto 's mockup. I like the chain of nodes adding affectors and events separately, I think it’s very intuitive. Generally, the number 1 thing I would like to see in the final UI is a clear “particle output” node, so that the data flow is very clear.
2 Likes
I don’t do that for a simple reason. It’s not necessary. In a particle system you don’t have an output, you have the result of the operations of each particle system tree, that could be one or 50 (because they are not objects) particles system.
So what we do, add a 50 outputs nodes in the same particle tree? Or connect all ends of the tree to same output?
1 Like
I think we’re saying the same thing …
only that they are inverted processes, to the output associate the object or multiple objects (or create more outputs)
In this way it starts from the particle generators (also more), adds filters and mixers and then lets the result out of the output … this process is simply more logical and understandable …
and is consistent with other node systems, shaders and compositor …
1 Like
I don’t really understand your proposal. Maybe a more specific example would help.