Hi everyone!
Merry Christmas ;)
Im in need of the wisdom of those on the mailing list :D
My self and my friend Jeremy are currently building an add-on called
crowdrender, we presented it at BC 2016. We’ve always wanted to find a way to
discover when a modal operator is finalised, either through calling its execute
method, or returning {‘CANCELLED’}. The reason being is that we track data from
the user’s blend session and stream it live to other machines so that they can
co-operatively render a single frame or multiple frames.
I asked a question at the blender conference “Developers - ask us anything”
session, Sergey responded to it. Basically we were asking this question I am
asking here. Sergey’s response was “yeah we can look into it”. So I am
officially following up!
The issue we have is in the fact that when a user uses grab, rotate or
translate (or any other similar modal operator). The active_object gets tagged
with its is_updated flag set to True on every iteration or every call to the
bpy.app.handlers.scene_update_post subscribed handlers.
This means we have to handle a large volume of updates to properties of the
active_object such as changes to location, rotation and scale for example.
Though technically we can handle this there is an important problem that we
have no elegant solution to yet (we have a solution, but it involves a lot of
extra processing inside our add-on which could slow down the UI).
Firstly, from an elegance perspective, a modal operator will change the data of
the active object, triggering the is_updated flag to be True even when the user
has not yet finalised their operation and they may even cancel it. All the
while, we’re processing these updates without knowing that the user may just be
adjusting something and haven’t yet committed to make the updates final. If we
could know that the user is using a modal operator, our process could be far
more efficient since it could ignore these updates until the user causes the
operator to be executed.
Secondly, undo is difficult to support in the most efficient way possible since
every update we process is committed on the other machines, meaning that we are
pushing undo levels on these other machines when the user’s machine is not.
Though we have actually successfully tested our code supporting undo in this
way, it requires us to store many more undo levels on the other machines which
we don’t feel very comfortable with since it increases their RAM requirements
and there is no definitive way to determine the number of undo levels necessary
to cover the user constantly moving an object around using grab for example. To
cover the extreme cases here would require us to set a number of undo levels
stupendously high with no guarantee it would always work.
We’ve investigated some methods of discovering when operators are invoked,
however there seems to be no method available through the python api that
advises the user has invoked an operator, at least not to my knowledge. We also
investigated if we could inspect the undo stack somehow since this would give
us a way to determine what changes had been pushed to the undo stack and
therefore what data updates were actually to be processed by our add-on.
However it seems that the undo level remains hidden from the python api. We did
look at bpy.ops.ed.undo_history() operator, however it seems to only displays a
popup containing list of other operators which run the same command with the
items argument set to the appropriate undo level. We couldn’t extract the
actual data or operator behind each of those levels.
So, my request is (sorry for the length of this e-mail :S) please can someone
advise us of a workable method (other than our brute force approach of course!)
for detecting when a user has finalised their operator, allowing us to then
process this update. We can’t just use C.window_manager.operators list either
since if we just used this list as the one true source of edits, we’d miss
edits made through other means like a script, or through the properties panel
in the 3d viewport.
To add weight to our request, we now have 70 people subscribed to our website
and many of those have since contacted us asking for this add-on to be
released, which we are eager to do in an alpha build. In fact we have scheduled
for release in early January. Despite the problem with the undo levels, we are
still happy to release it to a small number of artists who are happy to live
with the restrictions in exchange for early access to the software. This is
hopefully going to provide us with feedback.
In the mean time and as we continue to develop the add-on, we’d very much like
the opportunity to work with the blender developers to find a solution to this
problem since it will allow us to help artists share their computer power over
what ever machines they have access to in real time.
All the best for all on the mailing list for 2017
James and Jeremy from Crowdrender :D :)}
_______________________________________________
Bf-python mailing list
Bf-python@blender.org
https://lists.blender.org/mailman/listinfo/bf-python
