Simulation Nodes

[JuanGea]

You can have that information, the camera it’s just an object, the distance is the distance to the object, and you can compute the fustrum of the camera to calculate the margins (I don’t remember how to calculate it right now, but you can do it), also you can have an attribute and use a driver to link it to your camera data so it’s updated and inside the node tree, there are solutions for what you say

[Caner-Aslan]

Adapted Sean Christofferson’s string tutorial to curves and modified a bit. I sense so many possibilities . Can’t wait devs and people like Sean will come up in the future in physic sims department.

[brecht]

@Viktor_smg

Well, I would expect data outside the simulation zone to be fed into it as the simulation progresses, the simulation state being separate and not affecting anything else, rather than just at the start, and I would really expect a blank simulation zone to not change anything at all. Cloth/softbody simulations work with animated deforming modifiers before them, this should too.

You can feed the animated geometry from outside the simulation zone into the zone, by not going through the Simulation Input node. And then you have both the animated and simulated geometry, and can transfer the position from one to the other with the Sample Index node, and combine the animated and simulated positions in some way.

How exactly they should be combined depends on the simulation, there’s no one automatic way to do it. You could for example mix them based on painted goal weights like cloth and softbody support.

[Xeofrios]

These are some of my opinions after a long-ish project with Simulation Nodes. I have also used them in many smaller projects before.

• My experience has been amazing! The system is surprisingly intuitive and fast to use.

• This project, in particular, had many simulations referring to each other (eg. the Icing sim referencing the “pour” sim, the sprinkles sim referencing the icing sim, and some others changing the detail level when moving). The data flow never became confusing and simulations worked without any hiccups.

• I have never used delta time. It would have been more useful if it outputted time intervals using the actual FPS during viewport playback. For example, the sprinkle generation is based on the speed of moving the bottle. When the scene becomes heavier due to the other simulations, the FPS decreases. Because the simulation assumes ideal FPS, the calculated speed is more than the actual speed.

• I did not find any way to save the simulation progress without applying the modifier. I already discussed this in the Twitter post.

• The process of finding the value of an attribute/single value requires storing the value on the geometry. Is it possible to do this with a single inbuilt node? For example, this is how I calculate the velocity
  

  

• Since this setup requires saving attributes on geometry, it doesn’t always work. Here I tried to add points based on the speed of another object and it does not work for obvious reasons.
  

  
  
  Using Attribute statistics solves the problem
  
  
  
  But what really confused me was that using the simulation sockets, it worked as “expected”
  
  
  
  What is going on here? If the data is saved on the previous points how can the Points node access it? Is the data somehow being saved on the object level instead of the geometry?

• This is not exactly sim nodes related, but drivers were a pain. Since the nodes were not contained by the objects the user interacted with, I used drivers to pass on the data. Duplicating nodes removed any drivers and colour drivers required copying the RGB values individually.

Thanks for reading! I hope you found this feedback useful.

[seanterelle]

Hi, Sean here! I’ve had a lot of fun with simulation nodes so far. My main projects have been physics simulations using position based dynamics. I’ve also worked on a 2D eulerian fluid simulation as well as a couple different methods for simulating terrain erosion.

As mentioned in previous posts here, the ability to get attribute data within a certain distance of the currently operated element would be helpful. As others have noted there is a way to achieve this (Entagma’s n^2 workaround), but having an optimized method would be even better! For instance, when attempting to implement position based fluids, a key step is creating constraints between surface particles to simulate surface tension. One way to determine if a given particle is a surface particle or not (as well as calculating the surface normal) uses the positions of neighboring particles within a certain radius. I couldn’t find a way to do this without the n^2 workaround. I find myself wanting a “statistic of nearest” node that would take geometry, attribute, and radius inputs and have outputs the same as the attribute statistic node. Another more general solution would be a way to get a selection of nearest points on an input geometry to the current element within a certain radius, which could then be used as an input to the attribute statistic node.

Other than that I’ve run into no major roadblocks and simulation nodes have been a joy to work with! Many thanks to all the developers. I’m looking forward to both serial and parallel loops and all the other wonderful functionality that’s in store

[Xeofrios]

An update on this point

@Xeofrios

If the data is saved on the previous points how can the Points node access it? Is the data somehow being saved on the object level instead of the geometry?

I watched the Blender Studio sim nodes tutorial and it turns out it is actually possible to pass on data as a “single value”. This is a welcome addition but IMHO still a bit confusing. Partly because of the intuition I have developed over time and partly because the domain still shows up as Point

Other than that I am not too fond of the idea of limiting this feature to the simulation sockets. Store Named Attribute is much more convenient when using a larger number of attributes. Maybe single value can be added as a new domain?

[Strike_Digital]

+1 for adding a “Store single value” node, or allowing named attributes to just be single values rather than being duplicated for every item in the geometry.

I know it’s possible to do everything with links, but it just gets so messy so fast that I often resort to storing these single values as named attributes, so that I don’t have links stretching across entire node trees.

It’s also nice being able to give a name to the values, which can really help with the readability of a node tree (e.g. being able to see that a value is controlled by an attribute called speed is much nicer than having to pan the full node tree to see where it is defined and then panning all the way back to see what it does.)

[Baardaap]

There are good reasons to have a ‘single value’ domain (though it’s not exactly trivial. how do you handle that domain across join/realize instances etc. But that is solvable and we still need to solve that for “active color attribute” as well) but this is imo not a good reason:

@Strike_Digital

so that I don’t have links stretching across entire node trees.

That’s the equivalent of a ‘global variable’ in programming. Which is frowned upon for very good reasons.
Much better would be to implement one of the proposals for ‘link portals’ ‘hideable links’ etc which actually address the UI/usability problems of long links.

[DamianWinnichenko]

As for the latter, do you mean you need something like this?

[Strike_Digital]

@Baardaap

Much better would be to implement one of the proposals for ‘link portals’ ‘hideable links’ etc which actually address the UI/usability problems of long links.

Yeah, that’s fair, portals would be much better for this.

@DamianWinnichenko

As for the latter, do you mean you need something like this?

Yeah, that also works, it’s just a little bit of a pain to have to route the links over long distances. Something that might make it a bit better is if the labels for reroutes could automatically propagate from the source socket, so that you don’t need to spend ages renaming every reroute to see what it does.

Either way it’s not a major problem, just more of a paper cut I’ve run into a lot recently

[TheJeran]

Is it possible to set the starting frame of the simulation? I do a lot of animation and would like simulations to start later in an animation. The best I have come up with is a simple boolean that passes the data along without simulation until the frame I would like. But then I need to start at the first frame to begin the simulation which is not ideal.

[nickberckley]

I needed that too. I think Simulation Input node should have Frame Start property, where you can insert on which frame you want it to start. That’s the easiest it can get UI-wise

[Rusculleda]

You can with a switch node like this, animating the switch value or setting a frame condition:

The moment the switch value starts being true the simulation starts being evaluated.

[Xeofrios]

@Baardaap

though it’s not exactly trivial. how do you handle that domain across join/realize instances

I would not argue that this problem is not relevant to the discussion since it already exists for the current geometry domains. For example, the union of two meshes using mesh boolean

I do not consider this to be the “correct” result, but the point is that this is not a new problem.

[Baardaap]

That’s a related but different issue.

It looks a bit like a bug to me actually. it is to be expected that the newly generated points are the default color, but the existing points should keep their respective attribute values I’d think.

edit to elaborate:
In case of a single value domain it’s fundamentally unclear how to join those. We’d need to decide on a way (pick the first? last? average? weighted average depending on size of mesh? ).

This is more of an imperfect implementation. I’d argue that it’s quite clear what the desired result should be (All existing points keep the respective attribute values, filling in with the defaults if the attribute does not yet exist on that point. The newly generated points should get the average of the values of the surrounding edges.)

[DamianWinnichenko]

You might also like this:

Duplicate Group Input node, connect the socket, then press Ctrl+H to hide unused. Super neat!

[Xeofrios]

As far as I know, that is not possible with sim nodes

[dfelinto]

I was going to point you to the example files. In the Index of Nearest demo velocity is passed as attribute, without using Store Named Attributes.

From what I’ve seen so far this seems to be one of the biggest hurdle of the system. Despite the demo files, most people seem to first consider using named attributes.

---

I think I understand what you mean by Single Value. Basically you would like for a socket in the Simulation to not be a field, right?

For example like this:

Other than that I am not too fond of the idea of limiting this feature to the simulation sockets. Store Named Attribute is much more convenient when using a larger number of attributes. Maybe single value can be added as a new domain?

I don’t understand this. (and maybe I didn’t understand your original point at all)

[Xeofrios]

@dfelinto

I was going to point you to the example files. In the Index of Nearest demo velocity is passed as attribute, without using Store Named Attributes.

Yes, I figured that out after watching the Blender Studio tutorial

@dfelinto

Despite the demo files, most people seem to first consider using named attributes

That is basically the main issue. Using the simulation sockets becomes really inconvenient for a large number of attributes (or nodes in general).

[RiccardoBancone]

@dfelinto

I don’t understand this. (and maybe I didn’t understand your original point at all)

Hi, I’m not sure If I correctly got the discussion point here, but as far as I understand, there is the need of a new domain to store a single value, related to the whole object. Just like a normal programming Variable.
And this is not only needed just in relation to simulations, but to the whole Geometry Nodes System , or even to the attribute system.

Other node based software calls the domain “Detail Attribute” (Quite confusing and unintuitive name if you ask me) And it’s pretty useful.

Some examples that come to my mind are for example:

1. Number of points of an object, it is output by the attribute statistic node, but if I want to store it, I’m forced to store it on every single point of the mesh as a pont attribute (or any other domain) . Or am I missing anything?

2. A string label, like a name. So far we have String Attributes, but as far as I understand, it’s saved on every element of the domain. But what if I want to store a string that is related to the whole object, or a big piece of it?

A possible reasonable name could be

Single Value
Single Variable
Single Value Attribute
Just “Variable” in opposition to “Attribute”
Collective Attribute
Global Attribute
Object Attribute

About the last one, I’m not sure it’s convenient, since I can foresee more “instances” of the same variable in the same object. So It’s not necessarily a single value per object, but rather single value per chunk of geometry.

Let me know your thoughts, and if you think that it makes sense!