Re: [Bf-committers] GSoC 2016 Preliminary proposal to optimize the memory usage of mesh undo
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 wrote: > On Sat, Mar 5, 2016 at 8:19 PM, Ounan Ding 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@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers > > > > -- > - Campbell > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GSoC 2016 Preliminary proposal to optimize the memory usage of mesh undo
On Sun, Mar 6, 2016 at 4:53 PM, Ounan Ding wrote: > 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. No, your right, was thinking of global undo but re-read the code here and it does store entire mesh for each undo step. > 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 > wrote: > >> On Sat, Mar 5, 2016 at 8:19 PM, Ounan Ding 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@blender.org >> > http://lists.blender.org/mailman/listinfo/bf-committers >> >> >> >> -- >> - Campbell >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GSoC 2016 Preliminary proposal to optimize the memory usage of mesh undo
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 wrote: > On Sat, Mar 5, 2016 at 8:19 PM, Ounan Ding 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@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > > > > -- > - Campbell > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GSoC 2016 Preliminary proposal to optimize the memory usage of mesh undo
On Sat, Mar 5, 2016 at 8:19 PM, Ounan Ding 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@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GSoC 2016 Preliminary proposal to optimize the memory usage of mesh undo
Hi Ounan, That's been a lot of work, thanks for showing your commitment! I only had time to check it quickly. The Mesh team will go over it as soon as possible. A quick remark about undo optimize: it will be interesting to examine alternative ways too. like partial undo storage and compressing. But I admit I haven't checked this code for a while, who knows it's already there! -Ton- Ton Roosendaal - t...@blender.org - www.blender.org Chairman Blender Foundation - Producer Blender Institute Entrepotdok 57A - 1018AD Amsterdam - The Netherlands > On 5 Mar, 2016, at 10:19, Ounan Ding 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 > > (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@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] GSoC 2016 Preliminary proposal to optimize the memory usage of mesh undo
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 (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@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
