Page MenuHome

Depsgraph: Implement backtrace functionality
ClosedPublic

Authored by Sergey Sharybin (sergey) on May 24 2022, 11:51 AM.

Details

Summary

The goal is to make it easier to track down sources of errors during
the dependency graph builder.

With this change whenever a relation can not be added a trace to the
entity which requested the relation will be printed. For example:

Failed to add relation "Copy Location"
Could not find op_from: OperationKey(type: BONE, component name: 'MissingBone', operation code: BONE_DONE)

Trace:

Depth    Type                     Name
-----    ----                     ----
1        Object                   Armature
2        Pose Channel             Bone
3        Constraint               Copy Location

On an implementation detail traced places where checkIsBuiltAndTag
is called, with some additional places to help tracking pose channels,
constraints, and modifiers.

Further improvements in granularity are possible, but that could happen
as a followup development once the core part is proven to work.

An example of such improvement would be to have entries in the trace
which will indicate NLA and drivers building. Currently it might be
a bit confusing to see IDs in the trace referenced from driver.

Even with such limitation the current state of the patch brings a
very valuable information (some information is much better than no
information at all).

Diff Detail

Repository
rB Blender

Event Timeline

Sergey Sharybin (sergey) requested review of this revision.May 24 2022, 11:51 AM
Sergey Sharybin (sergey) created this revision.

Tested, it just works! 10/10.

Some context on why this is great:
Before this patch, when deleting a bone while rigging, if that bone was referenced by another constraint, there would be a warning telling you that something is referencing something that doesn't exist anymore, but it didn't tell you where the actual problem was within the file. And that would be super frustrating! But not anymore! :)

Sybren A. Stüvel (sybren) requested changes to this revision.May 24 2022, 12:36 PM

LGTM, just some minor notes. And one question: why this order of the stack trace? Does it make more sense than the opposite? In this example:

Failed to add relation "Copy Location"
Could not find op_from: OperationKey(type: BONE, component name: 'Bone.001', operation code: BONE_DONE)

Backtrace:
               Object : Armature.001
         Pose Channel : Bone
           Constraint : Copy Location

it basically mentions the "to" and then the "from", but the backtrace is listed from "from" to "to", so in the opposite order of the earlier messages.

source/blender/depsgraph/intern/builder/deg_builder_stack.cc
3

Why is your code so old? So old!?!

23

typo

source/blender/depsgraph/intern/builder/deg_builder_stack.h
3

year!

21

Might be nice to have a docstring.

52

Also needs a docstring, no idea what a "scoped entry" is.

78

typo

This revision now requires changes to proceed.May 24 2022, 12:36 PM

Fixed typos and added docstrings.

And one question: why this order of the stack trace?

Why not? :)
Starts from the top-level (typically ID). In the example the builder first went to Armature.001, then to Bone, then to a Copy Location constraint. The order would match the way how one would navigate to the offending entity in the outliner.

it basically mentions the "to" and then the "from"

It? The trace does mention neither "to" nor "from", it mentions "what": <type> : <name>.

Can adjust it to something like solving any possible ambiguity:

Trace:

Depth    Type                  Name
-----    ----                  ----
1        Object                Armature.001
2        Pose Channel          Bone
3        Constraint            Copy Location
source/blender/depsgraph/intern/builder/deg_builder_stack.cc
3

Yeah, was waiting for a perfect moment to publish it, duuh :)

Use more clear output format:

Trace:

Depth    Type                     Name
-----    ----                     ----
1        Object                   Armature.001
2        Pose Channel             Bone
3        Constraint               Copy Location

And one question: why this order of the stack trace?

Why not? :)
Starts from the top-level (typically ID). In the example the builder first went to Armature.001, then to Bone, then to a Copy Location constraint.

To me that's implementation details.

The order would match the way how one would navigate to the offending entity in the outliner.

This is Da Best Reason™.

This revision is now accepted and ready to land.May 24 2022, 2:28 PM