[Bf-committers] GSoC 2016 Preliminary proposal to optimize the memory usage of mesh undo

[Joe Eagar]

Editmode undo is different than global undo, remember.

This, people, is an awesome idea.  I've used Blender's tool operator
in three major projects (one of which is commercial) and I made
exactly this modification.  Why should the transform tool copy the
whole mesh?  Or the select tool?  It's not necessary. Here's the
source code for my design:

https://github.com/joeedh/fairmotion/blob/master/src/core/toolops_api.js

Here's one of the comments in that file:
/*
basic design of tool ops:
inspired by Blender's tool system. each tool has
a list of parameters, and are also passed a Context struct (a sort of
bundle of common tool parameters).
The main difference is that undo is implemented on top of this system.
Tools that do not implement undo callbacks will trigger a complete copy
of the data state. This is to get new tools up and running quickly;
all tools should eventually get their own, faster callbacks (or at least
inherit from super-classes with faster defaults, like SelectOpAbstract).
Note that for some tools, serializing the app state prior to undo is
unavoidable.

RULES:

1. Tools must store all (non-undo) state data in slots.
2. Tools cannot access ANYTHING RELATED TO THE UI within exec.
This is to ensure tool repeatability, and maintain the integrity
of the undostack (which doesn't store things like viewport pans).
3. ToolProperty subclassess MUST NOT STORE REFERENCES (except to basic
types like
strings, ints, etc). Rather, they must store a value to lookup an object:
* DataRef structures for DataBlocks (ASObject/Mesh/Scene/etc)
* integers for Mesh element subtypes (Vertex/Edge/Loops/Face).
*/




On Sat, Mar 5, 2016 at 8:27 PM, Campbell Barton <ideasman42 at gmail.com> wrote:
> On Sat, Mar 5, 2016 at 8:19 PM, Ounan Ding <ounanding at gmail.com> wrote:
>> Hi,
>>
>> I am Ounan Ding(IRC: TheBusyTypist).
>> I am interested in Blender and willing to contribute to our community in
>> the coming GSoC 2016.
>>
>> Here is my preliminary proposal to optimize the memory usage of mesh undo:
>>
>>
>> https://github.com/thebusytypist/gsoc-2016-doc/raw/master/proposals/mesh-undo-memory/mesh-undo-memory.pdf
>
> Checked over the document, one thing which isn't quite correct is the
> statement that...
>
>   "The current strategy is that the whole mesh data get duplicated and restored
> on the undo command"
>
> ... in fact each chunk of memory is compared and only stored if there
> are differences,
> though this is inefficient when making destructive changes to the mesh
> (subdivision for example),
> it does mean changing selection won't have to store  UV's, weights,
> shape-keys etc.
>
> One possible optimization would be to implement binary diffing, so
> minor differences to large allocates don't have to store the entire
> block each time.
>
>> (and I put it on wiki.blender.org as well:
>> http://wiki.blender.org/index.php/User:TheBusyTypist/GSoC2016-Mesh-Undo-Memory
>> But I suggest to read above pdf version since it has better typesetting)
>>
>> I have a review of current implementation here:
>> http://blender.linearconstraints.net/2016/02/28/notes-on-undo.html
>> It helps me form this proposal.
>>
>> I also have some notes and practice on the Blender Operator system:
>> http://blender.linearconstraints.net/2015/03/28/write-first-blender-operator.html
>> http://blender.linearconstraints.net/2015/04/01/analyze-primitive-cube-add-operator.html
>> which lead me to the design in my proposal.
>>
>> Currently I am still working on more strategies for specific Operators.
>> I am also looking forward to commends and critiques from you.
>>
>> Thank you.
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>
>
>
> --
> - Campbell
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers