Manipulator: Use evaluated object's matrix to get maipulator position
ClosedPublic
Actions

Authored by Sergey Sharybin (sergey) on Feb 2 2018, 5:59 PM.

Details

Reviewers

Brecht Van Lommel (brecht)
Bastien Montagne (mont29)
Campbell Barton (campbellbarton)
Dalai Felinto (dfelinto)

Commits

rBS40199c1d10a9: Manipulator: Use evaluated object's matrix to get maipulator position
rB40199c1d10a9: Manipulator: Use evaluated object's matrix to get maipulator position

Summary

With the clear separation between data and a state we need to make sure
operators and other areas are readingstate from evaluated datablocks.

Code-wise it means that all evaluated values are to be read from dataglock
which is owned by dependency graph, using DEG_get_evaluated_id() or similar
helper.

While this commit fixes manipulator, it doesn't make me fully hapopy:

How do we prevent accidents from happening?
How can we avoid madness of going over everything to see what's happening?
What should datablocks from context point to (as in, is active object from context points to original datablock or to it's evaluated version within a given context?

Diff Detail

Repository: rB Blender

Event Timeline

Sergey Sharybin (sergey) created this revision.Feb 2 2018, 5:59 PM

Another option here: always keep context and bmain and everything passed to operators and drawing to hold evaluated objects. So they will both read and write from/to evaluated versions of datablocks. And then make dependency graph to copy stuff from evaluated version back to original one when flushing tags.

Just an idea. Think we should have some sort of brainstorm?

Another option here: always keep context and bmain and everything passed to operators and drawing to hold evaluated objects. So they will both read and write from/to evaluated versions of datablocks. And then make dependency graph to copy stuff from evaluated version back to original one when flushing tags.

Imagine doing this for a mesh with modifiers, there would be no way to map the edited mesh topology from the evaluated mesh to the original. What the user edits is the original mesh, and in some cases we allow editing of the evaluated transform or vertex coordinates for convenience. I don't think we should try to do that automatically for operators, it's convenient in some cases but just doesn't work for datablocks in general I think.

I don't have great answers, but I think:

Context should return original datablocks, and operators that need it should be able to access the evaluated datablocks. To avoid accidents we could require getting the evaluated matrix through some helper function, but this is not foolproof.
Drawing should work with evaluated objects, and sometimes look at the original object when drawing editing related data.
Manipulators are part of the transform operators, so just like those I think they should loop over selected original datablocks and manually retrieve the evaluated datablocks from those.
Not sure what you mean by madness of going over everything, but for performance I think ideally the manipulator system should be able to listen to the depsgraph or notifiers for when selection changes, and only update cached manipulator data then.

@Brecht Van Lommel (brecht), by madness i meant that with the original proposal you'll have to go over all operators, and make sure evaluated stuff is read from evaluated version of datablocks. Surely, that's doable, but there might be some better/easier/more foolproof approach.