However, in the case of physics collision, cycles are actually supported in a limited way by the underlying system via using the saved collision data from the previous frame.

This is VERY fragile assumption, which nowadays never work when you render animation (because there is simply no previous state in this case). It also known to cause issues when you open file which is somewhere in the middle of timeline.

In order to allow using this behavior, dependency graph should know which relations are collisions, and prefer deleting them if possible when a cycle is detected.

Not sure what exactly you mean by "should" here.

In a more ideal world the physics solver should have a dedicated depsgraph node which will receive all colliding objects, run solver, calculate momentums and what not, apply them, continue with modifier stacks of every colliding object. Just similar to IK solver and rigid body simulation (to certain extent).

This is a bigger project than this patch though. Not sure what are the plans about physics solvers and if there is nothing planned in the observable future then depsgraph "could" allow the behavior you've described. With proper indication that this is not amortized way of designing features and that it's caused by design limitation in physics area.

This adds a new relation flag that marks collision relations.

What are the rules of using this flag? I see similar cases when same components passed to DEG_add_object_pointcache_relation will be marked as PHYSICS_BREAK_CYCLES and sometimes they will not.
That's confusing and will likely be fragile (tweaking those flags to solve specific report without being able to easily validate all previously fixed cases).

When resolving a cycle, collision relations going backward in the alphabetic order of object names are chosen as primary candidates for removal; this predictably resolves all cycles between multiple objects all colliding with each other.

That's interesting. Is it possible to extend this predictable cycles solver to other cases as well (not just to physics relations) ?

The depth first search cycle detection algorithm had to be enchaced to unwind the stack to the relation being removed; otherwise it cannot correctly detect all cycles.

Can this be applied as a separate patch?

This would already been a problem with the godmode flag, but it's not that obvious there, as that flag is rare.

The godmode flag was introduced to avoid possible relation removal from INIT to CLEANUP, which was causing weird and wonderful threading issues. Think we should be able to remove this flag and adjust cycles solver in a way that it prefers to kill relation between two different ID, or between different components of the same object, and as last resort kill relation inside same component.
Just saying, this is a separate story.

In D6494#152755, @Sergey Sharybin (sergey) wrote:

This is VERY fragile assumption, which nowadays never work when you render animation (because there is simply no previous state in this case). It also known to cause issues when you open file which is somewhere in the middle of timeline.

Physics is inherently stateful, so not having any previous state means by the time render is performed all physics must be cached (baked). If you want to somehow compute physics "without state", you basically require a way to backtrack in time until you find a cached previous state or reach the start of timeline. You simply can't simulate physics just from nothing.

Btw, the collision modifier is already stateful: it stores not only current position, but also calculates velocity by comparing with the previous position, and that is used later for subframes and collision math.

Also, unrelated to this patch, I'm actually thinking about adding even more state: I want to know the velocity of the object for applying some forces - basically I want an option for the Drag force that would drag things together with the movement of the effector, so you can e.g. pull on cloth. Any suggestions re how to fit this in?

In order to allow using this behavior, dependency graph should know which relations are collisions, and prefer deleting them if possible when a cycle is detected.

Not sure what exactly you mean by "should" here.

Well, the cycle solver must know which relations should have special behavior.

In a more ideal world the physics solver should have a dedicated depsgraph node which will receive all colliding objects, run solver, calculate momentums and what not, apply them, continue with modifier stacks of every colliding object. Just similar to IK solver and rigid body simulation (to certain extent).

This is a bigger project than this patch though. Not sure what are the plans about physics solvers and if there is nothing planned in the observable future then depsgraph "could" allow the behavior you've described. With proper indication that this is not amortized way of designing features and that it's caused by design limitation in physics area.

Thing is, since collision is a modifier in the stack, you can do weird stuff with it, like adding more modifiers between cloth and collision. This would require redesigning the collision feature.

This adds a new relation flag that marks collision relations.

What are the rules of using this flag? I see similar cases when same components passed to DEG_add_object_pointcache_relation will be marked as PHYSICS_BREAK_CYCLES and sometimes they will not.
That's confusing and will likely be fragile (tweaking those flags to solve specific report without being able to easily validate all previously fixed cases).

Well, currently I only use it for relations related to collision and depending on geometry, but not forces, or collision dependencies on object transform etc. I.e. those relations that actually cause the cycles when you have multiple cloth objects.

Btw, what is that point cache relation thing all about?

When resolving a cycle, collision relations going backward in the alphabetic order of object names are chosen as primary candidates for removal; this predictably resolves all cycles between multiple objects all colliding with each other.

That's interesting. Is it possible to extend this predictable cycles solver to other cases as well (not just to physics relations) ?

Maybe, but this is mainly targeting dense cyclic sub-graphs, like when you have a set of objects which each depend on all of the others. Sorting the objects in some stable way and killing 'wrong direction' links is a simple and reliable way to solve it. This heuristic is also only guaranteed to work if you can kill any relation in the cycle, so in a hybrid physics/non-physics cycle involving multiple objects it can fail to solve the cycle, depending on object naming.

The depth first search cycle detection algorithm had to be enchaced to unwind the stack to the relation being removed; otherwise it cannot correctly detect all cycles.

Can this be applied as a separate patch?

I guess so.

This would already been a problem with the godmode flag, but it's not that obvious there, as that flag is rare.

The godmode flag was introduced to avoid possible relation removal from INIT to CLEANUP, which was causing weird and wonderful threading issues. Think we should be able to remove this flag and adjust cycles solver in a way that it prefers to kill relation between two different ID, or between different components of the same object, and as last resort kill relation inside same component.
Just saying, this is a separate story.

It's mainly the case that if you kill a relation up the stack, you have no right to be in that sub-tree anymore, and have to backtrack and unwind the stack. Otherwise, for example, you may encounter a case where you find another cycle, but you have seemingly 'already resolved it' via that killed relation, and that completely breaks the logic of the algorithm. Without backtracking the cycle resolver totally fails on 3 inter-colliding objects.

Btw, the collision modifier is already stateful: it stores not only current position, but also calculates velocity by comparing with the previous position, and that is used later for subframes and collision math.

This is fine if you are baking or doing playback in viewport starting from frame 1.
It wouldn't work if you start animation render without baking or caching first.

Also, unrelated to this patch, I'm actually thinking about adding even more state: I want to know the velocity of the object for applying some forces - basically I want an option for the Drag force that would drag things together with the movement of the effector, so you can e.g. pull on cloth. Any suggestions re how to fit this in?

That very quickly escalates to a desire of pulling cloth based on a rigged character. Object velocity will be 0 in this case, but vertex velocity will not.

Not really sure what is the best approach here. Here are the following cases which doesn't fit the idea of using previously known object state:

• Animation render (no previous state, current state is evaluated from scratch for every frame), or rendering of single frame from command line
• Motion blur render (order in which scene will be updated for subframes is not strictly defined)
• Fast-forward in the timeline (jump from frame 50 to 100)
• Framedropping/AV sync
• Transform (what is the desired speed when you move object)
• Probably something else.

Anyway, there should be a solution, but lets move discussion somewhere else.

Well, the cycle solver must know which relations should have special behavior.

I disagree with such wording. Area must be designed in a way that doesn't require other areas to work around its weirdeness.

Btw, what is that point cache relation thing all about?

Physics gets cached to a pointcache. This cache is to be invalidated when you modify scene (i.e. when you move object around, change physics settings and so on).

In D6494#152782, @Sergey Sharybin (sergey) wrote:

Btw, the collision modifier is already stateful: it stores not only current position, but also calculates velocity by comparing with the previous position, and that is used later for subframes and collision math.

This is fine if you are baking or doing playback in viewport starting from frame 1.
It wouldn't work if you start animation render without baking or caching first.

From frame 1 is the ONLY way physics can be evaluated. You can't jump in time, unless you have it cached.

In other words. if you have it cached, you can jump in time, and you don't care about state because nothing is being evaluated anymore. If you don't have it cached, then you care about state, and you inherently can't jump in time.

Also, unrelated to this patch, I'm actually thinking about adding even more state: I want to know the velocity of the object for applying some forces - basically I want an option for the Drag force that would drag things together with the movement of the effector, so you can e.g. pull on cloth. Any suggestions re how to fit this in?

That very quickly escalates to a desire of pulling cloth based on a rigged character. Object velocity will be 0 in this case, but vertex velocity will not.

When you speak about vertex velocity you get into the area of collision - it has friction, although I'm not sure how well it works.

Here I'm mainly thinking it would be good to have a fully custom user controlled 'pull' effector, so instead of trying to simulate the real physics by sandwiching cloth between colliders or whatnot, you could just directly apply a force where you want the cloth to be pulled, and be done with it. Then you can just animate whatever is actually 'causing' the pull on top without it being an actual part of the simulation. I.e. it would be a targeted tool for more directly making the cloth do what the animator wants, instead of a more hands off 'realistic' simulation.

Not really sure what is the best approach here. Here are the following cases which doesn't fit the idea of using previously known object state:

• Animation render (no previous state, current state is evaluated from scratch for every frame), or rendering of single frame from command line
• Motion blur render (order in which scene will be updated for subframes is not strictly defined)
• Fast-forward in the timeline (jump from frame 50 to 100)
• Framedropping/AV sync
• Transform (what is the desired speed when you move object)
• Probably something else.

None of those things can or should be simulating physics. Physics is inherently stateful, and has to be evaluated in order.