Regarding the Simulation Architecture proposal

Hi there, I read this article:

It’s very interesting, but I feel that the direction taken there will make VERY hard to mix different simulation types, and this is very important to make a modern simulation framework.
For example, we need easy ways to make a force interchange between rigid bodies, mantaflow and particles, not just 1 way interaction like right now.

Without that possible communication we will end with the same that we have now, isolated simulation worlds filled with limitations.

Since this is setting the basis of a simulation framework for E.N. , I think it’s pretty important to take this into account for the future and find a proper solution, (in the similar style as Houdini, that are “micro-worlds” that can talk to each other, they are just solvers)

What do you think @jacqueslucke and others?


On the wiki page, it is explicitly said that we are forced to go with this 1 way interaction because we don’t have at disposal a solver for everything.

If you know one that could be used, they could start to build something around it.
But without this starting point, I don’t see how they could deviate from current system.

One of the main goals of the proposal is to make it easier to have different kinds of simulations that interact.

Every simulation has a “step function”. That is the function that is executed to get from the last simulation state to the next simulation state. Currently, there is no specific time in Blender when all step functions for simulations are evaluated. Many simulations are just evaluated as part of the modifier stack. That makes it difficult to have more complex interactions.

The document proposes one possible approach on how a more centralized approach to simulations can look like from the code architecture point of view. When different kinds of simulations should interact with each other, they have to be in the same Simulation World and there has to be a solver for the combination.
When the dependency is only in one direction, they can be in the same of different Simulation Worlds.


So the idea is to give the different solvers a moment to sync with others and transfer forces, that is great then, this will probably allow multiple physics implementation to interact, the key thing would be… what would be the “languaje” for them to understand each other?
In the end everything is a force in a physics simulation, so probably a proper vector field implementation could be enough as long as all the physics solvers are able to understand vector fields, from particles to cloth, RB or mantaflow.

@RonanDucluzeau in Houdini there is no Master Solver, you mix different solvers in the same simulation, this allows to mix different solver, wich is what I was speaking about, with that “step” part, this may be solved :slight_smile:

I don’t know. My experience with the internals of any specific solver is basically zero. I don’t make any assumptions about that currently. This has to be solved on another day.

Also note, when I talk about “simulation”, I do not necessarily mean physic simulations (although that is the most common use case).


Ok, but don’t leave it for a “we will do it later”, it’s important to tackle this point now in the most basic fundaments of the architecture, in the begining, so the system is future proof and has not caveats that will make any new simulation system impossible to talk with others, so we repeat the same situation as we have now, but just with nodes.

I’m sure people like @sebbas or @scorpion81 can give you a bit more deep view of things regarding simulations and interoperabiltiy, what may be needed and such things :slight_smile: regarding physics, but I think this should be a general way to work, particles (non physical driven ones) also, and other type of procedural content also.