Terrain Editing
Posted: 12 May 2017, 14:56
Developers are starting to get unruly about doing post 1.0 stuff, which is long overdue anyway. I am wondering if we are able to do some kind of push that maybe not get us completely there but at least a good part of the way.
OpenMW is more or less finished minus shadows and bug fixes. Little we can do about speeding that up.
OpenMW-CS is still missing a lot more functionality. But the only big thing missing is terrain editing. This is a gigantic task and unless some experienced developer with a lot of spare time comes along it will likely stay untouched.
But we did get a fair amount of new developer activity recently. Maybe if I chop up the task into smaller, better digestible pieces, could we find volunteers to work on them?
Here is a summary of the feature:
The 3D view has an edit mode button that can be used to switch between different editing modes. Currently implemented are instance editing and waypoint editing. Still missing are the implementation for terrain shape editing, terrain texture editing, terrain vertex paint editing and terrain movement.
Here are the issues that need to be tackled:
1. Transient changes: For example if we deform a piece of terrain via a drag operation these changes are not translated into changed content data directly. That only happens when the user releases the mouse button and the drag ends.
Unfortunately our terrain component does not support this function and there is no way around that. Bypassing the command interface by making direct changes to the terrain data during the drag would break things horribly.
There are two possible solutions:
a) Work with a copy of the terrain data. Not very memory efficient, but it should get the job done.
b) Implement some kind of layer between the terrain data and the terrain renderer that inserts the transient changes without actually touching the terrain data.
2. Selection: We need the ability to select terrain. Probably different mechanisms for textures, vertices and vertex paint. These selections need to be stored and rendered. Maybe this will also require some modifications to the existing selection implementation (but not the UI) which works entirely on instances.
3. Like the instance editing mode the terrain modes also will have sub modes. These need to be implemented one by one (several developers doing that concurrently would be feasible).
I suggest to start with texture editing. This is the easiest task and only requires #2. Of course if someone want to be daring he could take on #1 at the same time. Everything below this paragraph is exclusively related to this particular editing mode.
The texture mode is relative simple and does not require a sub-mode. But it needs a brush button, that is used to control texture and shape.
I imagine the texture editing functions like this:
1. When the user drops a texture on a terrain tile that is not selected the texture is applied to that tile.
2. When a part of the terrain is selected and the user drops a texture on it the texture is applied to the selected terrain tiles.
3. When an unselected piece of terrain is clicked with the primary edit button the texture from the brush button is applied to an area of the terrain specified by the current brush.
4. When a selected piece of terrain is clicked with the primary edit button the texture from the brush button is applied to all selected terrain tiles.
5. When the user clicks a piece of terrain with the secondary edit button the brush button is set to use the texture on this terrain tile.
6. The user can copy the selected part of the terrain as usual.
7. Pasting works in two ways: a) by pressing ctrl-v while hovering the mouse over the insert point, b) via the brush button (see below)
Selection-Button:
When clicking the selection button a small window should pop up that allows to configure the selection brush:
- single point (no size)
- square (size is length of an edge)
- circle (size is diameter)
- custom (makes the shape and size of the current selection into a brush)
The selection button should also have a context menu with a list of recently used brushes (size of list configurable via user settings).
A fancy implementation may display hints about the currently selected selection brush in the selection button icon (but that is optional).
Brush-Button:
When the user drops a texture on the brush button the texture is selected. The brush button should also have a context menu with a list of recently used textures (size of list configurable via user settings).
When clicking the brush button a small window should pop up that allows to configure the brush:
- single point (no size)
- square (size is length of an edge)
- circle (size is diameter)
- custom (makes the shape and size of the current selection into a brush)
- paste (only available while there is copied terrain in the clipboard)
Note that this window and the one of the selection button are almost identical. A shared implementation would be a good idea.
A fancy implementation may display hints about the currently selected brush in the brush button icon (but that is optional).
A final word about selection and brushes: As you have probably noticed there is a lot of duplication between these two. This is unavoidable IMO. We need a fully features selection mechanism for moving terrain (textures) around. But forcing the user to do texture editing by selecting the terrain first and then change the selection would be a very bad usability move. Therefore we also need a fully featured brush for direct editing.
So, does this sound interesting to anyone or am I talking into the void? If there is any interest I will chop up this wall of text into individual issues and add them to the tracker (will probably take me a few days).
OpenMW is more or less finished minus shadows and bug fixes. Little we can do about speeding that up.
OpenMW-CS is still missing a lot more functionality. But the only big thing missing is terrain editing. This is a gigantic task and unless some experienced developer with a lot of spare time comes along it will likely stay untouched.
But we did get a fair amount of new developer activity recently. Maybe if I chop up the task into smaller, better digestible pieces, could we find volunteers to work on them?
Here is a summary of the feature:
The 3D view has an edit mode button that can be used to switch between different editing modes. Currently implemented are instance editing and waypoint editing. Still missing are the implementation for terrain shape editing, terrain texture editing, terrain vertex paint editing and terrain movement.
Here are the issues that need to be tackled:
1. Transient changes: For example if we deform a piece of terrain via a drag operation these changes are not translated into changed content data directly. That only happens when the user releases the mouse button and the drag ends.
Unfortunately our terrain component does not support this function and there is no way around that. Bypassing the command interface by making direct changes to the terrain data during the drag would break things horribly.
There are two possible solutions:
a) Work with a copy of the terrain data. Not very memory efficient, but it should get the job done.
b) Implement some kind of layer between the terrain data and the terrain renderer that inserts the transient changes without actually touching the terrain data.
2. Selection: We need the ability to select terrain. Probably different mechanisms for textures, vertices and vertex paint. These selections need to be stored and rendered. Maybe this will also require some modifications to the existing selection implementation (but not the UI) which works entirely on instances.
3. Like the instance editing mode the terrain modes also will have sub modes. These need to be implemented one by one (several developers doing that concurrently would be feasible).
I suggest to start with texture editing. This is the easiest task and only requires #2. Of course if someone want to be daring he could take on #1 at the same time. Everything below this paragraph is exclusively related to this particular editing mode.
The texture mode is relative simple and does not require a sub-mode. But it needs a brush button, that is used to control texture and shape.
I imagine the texture editing functions like this:
1. When the user drops a texture on a terrain tile that is not selected the texture is applied to that tile.
2. When a part of the terrain is selected and the user drops a texture on it the texture is applied to the selected terrain tiles.
3. When an unselected piece of terrain is clicked with the primary edit button the texture from the brush button is applied to an area of the terrain specified by the current brush.
4. When a selected piece of terrain is clicked with the primary edit button the texture from the brush button is applied to all selected terrain tiles.
5. When the user clicks a piece of terrain with the secondary edit button the brush button is set to use the texture on this terrain tile.
6. The user can copy the selected part of the terrain as usual.
7. Pasting works in two ways: a) by pressing ctrl-v while hovering the mouse over the insert point, b) via the brush button (see below)
Selection-Button:
When clicking the selection button a small window should pop up that allows to configure the selection brush:
- single point (no size)
- square (size is length of an edge)
- circle (size is diameter)
- custom (makes the shape and size of the current selection into a brush)
The selection button should also have a context menu with a list of recently used brushes (size of list configurable via user settings).
A fancy implementation may display hints about the currently selected selection brush in the selection button icon (but that is optional).
Brush-Button:
When the user drops a texture on the brush button the texture is selected. The brush button should also have a context menu with a list of recently used textures (size of list configurable via user settings).
When clicking the brush button a small window should pop up that allows to configure the brush:
- single point (no size)
- square (size is length of an edge)
- circle (size is diameter)
- custom (makes the shape and size of the current selection into a brush)
- paste (only available while there is copied terrain in the clipboard)
Note that this window and the one of the selection button are almost identical. A shared implementation would be a good idea.
A fancy implementation may display hints about the currently selected brush in the brush button icon (but that is optional).
A final word about selection and brushes: As you have probably noticed there is a lot of duplication between these two. This is unavoidable IMO. We need a fully features selection mechanism for moving terrain (textures) around. But forcing the user to do texture editing by selecting the terrain first and then change the selection would be a very bad usability move. Therefore we also need a fully featured brush for direct editing.
So, does this sound interesting to anyone or am I talking into the void? If there is any interest I will chop up this wall of text into individual issues and add them to the tracker (will probably take me a few days).