This is what I was thinking in my first post. I think it makes sense for now. As long as the particle type node exists, I think it should come at the end. And I think the flow of things is much better in this proposal! Can’t wait to try it out~
1 Like
I don’t see the need for such a forced output node. Without an input node, which should be the important thing, this only complicates the particle system further for the newbies. It can only please those who already knew the old system and now should not put the events to the right. But beyond that I don’t see any improvement.
And also the design in this way limits a lot, or so it seems to me, to be able to make complex systems. As soon as you have to make a system with a minimally complex behavior to make everything grow to the left will make it almost impossible to find out what is happening.
I don’t know if the most powerful particle editors of today have a linear edition, from left to right or top to bottom. I don’t see why Blender should be limited to a “pile” of nodes at the left, without following a single standard in UX, any linearity and eliminating any possibility of having a real control of what happens in the particle system except concatenate events.
1 Like
Agreed that ‘particle type’ should be renamed ‘particle output’ - that may only be necessary for learning though, as it’s still imperfectly clear in my mind how all this works (slowly getting clearer though !).
I believe it would be nice to have a embedded socket that represents an array of a type.
It sould have functionalities like add, remove, reorder and convert to external node.
P.S.: Sorry about my bad mockup but i have only a browser available at the moment…
I might rename it. Have to think about it a little more.
Yes, something like that. It’s just a bit hard to imagine how it would look like in the style of Blenders node system. Btw, afaik in Softimage ICE it looked more similar to what I used.
We have reroute and frame nodes to organize nodetree and make it readable.
I don’t think that way of presenting Particle Type node as a huge impact on readability of Particle nodetree.
Although they are all connected to same socket ; nothing prevents user to place event nodes into a chronological order, from left to right.
It is true that UI is not guiding user to act like that. But, at least, he is not stopped if he tries.
To me, 3 proposals are usable.
I prefer the last one. It looks like the less complicated and does not look weird like a node without socket.
IMO, what is decisive about ability to make complex nodetrees, rather than Particle Type node look, is amount of other nodes at our disposal and connections allowed or forbidden.
If “any design UX is valid” will be true then blender2.8 wouldn’t have spent two years in remake the UI and UX because newbies didn’t understand how to move the camera.
Now we want to tell them that is really easy a node system than they expect
- input particles -> conditions -> output system
is
- output -> process
2 Likes
I have not read the whole thread but would like to plug a couple of things that I have in mind.
From my Maya, and a bit of Houdini background, Particles can be either a single node with a lots of slots (simple system) and a more robust one that usually involves SOLVER node of some sort, that’s supposedly handling all kind of FORCES.
A few years ago, last time I checked, from what I remember Maya has the classic Particles system which is pretty robust, which can use all sort of expression and drivers and attributes (can be pretty complex) and also it has nParticles, which system has 100+ attributes to play with.
What I do like from Maya and Houdini is the ability to:
- Visualize spreadsheet of every particle attributes from birth to death
- Viewing all kind of attributes as Color
- Mapping and painting over Particles
- Quick presets
- Quick baking
- Ability to break or pause the simulations
Via Sverchok, we have an example of “Pulga Physics” node, which is a single node which has a lot of toggle to add and remove “features” as needed. And then it has iterates and acumulates… probably more procedural … than actual physics and particle dynamics…
I like this kind of simplicity of “single node” particles for 50-60% of particle job.
I have not dealed much with a more complex system that uses EVENTS and TRIGGERS much, maybe Unity or Unreal already has such system?
Old school Blender Particles and Hair are actually quite nice and could become a single power node also…?
(I probably now need to read the whole thread once again and what Jackques already written in his 3 parts proposal…)
Maybe also take a look at particles in “Realtime” app like Shade (iPad), Snap Studio and Spark Lens Studio, which is “simple to use”. All users need to think:
- how particle looks (animated frames? or shader)
- how particles react with forces
- where particles emitted from
- what kind of solver
- particle instancing
So… what I mean is that maybe have a simple Particle system and a more robust one. Like Principles BSDF and whatever other nodes to put together…
Sorry if my thought is too simple. Cheers!
2 Likes
Alberto
Now we want to tell them that is really easy a node system than they expect
- input particles -> conditions -> output system
is- output -> process
True to me, maybe I’m not smart enough, but it’s hard for me to visualize the flow.
On the other hand I like the fact that there is a way out.
I did not go deep, but in Armory I understood well.
On the other hand, although it is not planned to integrate a game engine shortly, I think it should be taken into account for future extensions.
The following capture although they are not directly particles, shows the flow of Armory, I have simply added frame in the update to adapt the refreshment. It is very clear to me.
Sure, but honestly, I’m not sure node based systems are strictly “for newbies”. It’s true they are great for people who aren’t that good at coding; they are a great way to visually represent things, but that’s not their main purpose. When I was learning Unreal Engine I had not even known about node based systems before, and honestly it confused me a lot at first. Once I understood more about shaders, logic etc…the tools of the craft, then things made sense to me. You have to be able to have a goal in mind in order to use these things, and even then you have to understand all the tools at your disposal. Node based systems simplify a lot of complexity, and add a lot of functionality, and even though they are easy for intermediate users, for beginners I still think it’s hard.
While blender has become a lot friendlier to beginners, we are also deciding to take the everything nodes approach, and I do think that might scare off some beginners. But, in return, it gives users a lot more power at their command, and I think that’s a worthy endeavor. Also those who stick with it should learn pretty fast, plus we might have legacy options as well who knows.
1 Like
First, the particles are a basic system that all newbies want to use.
Second. I’m not a newbie with node systems, and need to read several times a manual to know how the particle nodes works. It’s not intuitive, like a node system.
A node system normally have a clear flow of data, from beginning to the end. In a shader I have multiple inputs that mixed properly give me an output for the shader socket. and that shader sockets can be mixed to the surface output. It’s powerfull, but also it’s clear.
In actual system I don’t know where need a new user to put the “mesh” that he want to use. Also teorically we can work with each particle, but I only see how to add effectors and events. I don’t know how to tell to it “hey, when the particles enter in that volume they lost all velocity and it changes with this matematical operation that I give you and it affect to position of the particle”.
Newbies will use particles with shared nodegroups when the asset manager is done…
It’s more needed to focus on particles design that have more abstraction and extensibility…
Newbies won’t know what the asset manager is… less to know what a nodegroup is. It’s more easy to learn the node system.
Jacques answered me to the part of the forces, it’s not implemented, I think a lot of things are not implemented yet, so there are many things that are hard to figure out because we need more nodes.
Also when you think in houdini for example it’s not “intuitive” either, until you understand the underlying philosophy, and even in that case it’s not too intuitive, but that un-intuitiveness gives Houdini the adaptivity and power it has, as I stated before both ends have to be covered, simple high level nodal graph for new users, complex low level access for advanced users, no limitations, all the power.
I think this can be achieved with Jacques idea, but I think we still need something more “complete” to be able to clarify wheter this is the correct path or not, but it’s normal, this is growing from the ground up being totally new! 
I don’t think that houdini is not intuitive, the problem is the name of nodes. But the system is clear.
Yes, but particles by nature are pretty difficult. Normals, Velcocity, Rotation, Damping, the list goes on forever. I’m not saying that newbies don’t want to try particles out, I’m just saying no matter what I think it will be difficult for them. I just don’t want to blender to loose functionality just to pander to newbies. Some parts are just going to be more difficult than others, I feel that particles is one of them. That doesn’t mean we should try to make it as efficient as possible though!
It’s still really early,
We just need to give things more time, I’m sure we are going to end up with a great design.
@JimmyGunawan What I’m missing here is a bit more context on how you actually use that node. If it is just one big node, than why have a node at all and not just a panel?
Besides that I did not see anything that could not be achieved with the proposed system (once it got more mature of course).
This is pretty much how the proposed system works as well. There is control and data flow. Only in the last proposal I did change the way control flow works for reasons mentioned in the proposal.
Well, not all nodes exist to achieve this effect yet, but this is pretty much the ideal case for the proposed system. You just have an “Enter Volume” event and then you do some thing when it is triggered.
Yes, this is a more general problem. The longer I wait to show how everything is supposed to work, the more you’ll understand it, but it becomes harder to change things. When I gather feedback early things are easy to change, but I cannot easily show how everything works.
When I started this thread I thought it would be a good time. There is already something people can play with, but it is still quite easy to change.
4 Likes
Yes, that’s the trade-off, but I still think this thread has been, and will continue to be a good idea. People are just very excited and passionate about this kind of project, we will just need to be patient of course.
1 Like
While I like the third proposal, it seemed difficult to grasp how some particles in the first proposal can be represented in the latest one.
In order to discuss “How expressive a node system is”, I believe that there should be shared test cases of particles, various types of complex particles that the particle nodes should be able to generate. By doing so, we can compare across various proposals and judge which one is the most user friendly. Once the system is chosen and implemented they should work as perfect examples.
2 Likes
Feel free to propose some test cases.
I think everything that can be expressed in the first proposal can be expressed in the last one.