Introducing the new ETL demo

CABAListic

05-10-2008 21:58:40

Finally done with my Bachelor Thesis, so I'm back on track with ETL now (or so I hope :) ). I've begun work on the new ETL demo which will replace the hacked up demo from previous versions. It's going to be a more or less full-featured terrain editor, but with focus on showing ETL features, not on usability. The beginnings of my work are visible in this screenshot:



There's a lot of work ahead still, but it's coming along nicely. I'll keep you posted on my progress. Oh, and don't worry, I'll eventually replace that ugly standard CEGUI theme with something custom-made, I already asked jjp to do some more artwork for me :)

SongOfTheWeave

06-10-2008 05:53:42

woot!

Nauk

06-10-2008 21:07:53

Good news & congratulations on the finished thesis, I am looking forward to ETL and the yummy new features since quite a while, godspeed for the coding :)

CABAListic

06-10-2008 21:49:56

A few more words on what I have in plan for the demo. The focus is obviously on showcasing the editing features of ETL. There will be some basic support and saving and loading terrain, but this will be really only as much as is necessary to get it working. Basically you will enter a name for the terrain to be saved to or loaded from, and the editor will create a subdirectory in a hardcoded folder and store heightmap and splatting maps there. There won't be any filebrowser or anything, just bare-bones save and load.

As for the edit part, one focus will be showcasing the new brushes. The editor shows a selection of images contained in the resource group "brushes" which can be selected as brush. The brush's size can be scaled and even rotated, all without modifying the actual image. This is thanks to the new brush handling which uses interpolation to match the fixed grids of terrain and brush without actually having to align them. This is already working more or less, but I will revise the brushes to make their internal handling even better.
There will be three primary edit actions you can do on the terrain: You can deform the terrain, you can splat textures and you can colour-paint the terrain. The first two are nothing new, but the latter allows you to choose an arbitrary RGB colour and paint it onto the terrain. This makes use of the new DynamicTexture class. For the texture splatting you can choose from all the textures found in the special resource group 'textures'. The new SplattingManager will automatically assign used textures to channels as you go. Unfortunately, this is the major area in ETL that doesn't exist yet. In a first step I need a SplattingMaterial manager so that the dynamic mapping of the SplattingManager can even be mapped to the material. For that matter, I will offer a helper class in ETL which will create a splatting material from a given base material by adding the splatting passes to that material. That way, you still have full control over any following passes for lighting and other stuff.

Finally, I want to give the editor and the ETL library basic undo/redo support. This is a part which I might skip if I hit time constraints again, but I really think that feature would be awesome. The way I envision to do it is to have a history manager for which you can create edit proxies for your various editable components. For example you could create an edit proxy for your terrain. Now, instead of editing (deforming) the terrain directly, you would do it with the proxy. The proxy redirects the editing, but remembers and updates an internal dirty rectangle. Then, when you are finished with an edit step (i. e. if the user releases the mouse), you would tell the proxy that you are finished. The proxy now saves the new state of your proxied object by copying the dirty area into a buffer which is stored on the history manager. The history manager can now differentially restore any of your proxied objects to previous states.
The challenge in the history manager is that the editable components of ETL all store different data, so I need to come up with a way to create the proxies with as little code repetition as possible. This will probably involve some template magic, but it will be totally hidden from you :)

Nauk

07-10-2008 16:32:42

topic undo / redo
You might want to consider what I have been doing for Artifex, actually a quite simple solution: After each action, mainly upon key release or mouse up I just save the entire image (either heighmap, coverage or colormap) to an Array along with the type of action. Sounds like an overkill at first but runs actually quite performant and does not really notably slow down the application and the image sizes are rather small compared to the amount of memory you have nowadays, talking 1-2 MB here per undo step.

kungfoomasta

07-10-2008 16:49:31

CABAListic, this is great news! The undo/redo definately sounds like a pain to implement. I noticed you haven't mentioned anything about smoothing or flattening areas, have you thought about this? The ability to set absolute heights would be useful also, for example imitating a warcraft 3 or other RTS map with ETL. :wink:

CABAListic

07-10-2008 17:33:35

topic undo / redo
You might want to consider what I have been doing for Artifex, actually a quite simple solution: After each action, mainly upon key release or mouse up I just save the entire image (either heighmap, coverage or colormap) to an Array along with the type of action. Sounds like an overkill at first but runs actually quite performant and does not really notably slow down the application and the image sizes are rather small compared to the amount of memory you have nowadays, talking 1-2 MB here per undo step.


Sure, that's basically what I'm going to do, except that I plan to limit the copies to the actual dirty rects, so that I save some bytes for each iteration. But that's not really much of a problem. The key problem is that I want to have a ready-working solution for any library user to integrate, and that means I don't know about which objects I need to copy. So the key part is for the user to be able to specify those objects in a coherent way.

I'm currently thinking of a transaction-based approach. What I could imagine (just thoughts-play, no actual implementation yet) is something like this:

// setup
ET::TransactionManager transactions;

// register an object for versioning
transactions.monitor(myTerrain);

// now do some modifications to the terrain, then commit the changes
transactions.commit(myTerrain);


Basically, what the monitor call would do is copy the contents of the entire object as the initial version. Then each commit checks which parts of the object have changed since last time (obviously need a Listener structure here from the objects to the TransactionManager) and copy the smallest rectangular area possible. This is stored as one edit step. Reversing an edit step is then simply a matter of restoring that particular rectangle to the previous state. The latter has some pitfalls because I do not store the entire object each time, but it's still pretty straight-forward to do.
The actual problem is that the objects you might register are of different type and store different types internally. So monitor and commit must both do some magic behind the door to solve that behind the doors. Most certainly any versionable object will inherit from a common base class. Now the base class could offer the ways of saving data from the object by returning another base object pointer which is specialised for each versionable object. But I sense an opportunity for template magic here and will investigate that opportunity :)

CABAListic, this is great news! The undo/redo definately sounds like a pain to implement. I noticed you haven't mentioned anything about smoothing or flattening areas, have you thought about this? The ability to set absolute heights would be useful also, for example imitating a warcraft 3 or other RTS map with ETL. ;)
You have full access to the heightmap of the Terrain object, so you can basically set the heights in any way you like, you don't even need to go through a Brush object to do this. Any height value you modify will be marked as dirty, and the next update call on the Terrain object will reflect your changes to the visual representation (if any). But I won't offer any functionality in ETL to do flattening or smoothing, as you can do it the way you want via this way of access. The editor may offer smoothing ability (it's in the selection in the screenshot) if I get to it, though, so it would show an example of doing it.