I strongly like I idea of going a approach similar to nuke (or houndi which looks similar). They both seem to have the flow: object to emit/particles -> particle emitter -> forces -> particle output. I like this as to start a simple particle effect you just need a particle emitter and the output. Then you can add inputs to the emitter such as objects or other particle systems and effect the output of it with forces.
This sort of flow seem quite natural.
I would also be interested in some sort of particle add node which nuke has.
3 Likes
Little opinion, Particle System Tree must be a object, not a tree inside a modifier inside a object.
And we must to be able to see like this.
Maybe this object wonât have transformation, origin, position⌠but it cannot be a simple tree that you link to anything with a modifier.
5 Likes
Reading through the " Updated Particle Nodes UI" wiki page ⌠i"m wondering, is node tree growth really a problem? I work with Nuke on daily basis since several years (together with many many artists in several companies) and i never heard anyone complain about ânode tree growthâ.
Complexity, yes, thatâs a problem. But removing links doesnât solve that.
Grouping helps.
8 Likes
I see what you mean, but Iâm not sure I agree. These particles system trees are more like materials, in the sense that materials can be attached to many objects and are shown under the object data of an object. Houdini shows it it in the object that itâs attached to, and Cinema4D quickly shows a particle icon beside the object and has it, once again, below the object. My opinion is we should just add a particle system icon beside the mesh data icon and modifier icon, and then have it below in the modifiers drop down as well, like usual.
And here is Houdini for reference:
It just seems weird to make it have itâs own slot in the outliner, like it is itâs own object. But perhaps we could have a different section in the outliner for Graph Trees?
3 Likes
Materials? We talk about an particle system that is not related to the object liked. The only thing that do is hide object, use others emisors and hide inside a modifier.
No weâre not talking about materials, but what I mean is materials are often assigned to multiple objects, like these particle trees can be; materials, however, are not displayed as their own object in the outliner. You have go to the material tab in the outliner, there you can have them all listed. I think the particle graphs should be basically the same. As we are using a modifier for particles you can should see it in the modifier drop down under the object. That can be hard to tell what has a particle trees and what doesnât, so Iâm proposing adding a particle icon beside the object in the outliner so you can see what has a particle tree at a glance.
To be extra clear, if you look at the picture from Houdinis outliner, itâs almost exactly the same as blenders! You have an object âgeo1â, and under it you have everything associated to that object. There is no material in there however because I didnât assign one, but had I it would also appear under âgeo1â. So itâs the same. The only thing it does different is when you collapse âgeo1â you donât have those icons on the right of it saying somethingâs about it, like in blender. In blender we get a modifier icon and a mesh data icon. Itâs a pretty great visual way to confirm things about your objects. Iâm just proposing putting a particle icon there for extra clarity. I donât really see why we would need a separate entity in the outliner for a particle graph.
1 Like
I donât care about Houdini.
it doesnt have any sense and the unique reason to defend it is because this is similar to houdini. But still dont have any sense, the particle system is independent of the objects with the modifier.
Defend that is like told that we need a object where we link the grease pencil with a modifier that make disappear the object, instead of have a grease pencil object because other program do it. The old particle system depended of the object with particles, and it was a big limitation of the old system. The new system add the emitter inside the tree, you could use groups, collections, lists,⌠why we need to link the particle in one of that objects instead of have a own object? If we need inside other object in the outliner tree we only need to parent it.
5 Likes
@Bobo_The_Imp , that does not make sense to have particle system as a modifier with what Jacques Lucke did.
Under master, particle system is a modifier on one emitter. It is completely required for hair particles.
But what we are talking about in this thread is Emitter particles from Functions branch.
You have to indicate emitters into nodetree. So, that does not make sense to add a modifier on a mesh that is disappearing and its geometry not used at all. User have also an unecessary step to create a nodetree.
Things will be a lot simpler if by creating a particle tree object, a basic node tree would be immediately accessible.
1 Like
@Bobo_The_Imp @Alberto Yes thatâs true, and I like the clarity of this proposal.
But wait. What happens when, for exampleâŚ
-You create a modifier with âFunctionsâ
-This modifier is applied on a Mesh to transform its vertices.
-You also use âBParticlesâ connected to the âFunctionâ which is altering the vertices of the mesh.
(Or maybe even generating new vertices, because you vdb mesh the particles for example.
Would you put the particle system in the outliner or would it stay parented to the object?
I think, there are three options.
-
You have two places where particlesystems could be found.
(In the outliner for global ones, in the case the particle system is definitely connected to the object, it would be parented.) -
Particle systems always have to be nested into the context of object data. Like in @Bobo_The_Imp proposal. (parented)
-
You only use particle systems in the outliner as an seperate object.
(But then you have situations, where you maybe have hundreds of particle systems in the outliner and your overview is gone. And itâs even more complicated to see what particlessystems are connected to a object if needed.)
Thatâs a pretty difficult decision to be made.
I would go with option number 1.
A object in blender is still an object, even if itâs a greasepencil or an empty.
It has itâs transforms and data can be stored to it. So it also could be a particleObject
Id rather would just change the icon of the object, when no mesh data is present or generated.
So it would be clear that it is just a global particle system, which doesnât change geometry.
But I wouldnât like to see a particle system for every object I want to alter. Itâs like if you had material objectâs in the outliner for every unique material you are using. Imagine you want to build a city generator, in the worst case, you would have a particle system for cars, one for houses, lamps, people, trees, etc. This could all be stored in one object, rather then cluttering up the outliner.
1 Like
If you have hundreds of particle systems in a scene, Iâm sure that the minor problem of managing in that scene are the particles systems. Also if the particle are linked with a modifier to an object I donât think that have hundreds of objects hiding your particles systems will improve the situation.
Maybe I have understand wrong your proposal, but mix the particle system in the ouliner with other objects is a bad way because. Where could I found one of my particle system? like an object? like a nested modifier? Do I need to remember the name of the emitter to know where I can found it?
If you talk about have the object and also show an icon in the objects used by a tree with a modifier. It is good option
Managing and finding Bparticles and Functions, will work the same way we manage shaders. You have access to all shaders of your scene with a dropdown and a search function. The same goes for the new nodesystems.
Naming them right is the a and o of a well organized blend file.
I just think we should avoid adding additional objects to the outliner as good as possible. Or you will one day end up with something c4d is struggling with. The outliner there gets messed up really fast and you loose a lot of clarity of your scene. Especially because the particle systems there are based on the outliner hierarchy and the logic and behaviour is build on it.
1 Like
I agree that the particle system should probably be its own object, even just for the sake of clarity in the outliner. Thereâs another argument for it : particles can be spawned from any surface or volume, even from multiple sources : so, linking it to an object wouldnât necessarily make sense as particles wouldnât necessarily spawn from it.
3 Likes
Iâm not âdefending itâ⌠Iâm posting what I know about it so we can learn from it and make a better system. I want blender to be even better just as much as anyone else. That being said, after reading the posts here, I now agree with you. I just initially found it weird for it to be itâs own object in the outliner as it is, but after thinking about it, I realized thatâs basically what houdini as well, just with different presentation. Iâll explain at the end of the post
Yes I agree, but as itâs probably in pre-alpha, thats what it is for now. Letâs keep in mind that in the future it will probably be a node. Itâs just really hard to tell how that system will be as of now, so itâs difficult to say how it should work for now.
(TonR: removed image, not allowed to share or discuss screenshots of commercial apps here)
In Houdini there is a âScene Levelâ and a âObject Levelâ and finally a âNode Levelâ. All the screen shots Iâve posted previously have been on the Node Level. Basically, the scene level is the highest level, and can kind of be considered the outliner. This is where you choose what âthingâ you are working on. In this case I made âDevtalk Geoâ in the red. If you double click on it, it will take you to the object level, here is a small graph of nodes that would technically be where âmodelling nodesâ would be. As you can see there is a particle node in red here. This is what would be a nested Particle system in the context of object data. Once more, if you double click the particle node you are bought into the node level. This is where you make your changes to the particle tree. So those are the three level.
However, if you noticed there is also some things in green I have been highlighting. In the Scene level this is a particle system that is independent of any object. That is essentially putting a particle system as itâs own object. That very same particle system is also being referenced with a node at the object level. So basically Houdini has both nested and independent particles systems.
So whatâs the point of all this? Well, I think there might cases where you want a particle system as an independent function, but also times when you want is it nested in an object. Specifically, when we get modelling nodes, we might shoot ourselves in the foot for not having nested particle nodes, as they can be super helpful to make objects.
Here is a slime thing I made just now. This is using a nested Particle node. Here is how it works:
A Base sphere is plugged into a nested particle node. This nodes deleted the sphere and uses its surface to creates points. I then copy to these points another sphere to create the bubbles. I then re-use the base sphere, then the whole thing is turned into a VDB to weld it all together, then finally it is outputted as polygons. Simple enough.
If the particle node we are proposing now is completely independent, and itâs own object, then in order to create something like this you would need modelling nodes inside the particle tree. Which is it then? Particle nodes and modelling nodes?
I know this is a super long post, but I hope that makes sense.
To summarize: I think we need both an independent particle node and a nested one to achieve great things.
7 Likes
I think that using particle as a modeling tool is expected. But that does not change the need to preview particles emissions and movements.
Finally, you will end up to visualize these particles as dots or circles. Although they are used to create mesh deformations or explosions.
So, having them as an object that could be easily hidden and is directly visible and reachable by using outliner, IMO, it looks like the best way to notice that particles are used in the scene.
You can argue that as a nodegroup user could tweak internal settings of particle settings and easily switch to modeling nodes.
But I think that a simple modeling node to use a particle system object like current emitters nodes are referring to emitter meshes would be sufficient.
We could imagine a synchronization between node editor and object selection.
So, basically, switching selection from a procedural mesh object to a particle object would update Node Editor to show pertinent nodetree type.
So, one part of complexity would be handled by outliner and the rest by node editor.
Procedurally created objects will probably not be limited to one mesh, too.
As booleans, they could be made of several animated objects.
There was an intention to create an OpenVDB primitive to load OpenVDB grid files.
We could expect a particle system object, an OpenVDB object and a procedural mesh generator object.
So, a particle system object would be just another object type from a tendency to give a simple access to complex construction managing a big amount of data.
No. It is just the node Turn into Polygon that gives a mesh as a result.
We could simply have an OpenVDB object or Procedural Mesh Generator using only one node to convert a particle system into geometry or OpenVDB grid.
This process could be automated. Alt C shortcut could be sufficient to to set-up such thing.
And seriously, we can already obtain that result, just with metaballs.
I will make a mock-up about my tab proposal when I will find time.
But for the moment, here is an illustration about what reroute node allows us to do.
For merging Inputs , in facts, there are 2 Reroute nodes that are at same position.
Currently, a Reroute node can handle only one input and can distribute several outputs.
But it would be good to add ability to reroute node to handle several Forces and Emitters as inputs instead current situation.
We are forced to connect them directly to Particle Type node, then, to subdivide connection with new Reroute nodes and then, to snap there location to Reroute nodes of connections already present in nodetree.
I donât think nested particle nodes really prevent you from visualizing particles. Currently, modifiers can be turned on and off, right? So when we get modelling nodes I can only assume the same behavior would be present, meaning you can turn on/off things until you see the particle node, then you just see the particles. Iâm hoping we can also get a âflagâ system like houdini (or something like it), where you just click a âviewâ icon on a node and you see the object at that point of the tree. That way you need not turn off/on a bunch of nodes, just clicking on a node to decide that it is the final output.
If I understand this correctly, I want:
1)Within a modelling tree, you have a particle node that if you click on it, the editor switches to particle nodes.
2) An independent particle node âobjectâ that has no restriction and easy outliner access.
Whereas you want:
- An independent particle node âobjectâ that has no restriction and easy outliner access. This particle object, if clicked, opens a graph editor that on top of having particle usage, also has the ability to reference a modelling tree within a node. If you click this referenced modelling node, you will jump to the pertinent modelling tree.
Is that correct @RonanDucluzeau ? I may have that wrong.
Well, it was just one example, I meant it more just to show the idea that modelling with particles is powerful, but you seem to already know that! Also yes, using Animation Nodes you could use metaballs to create that for sure, but if you, say, used cubes instead of spheres I donât think you can. At least until we get a VDB node or something.
Regardless, think your method is going to run into problems. If you go back to my slime example, an object is going into a particle node, but then a large chain of modelling still continues after it. So if we have an independent particle object with a tree inside, then we reference a modelling tree within it with a node, we can then do other particle operations after that modelling node. But then what if we want to do more modelling operations after that? Do we need an output to modelling node then? We would also probably need a import geometry from particle node, or something like that so we can pick it back up on the modelling side of things. The point is that just to produce one object, we are going into 2 different editors with multiple referencing nodes. I think itâs just too convoluted. I think that for modelling, being able to dip into particles with a nested particle node is best, and when you want to do purely particle based things an independent particle node âobjectâ is the way to go.
Anyways, this is getting pretty interesting, but also very high level. I think we need to clarify a bit with Jacques, as we are getting into larger topics like modelling nodes and overall integration. Iâm very curious to see how he feels about this. Hopefully these conversations are helpful for him.
1 Like
Turning things on/off is what I would like to avoid. I think it is always welcomed to be able to display geometry generated by particles and particles at same time, in Viewport under Wireframe or X-ray mode .
No, it is not the behavior, I am describing.
I want a particle node into modeling tree but that is just an input node. Selecting it does nothing except giving ability to move, connect or delete the node.
An independent particle node object visible into outliner, restriction set-up by user.
This particle object, if clicked in outliner or selected in 3DView, changes opened node editor displaying a node graph made of compositing nodes or modeling nodes, into a node editor displaying its node graph about particles.
If there is no already opened node editor into workspace, selecting the object is just a current object selection.
Then, if you want to go back to modeling nodes, you do the same by selecting OBJECT that supports modeling nodetree.
There is no need to add complexity to UI and change it by selecting nodes.
Yes. But that is a pertinent example that shows what will be most of cases. Things that will not be very complex. Just a remeshing from particles or a mesh generated by boolean operations emitting particles.
The interest of OpenVDB is clearly to avoid to go back and forth many times between particles and meshes.
Basically, result of modeling nodetree is just a mesh. Inside particle nodetree, it will be treated as any other mesh.
Just create another object that uses the first one emitting particles or particles system as an input node.
You have more objects to deal with but all of them as a simple node tree instead of a unique object with a really complicated nodetree.
We are dealing with 2 different editors but what I described is that we could automatically switch same area between both. That would not be more disturbing that switching from shading nodetree of a mesh and shading nodetree of a light by selecting them.
That would be equal to switching from general modeling nodetree or internal nodetree of nested particle node with Tab key.
And if user has enough space to display both editors into his workspace, he could visualize both trees at same time.
That would not be different than trying to have 2 areas dedicated to same editor displaying global modeling nodetree and internal nodetree of nested particle node inside modeling nodetree.
I uploaded an updated proposal that takes some of the feedback into account.
Let me know what you think.
https://wiki.blender.org/wiki/Source/Nodes/UpdatedParticleNodesUI2
6 Likes
My first impression is that this seems like an improvement over the first two proposals.
I agree with your assessment of the âexecuteâ inputs - the example you show in this proposal looks very messy to me and I agree that there is probably a better solution. (But I donât have any ideas as to what that might be.)
While not strictly necessary, an often requested nice-to-have-feature is an output node . In this design, the Particle Type node looks like an output node. There can be multiple though. Nevertheless, it can help to orient yourself in the node tree.
Nice, that works for me.