Just a small thing…
I noticed that the Simulation modifier is after Soft Body in the modifier menu, so they are not alphabetically ordered.
Anyway, keep up the good work!
idk if this was mentioned in the grand openvdb, prt debate, but blender’s mantaflow seems to be exporting particles in the openvdb files aswell (when you open a mantaflow vdb file from blender in blender, it’ll be basically the domain as a solid volume and there’ll be a note about particle channels not being supported). So blender being compatible with itself should probably be a point of consideration too
2 Likes
It’s nice to start playing with these particles again, but this time in master 
Having some fun with the color-to-vector conversions:
21 Likes
quote=“dfelinto, post:1, topic:14588”]
Multiple inputs for the same socket (needs design solution)
[/quote]
Maybe I missed something, but Why not just use “add node”, and allow just one input per socket?
Like - " Add shader", “Add event”, “add force” Etc…
3 Likes
@jacqueslucke Do you still have confidence in this product? Just Curious. I think it is going in a OK direction for now.
Yes, I do. However, the communication has to be improved, so that it becomes more clear where this is going. This will be discussed in more detail next month when I’m in Amsterdam.
10 Likes
Second test of Blender New Particle System on Blender 2.91 Alpha
Nice crossproduct node.
6 Likes
4 Likes
@jacqueslucke Huge congrats for the whole idea of Particle Nodes and its implementation! Saw the post from Particle Nodes Status and reference materials of ManvsMachine - amazing (@dfelinto). So I have a question regarding some functionality.
I’m using Particle Nodes and Sverchok for procedural design and animation. The only one thing I cannot do right now using both of them is differential mesh growth. Houdini is king here : -
Question: Any chances to see that feature available in Particle Nodes? Here’s the reference of what I mean exactly:
7 Likes
A couple tests with the new system:
Edit: I have to mention that it’s very nice how the system manages to interpolate the “between frames” movement of the emitter so smoothly!
21 Likes
@jacqueslucke I think the particle attribute node should perhaps display a list of common attributes rather than having you input the name manually, like this:
This is already a standard of convenience in blender what with the texture coordinates node, object info, geometry node from shading etc. If you are a bit worried it might be too long I don’t mind having 2 separate nodes, one like the current where you manually type in the attribute, and another like this with several commonplace attributes. It could also have functionality like in animation nodes where you can open the “N” panel and add/remove attributes from a larger list.
11 Likes
I partially agree. I do think that it is too cumbersome to type the attribute name in every time. That has to change eventually.
I’m not sure I agree that there should be a single node that outputs many of the attributes. That often leads to node trees where there is one Particle Attribute node at the very left and it has many long links to other nodes in the node tree. I prefer it when the you have multiple Particle Attribute nodes, which are placed exactly where you need the attribute. I think that makes the node tree more readable. There are of course multiple ways to achieve this.
When we provide a Particle Attribute node that outputs multiple attributes, it should probably be a node group. You can build such a group already.
12 Likes
Not necessarily - the user can duplicate this node and place it wherever they want, and further hide unneeded outputs. This is what I have been doing with the Cycles attribute nodes (geometry, texture coordinates, etc) and it works fine imo, at least visually. Would it have a negative impact on performance ?
After all these “basic” attributes (shown in picture) are going to exist in any case, right ? User-created ones can always be specified by name either from a different node, or from the same one.
1 Like
See shader group input node, it can and should be instanced/copied multiple times throughout the tree to cut down on long links.
edit: and I mean it can.
I think that what @jacqueslucke means with this is to find a way to “force” the users to keep the trees as clean as possible, because if the default node is the big one, then it will happen, in general, what he says, on node with long links, if there are several attribute smaller nodes, they will be used separatedly.
So it’s not a matter of what “can be done” but a matter of what “should be done” more or less 
4 Likes
Sure, but I mean so long as what I previously mentioned is possible(instanced node) then that’s all that matters. I wasn’t particularly making a counter argument to what he stated.
Though I do think that having an option of exposing all the sockets could be on the table. Note sure what socket would initially be exposed in that case. In the group inputs we have now in shader nodes we have to hide unused sockets on a node, which is sort of the reverse.
Maybe we could have an input node then where we can pick from a list of available options to add the sockets we need onto a single input instance?
TL;DR: I’m not even sure that attribute and input nodes need to be separate.
2 Likes
Have an attribute node, with one output and a pulldown to select which.
We dont need them that often, then it becomes smaller its taking a lot of space.
1 Like
Subframes. My question is not quite about UI but I consider it very important for the future production. From the current system’s behavior I propose that at the moment simulation particles’ states update only once per frame. Particles don’t move between frame 1 and 2, they just jump from one position to another when the frame changes. I believe we really need a possibility to control the number of substeps for the simulation, playback and render in the future, ideally - independent for the playback and the render. Subframes are necessary for many features like motion blur, smoke simulations and time remapping. Of course there always may be weird user workarounds but as soon as it is possible to avoid them at the development stages with adding substeps into the original system, it would be much appreciated.
4 Likes