[Bf-committers] > Undo system design

Ton Roosendaal ton at blender.org
Wed Nov 17 22:36:52 CET 2004


Hi,

Sorry for the hijacked thread. Hopefully this one goes better now.

For each editmode undo step, the full dataset is still copied. That's  
simple and fast, but will give potential memory problems on larger  
meshes or images when you make such stacks entirely local for objects.
Editmode in Blender also is temporal data, converted for maximum  
editing speed. Whilst the Blender database (and files) are supposed to  
be as compact as possible. And lastly, editmode data was not supposed  
to be quick for saving in files...

Doing separate stacks for vertex painting - for example - would also be  
impossible to maintain when (amount of) vertices change during  
modeling...

So there's quite some issues if you want to make it fully non-linear. :)

It *is* interesting though, and the current editmode undo is sort-of  
non linear now. What I could do - for example - is make sure there's  
some tags in the global undo system that makes sure global undo  
stepping also matches editmode undo state. Like for this case;

1- Add cube, model it into a plane. exit edit mode
2- move it a bit around
3- enter editmode, make the plane an ufo. exit editmode

Now if you 'global undo' back to step 2) the editmode undo stack also  
should rewind... if that's possible, since that stack of course can be  
full.

-Ton-



On 17 Nov, 2004, at 21:43, Goran Kocov wrote:

> Well maybe "unified undo stack" or "unified linear
> undo system" would have been better terms, since a
> stack is always linear :), but what I ment was an undo
> system of the type that's most commonly used in
> today's applications - one stack into which all (or
> nearly all) changes in the application state are
> pushed for later retrieval in case the user needs to
> go one or several steps back.
>
> Now, a "non-linear undo system" would have separate
> stacks for different elements of the application
> leading to a better flexibility with the cost of a bit
> more complicated workflow (i.e. the user has to be
> aware when he/she is using which undo stack). Elements
> in which complex or sensitive datasets are handled (by
> sensitive I mean data in which problems can be
> generaly hard to spot) would benefit the most from
> local undo stacks since they are most susceptible to
> hard-to-correct problems.
>
> In the case of Blender, one possible implementation
> would be:
> - one global undo stack per scene (3D Object Mode and
> all other modes/editors that are not mentioned for the
> local stacks);
> - one local stack per object for local object/geometry
> changes of meshes, curves, surfaces, metas, lattices
> and armatures (3D Edit Mode, Weight Paint, Vertex
> Paint, Pose Mode);
> - one local stack for UV mapping (per mesh object) and
> texture painting (UV Face Select, UV/Image Editor,
> Texture Paint (maybe the texture painting part should
> be transfered to the global stack, since it's not
> directly related to an object));
> - one stack (per object if it's object data that's
> handled) for animation (IPO Editor, Action Editor, NLA
> Editor (although the NLA would be tricky, since it
> functions globaly));
> - one local stack for each script in the text editor;
> - one local stack for the sequence editor;
>
> I'm aware that there are a lot of
> problems/inconsistencies to solve (especially where
> editors with different undo stacks can operate on the
> same dataset), but this is still heavily WIP and I
> think that with some effort the non-linear undo system
> can lead to a very effective undo solution.
>
> Please, have in mind that I haven't spent a lot of
> time/energy in coming up with this proposal, so some
> parts are probably confusing and/or inconsistent.
>
> Thanks,
> Goran
>
> P.S. Guys, please don't take over my thread or at
> least change the subject name.
>
> --- Ton Roosendaal <ton at blender.org> wrote:
>
>> Hi,
>>
>> No, this is the proper maillist for such
>> discussions. :)
>>
>> I've never really investigated what 'proper' undo
>> architectures are, so
>> your remarks on 'unified linear undo stack' I don't
>> really get... what
>> would 'non-linear' undo be?
>>
>> My remark in the release notes on the current undo
>> issues are more from
>> a user perspective, with multiple different undo
>> systems being in use
>> now (editmode undo versus global undo). This can
>> lead to confusement,
>> and it is worth trying to unify I think.
>>
>> The current undo system does indeed include more
>> features we can add
>> for a next release yes. The full undo stack can just
>> be written in
>> files. Or even better, I thought of dumping the
>> entire undo stack
>> including current project on exit, and just have it
>> read back on
>> restart of Blender. Would be a very interesting
>> experiment, and
>> certainly be extremely cool to show off. :)
>>
>> Whether Blender has a 'farsighted design' opinons
>> can differ though,
>> I'm usually quite humble about that. But for
>> presentation/marketing of
>> our project it wouldn't hurt to emphasise some more
>> of the good things
>> in Blender, so a text as you wrote below should be
>> at least quoted on
>> our blender3d.org website!
>>
>> -Ton-
>>
>>
>> On 17 Nov, 2004, at 13:09, Goran Kocov wrote:
>>
>>> Hi!
>>>
>>> While browsing through the 2.35 changes documents
>>> yesterday, I noticed that the undo system design
>> is
>>> still not completly resolved and that there's a
>>> possibility of switching to a unified linear undo
>>> stack.
>>>
>>> Since in many design decisions, Blender has proven
>> to
>>> be years ahead compared to other 3D apps (excelent
>>> example is the UI with the non-overlaping windows,
>> the
>>> widgetless transforms, etc. resulting in a nearly
>>> unsurpassed workflow), I see the flexible and
>> elegant
>>> solution of a non-linear undo system (which is, in
>> a
>>> large part, already implemented) as a possibility
>> once
>>> again to show the 3D world the farsightedness of
>>> Blender's design.
>>>
>>> I'm not very familiar with Blender's architecture,
>> so
>>> I can't tell the possible technical pitfalls of
>> this
>>> approach, but IMO, from a design point-of-view,
>> going
>>> to a unified undo system would be a *bad*
>> decision.
>>>
>>> Another very useful undo related feature would be
>> the
>>> capability to save the undo stacks in the blend
>>> project file, thus enabling the user to undo
>> changes
>>> even after the project has been closed and then
>>> reloaded. Once again, I don't know if this is
>> possible
>>> and/or practical with the current architecture (I
>>> suppose the size of the project file would rise
>>> exponentially with the undo stacks included, but I
>>> can't see any other problems at the moment).
>>>
>>> Goran
>>>
>>> P.S. If the right place for this post is in the
>>> functionality board mailing list, please tell me
>> and
>>> I'll move the thread there.
>>>
>>>
>>>
>>> 		
>>> __________________________________
>>> Do you Yahoo!?
>>> Meet the all-new My Yahoo! - Try it today!
>>> http://my.yahoo.com
>>>
>>>
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at projects.blender.org
>>>
>>
> http://projects.blender.org/mailman/listinfo/bf-committers
>>>
>>>
>>
> ----------------------------------------------------------------------- 
> -
>>
>> --
>> Ton Roosendaal  Blender Foundation ton at blender.org
>> http://www.blender.org
>>
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at projects.blender.org
>>
> http://projects.blender.org/mailman/listinfo/bf-committers
>>
>
>
>
> 		
> __________________________________
> Do you Yahoo!?
> The all-new My Yahoo! - Get yours free!
> http://my.yahoo.com
>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
>
>
------------------------------------------------------------------------ 
--
Ton Roosendaal  Blender Foundation ton at blender.org  
http://www.blender.org



More information about the Bf-committers mailing list