@Sergey Sharybin (sergey) The thing that is missing here is that we have to tag the depsgraph someway that the cloth brush is going to use collisions.

When using modifiers, we can use DEG_add_collision_relations. But neither Pablo or I am sure how we should add this relation when using a tool/brush.

Now we hack around this by adding an other modifier to the mesh that adds this relation (so that the collision data is available). But this is not a good solution.
So we are wondering if you know any good way to do this.

Well, ok. Couple of things here:

• There is no such thing as dependency to/from a brush, as the brush is not covered by the dependency graph (while it is internally an ID, it is considered a tool/interface).
• You wouldn't want to add/remove relations on stroke begin/end, as rebuilding relations is not entirely cheap and you don't want any lag.

Easiest is probably to consider that brush is handled from an evaluated dependency graph state, which would mean that all colliders are at their final evaluated state. And then for the brush/sculpted object you "by-pass" dependency graph by providing explicit list of colliders (ideally ,without using temporary modifications to the object).

@Sergey Sharybin (sergey) If the way of initializing the colliders using bmain is ok, then I think this should be ready for 2.91

If the way of initializing the colliders using bmain is ok

Not in this way, no. bmain is a pointer to the main database the depsgrah has been created from. In general case, depsgraph will be created for a subset of them. This means that ierating the bmain and requesting evaluated IDs for objects from the bmain is wrong, as there might not be such an object.

You can iterate over objects from the depsgraph using the DEG_depsgraph_query.h.