It's not as easy as it sounds though. Assume that your data structure is a tree, and you modify a node. If you modify a node, you basically add a new view to that data structure that sees all the other nodes, plus the new (modified) copy instead of the old node before it was modified. So what you really have is a new view onto the structure of the tree. To implement this, you also need to copy the parent of the modified node so that the new node can replace the old node in the children of the (new) parent node. And so on until you reach the root node.

So what's really happening is that you keep making new views on part of the structural information in your data structure. For trees, this might be easy to track. For graphs, it sounds like a nightmare and I'll wager that quite often you'll run into situations where you change one node, but have to copy a lot of structural information.

There's another problem though. Let's assume you have mastered this problem and you have a nice data structure that internally handles all this very well. What about references to nodes from the outside? Let's say your editor keeps a list of selected nodes and one of these nodes is changed and thereby copied. You have to update the node reference in the list of selected nodes too because now it points to the old version of the node. Okay, so maybe you can manage this too. But then you realize that keeping references to nodes is kinda handy (and also kinda the point of OO design), and so you are kind of designing against the core features of your language of choice (given that it is an OO language).

Anyways - I suppose that it is possible to write a data structure this way, and if you avoid references from the outside into the data structure, then this approach will work. But I don't think it's better than using the command pattern for undo. In fact, since it forbids a key feature of OO, I think it's quite a bit worse.

Or maybe I'm missing some things? 

 

Haskell mostly works with immutable data structures conceptually. Some of those have an operation to "refresh" the data, e.g. to chop off data that's not referenced from a view anymore.
This system is very awesome in practice, but it comes at a cost: They had to put a lot of brain into bookkeeping it all properly behind the scenes. If you just store updates upon updates all the time, there ultimately comes a point where you must start consolidating the data at the bottom. I think that's difficult.

Lunaran: You are talking about the tools the editor offers. I am talking about the functions used to create those tools. If I give the plugin programmer the ability to determine when a new undo step starts, what I said is a consequence. In practice, my tools will behave as expected: A deletion will be undoable, and I will look into making a plugin to support table-flipping so the editor is even more useful. :3 

Data types and implementation is important but maybe the way a tool shapes and interacts with the user should be the most important question?

Is undo/redo of every operation beneficial or does it slow down the creative process to have a huge amount of discrete steps that can optionally be back-tracked or not? Of course it's easier for the developer to just implement the standard features instead of pondering the philosophical implications of every feature.

Sometimes you do want to be able to flip back and forth between your latest action(s), sometimes deliberate snapshots(or commits � la git) might be better and sometimes it could be best to just move forward and never look back! 

Even if a plugin does create a brush and deletes it all within the same transaction, is that really a problem? That sounds like something you could live with, and if it does become a problem, it should be easily fixable. Since the only operation you allow on your tree is adding and removing nodes, it should be easy to identify such sequences.

One problem that you might have to prepare for is that there may be nested transactions. It will happen if you allow operations to be composed of other operations that might also be used in isolation. It's easy to solve though, the simplest solution is just to track the number of active transactions, and ignore the start / end of any nested transaction altogether. 

bear - Good undo/redo support that's well thought out is pretty important for the user.

Jackhammer, for example, doesn't do undo/redo of selections. That's really a pain when you're selecting a bunch of stuff, make a slip, and by habit try to undo it. Well, none of your selections change BUT the last edit you did before you started selecting things goes away.

That way lies madness... 

Undoing selection and other, similar actions that don't modify the map is a bit counter intuitive at first, because well, it doesn't modify the map! Also, other programs such as a word processor don't undo selection either. But in those programs, selection is a simple operation, whereas in a 3D tool, selection is not so simple. Sometimes you have to click a lot of times to select a number of objects, or you have to move the camera around a bit to select everything you wanted. So it can be a costly operation in terms of user effort, and that's why I think that it has to be undoable.

On top of that, I find it coherent that modifications only happen to selected things in all situations. In TB, the rule is that nothing changes unless it is selected. This is not only beneficial for optimizing the renderer (you only need to take care of updating the selected things in the renderer), but it also gives a simple, consistent rule for the user. 

@SleepwalkR: Creating and deleting a brush in the same transaction is not necessarily a problem, it's just a thing I have to consider. You know, when I sit there and sketch out all the implications of all the things that can happen. :)
Nested transactions... that sounds scary. I don't have that yet, but your heads up on that is quite correct.

@WarrenM: I don't plan on making selections undoable at the moment. 

I don't know how you sleep at night. 

 

You should reconsider that for the reasons outlined above. And as I said, it's easy to detect and dismiss nested transactions. Only the topmost transaction must be undoable anyway. 

bear - Good undo/redo support that's well thought out is pretty important for the user.

Yes, but what is good undo/redo support? And what other meaningful ways of navigating the command/action history of a document could there be? It's all application specific work flow design, you mentioned you want undo/redo of selection actions.

What about giving the user the ability to define important moments in history and have "Undo up to latest historic event"? What about branching document history? Or should that just be handled by source control since it's starting to sound a lot like it.

For a brushed based level editor it seems to me it would be useful to have both fine grained and coarser ways of going back and forth the building process.

Still I think Undo can sometimes be harmful since you always get the choice to take back your action and question your every move. 

Bob Ross didn't need an undo. Happy little brushes! 

"Still I think Undo can sometimes be harmful since you always get the choice to take back your action and question your every move."

The hell? 

i would even say there should be a separate undo stack for the camera................. at least when moved from mouse interactions as it wouldn't make sense for fly mode.

many times while orbiting, i've accidentally clicked a point miles away and sent my view careening off into the grey void of despair. 

that's a TB complaint, btw. I haven't tried microbrush. sorry, i really need to pay more attention when i post. :P 

Good news! My first experiments are going well so far. It is very fiddly code under the hood, but I think this will succeed.
:) 

I have my son's PC next to me in our home office running Windows 10 with an older Nvidia video card. I have found if I run the initial, "First start and tasty fresh cookies!.bat" on his PC and then copy the folder back over to my Linux desktop also running an Nvidia card Microbrush 3 does indeed run under my default wine-1.7.55.

Not ideal if you don't have access to a windows PC, but it seems to work OK. I'm not familiar enough with the program to say how it normally works, but it seems to operate the same in wine as it does in windows 10. 

That sounds rather good!

Now I'm interested in a few more details: Does this .bat file not work in WINE? It compiles the editor plugins and models using a Microsoft.Net application and also displays instructions. The file loading and saving from the editor uses such a .Net application, too.

Maybe these insights could also help Shamblernaut...

I certainly welcome your experience because not only does it tell me that this works on Windows 10 (I have really not tested that yet), and using WINE. It's also something I can point at when that question comes up in the future. :) 

I need more time to look into it, but shortly after I made the previous comment I figured out it was dependant on .Net and was successful in compiling the editor plugins, models and configuring via your setup batch file all in one of my WINE prefixes.

Yes WINE does batch files. With WINE installed you can run them from the Linux terminal with, "wine cmd.exe /c FILENAME.bat" for example.

The WINE prefix I used is my Steam game prefix and it has many dependencies installed to run most any game I play so it already had the required stuff. Anyone with enough Linux/WINE knowledge can duplicate this themselves, but I'd be happy come up with a process for duplicating it from a fresh Winetricks/WINE or POL/WINE install when time premits if it helps anyone. 

If you do, I will gladly post that information on or link to it from the project page with due credit. :) 

What is the Minimum .Net requirement?

4.5? 4? 3.5? 2? 

The only dependencies i needed to install in a fresh WINE 32bit prefix to make your program setup and run was corefonts and dotnet4.5. :)

I'm writing it up now. 

I tried to put it here, but this board eats backslashes. Its just as good on your Steam group page. 

Very nice, thank you a lot! :D
I'll integrate that info soon. :)

And more good news: After a lot of crashing and then a lot of fiddling, all of the tools just fully survived an undo test. This feature is quite a delicate addition on top of what was already there, with the potential for really nasty bugs, but so far it seems to work. Let's hope I won't need to reprogram it all based on new findings that I've missed bad behavior. Should be releasable soon.