Page MenuHome

Boolean Operation is slowing down objects transformations even it it's disabled in the Modifier Panel
Closed, ArchivedPublic


System Information
Win7 x64

Blender Version

Short description of error
if you have a boolean modifier applyied between high poly objects it's ok that it is slow to update so when you move/rotate/scale it we got some lag, but it happens too even if the object is disabled for the realtime 3dview and the render in the modifier panel. We should't have a check for that for true disable this object in the Boolean Operator?

Exact steps for others to reproduce the error
In this demo we have a result object , a high poly sphere and a low poly cube both applyied as a boolean modifier difference.
The sphere is turning the result a high poly and is slow to move it in the viewport, it's ok since it is a hgh poly mesh applying a boolean operation.
But the modifier that apply the boolean operation for the Cube is disabled for the viewport and the render, but even with this it's slow to move too as if it's applying the boolean operation, but it's not.

There's no change if the Boolean of the cube is in the top of in the bottom of the stack too. It's lag at the same way.



Event Timeline

Vitor Balbio (vitorbalbio) created this task.
Vitor Balbio (vitorbalbio) raised the priority of this task from to Needs Triage by Developer.
Sergey Sharybin (sergey) closed this task as Archived.
Sergey Sharybin (sergey) claimed this task.

This is a design limitation of dependency graph, which doesn't check on whether modifier is enabled or disabled when building the dependencies. Perhaps could be solved as a major dependency graph re-work project.

@Lukas Toenne (lukastoenne), think you would want to keep your radar here :)

Thanks for the report, but not considered a bug.

It seems that in this case the unnecessary updates by the depsgraph could well be avoided in principle. When the modifier is disabled the depsgraph should treat it as if it didn't exist, i.e. not call the updateDepgraph callbacks in such modifiers at all:$574

We have to be a bit careful with this though, there are lots of hacks that can make the depsgraph react to such a change in unexpected ways.

Also note that it is quite easy to produce only slightly more complicated cases where the data->data dependency of the boolean modifier is still created, due to lack of granularity in the depsgraph (e.g. a later modifier that is much simpler but also uses the cube's geometry would force the boolean modifier to update too). These issues would only be solved with the depsgraph refactoring.

Overall this is not strictly speaking a bug, but worth investigating, since there is a straightforward solution at least in theory.

Correction: @Sergey Sharybin (sergey) noted that we don't have a distinction in the depsgraph of render/viewport/preview/baking context etc. yet, so unfortunately we can't selectively disable these dependencies :S

Has to stay a todo until depsgraph refactor ...