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

[Ounan Ding]

Hi Campbell,

Thank you for your clarification.

I just re-check the code but I am afraid I cannot confirm what you said.

If I understand the code correctly, the actual assembling of UndoElem
happens in undo_editmode_push.
Then it steps in editbtMesh_to_undoMesh through:

curundo->undodata = curundo->from_editmode(editdata, obedit->data);

In the editbtMesh_to_undoMesh, I see verts, edges, loops are duplicated in
the function BM_mesh_bm_to_me.

I failed to find any difference checking code in BM_mesh_bm_to_me.
It just iterates verts, edges, loops and copy the data.
I am also aware of the member elem_index_dirty in BMesh. But I do not see
it is used to avoid unnecessary copying.

Please correct me if I am wrong.

BTW, could you also put some comments on another proposal on Solidify
modifier I wrote a day before?
http://lists.blender.org/pipermail/bf-committers/2016-March/046915.html
It is not hurry. But I really like to collect ideas and make some
improvements before the final proposal submission date.

Thank you.

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
>