Terrain Editing

Involved development of the OpenMW construction set.
Lamoot
Posts: 77
Joined: 22 Apr 2016, 12:03

Re: Terrain Editing

Post by Lamoot » 21 Apr 2018, 10:14

The screenshots look promising!

I agree with Zini on that terrain editing would benefit greatly from design work first. What tools are needed / expected by artists to comfortably work on terrains? Off the top of my head there would need to be these very basic tools:

* Raise / lower
* Smooth / sharpen
* Plateau (based on set height or height of the terrain where the brush started its stroke)

unelsson
Posts: 94
Joined: 17 Mar 2018, 14:57

Re: Terrain Editing

Post by unelsson » 21 Apr 2018, 11:57

Zini wrote:
21 Apr 2018, 09:43
We still don't have a selection mechanism and there is still the elephant in the room, namely the issue of transit changes.
Building complete macros for drag&drop operations (transit changes?) should be implemented now. https://github.com/OpenMW/openmw/pull/1680.

unelsson
Posts: 94
Joined: 17 Mar 2018, 14:57

Re: Terrain Editing

Post by unelsson » 21 Apr 2018, 20:39

Zini wrote:
12 May 2017, 14:56
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.
I went through and got a bit into PlutonicOverkills code on terrain selection. Although the feature itself could be developed further, there are several problems (mostly with the feature itself, not really so much on code). Firstly, brush button settings window and terrain selection are both tied under primarySelectPressed. If selection feature needs to be fitted, maybe add a setting (checkbox? slider with two modes?) to brush window to toggle between select/edit, that is, whether primaryedit selects parts of texture grid or applies texture painting? Another possibility is just to use secondary edit, but that would interfere with the "select clicked texture" feature. Discarding selection should also be possible in some easy way, possibly if newly started selection click doesn't hit any land. What's the actually needed use for selection feature - is it drag&dropping textures to selected area? Moving shapes of textures - if so, what's going to be left under moved terrain? Copy-pasting texture areas ("currently custom selection" in brush settings window)? Is it Ctrl-C copy or some other method of copy?

Second problem with terrain selection is the size of the grid - somewhere it was mentioned that selection feature should work differently whether we are land editing (selecting vertices) or selecting pieces of texture grid. In PlutonicOverkills branch, while the selection seems to work correctly, it's drawn to only corner of the cell (in smaller size instead of texture size). This branch could be developed into different directions - selection could be permanently visible, or it could be visible per-edit-mode. It might remember the selected area after changing editmode, or delete the selection from memory. When changing editmodes, there might be an algorithm that tries to estimate a selection and convert the selection into another mode - this should be fairly accurate when changing from texture grid to vertices, but other way around requires some weird approximation that obviously loses resolution. If multiple selections are visible, they should probably be coded somehow - color mayhaps? On the other hand, having multiple different overlapping selection lines drawn might make the scene look messy.

unelsson
Posts: 94
Joined: 17 Mar 2018, 14:57

Re: Terrain Editing

Post by unelsson » 22 Apr 2018, 10:53

On terrain shape editing I get terrain tearing and terrain stripes when saving, when I edit terrain heights data. When editing in OpenCS, everything looks nice (no tearing, no stripes), but data gets corrupted after saving - terrain is striped and torn when opening terrain in openmw or reloading in opencs. My current editing code leaves the last column and row of land heights data unedited (using it for calculations results in trouble - I understood it's used to connect to next cell?), and it can rise and lower U-shapes from terrain.

Tearing
https://imgur.com/SN8cu7n

Stripes
https://imgur.com/hPKvFzM

User avatar
Zini
Posts: 5503
Joined: 06 Aug 2011, 15:16

Re: Terrain Editing

Post by Zini » 22 Apr 2018, 11:38

unelsson wrote:
21 Apr 2018, 11:57
Zini wrote:
21 Apr 2018, 09:43
We still don't have a selection mechanism and there is still the elephant in the room, namely the issue of transit changes.
Building complete macros for drag&drop operations (transit changes?) should be implemented now. https://github.com/OpenMW/openmw/pull/1680.
That would work for the texture editing. It does nothing for terrain editing.

Sorry, I don't want to dampen your enthusiasm, but I really think we are not ready to deal with this problem. There is still a potentially large problem with the texture editing, we are missing the selection mechanism and the transient change support. I strongly recommend getting these out of the way first before even starting on designing the land editing feature.

unelsson
Posts: 94
Joined: 17 Mar 2018, 14:57

Re: Terrain Editing

Post by unelsson » 25 Apr 2018, 10:25

unelsson wrote:
21 Apr 2018, 20:39
I went through and got a bit into PlutonicOverkills code on terrain selection. Although the feature itself could be developed further, there are several problems (mostly with the feature itself, not really so much on code). Firstly, brush button settings window and terrain selection are both tied under primarySelectPressed. If selection feature needs to be fitted, maybe add a setting (checkbox? slider with two modes?) to brush window to toggle between select/edit, that is, whether primaryedit selects parts of texture grid or applies texture painting? Another possibility is just to use secondary edit, but that would interfere with the "select clicked texture" feature. Discarding selection should also be possible in some easy way, possibly if newly started selection click doesn't hit any land. What's the actually needed use for selection feature - is it drag&dropping textures to selected area? Moving shapes of textures - if so, what's going to be left under moved terrain? Copy-pasting texture areas ("currently custom selection" in brush settings window)? Is it Ctrl-C copy or some other method of copy?

Second problem with terrain selection is the size of the grid - somewhere it was mentioned that selection feature should work differently whether we are land editing (selecting vertices) or selecting pieces of texture grid. In PlutonicOverkills branch, while the selection seems to work correctly, it's drawn to only corner of the cell (in smaller size instead of texture size). This branch could be developed into different directions - selection could be permanently visible, or it could be visible per-edit-mode. It might remember the selected area after changing editmode, or delete the selection from memory. When changing editmodes, there might be an algorithm that tries to estimate a selection and convert the selection into another mode - this should be fairly accurate when changing from texture grid to vertices, but other way around requires some weird approximation that obviously loses resolution. If multiple selections are visible, they should probably be coded somehow - color mayhaps? On the other hand, having multiple different overlapping selection lines drawn might make the scene look messy.
Zini wrote:
22 Apr 2018, 11:38
we are missing the selection mechanism and the transient change support
Adding to my previous questions on selection mechanisms, I'd need to have a definition of "transient change support" to be able to (try and) develop it properly. There is a sort of transient change, as I understand it, in the latest commit of texture edit, but I'm not sure if that's enough.

edit: Thinking this further, I understand the current implementation isn't "true" transient change, as it pushes commands straight away to command macro, and therefore changes data. Full support would require a data layer in between, probably at cell.cpp. Changing data directly through command macros seem functional in my tests, but maybe it's unoptimal.


Terrain select questions in summary:
- What (mouse) button will be used for terrain select?
- What button will be used to open a brush button settings window?
- If functions above share the same button, how should that be implemented?

Now, contrary to Zini's advice, I've also dabbled with some land shape editing, as I started developing a custom mod that needs it. I however haven't used much effort in making the code good for public use, and I won't make a PR until texture edit is settled. The functions (math used in land shape editing) are valid though, so maybe when it's time, they can be used for developing a proper land shape editing mode. So far, I have a decent raise tool, lowering tool and smoothing tool. Smoothing also applies some land normals, similar to tesanwynn, however I'm not sure if they are correct in the first place, and I haven't implemented normals calculations for land edges. Most edge tears are resolved though.

Screenshot here (land created first with tesanwynn, then heavily edited with opencs land edit)
https://imgur.com/kl5gQl7

User avatar
Zini
Posts: 5503
Joined: 06 Aug 2011, 15:16

Re: Terrain Editing

Post by Zini » 27 Apr 2018, 13:06

Sorry for the delay. Busy couple of days.
edit: Thinking this further, I understand the current implementation isn't "true" transient change, as it pushes commands straight away to command macro, and therefore changes data. Full support would require a data layer in between, probably at cell.cpp. Changing data directly through command macros seem functional in my tests, but maybe it's unoptimal.
Example: You want to raise a piece of terrain. You would typically do this by a drag operation (press mouse button, then move mouse). You would then see the terrain deform accordingly. But the changes should take effect only once you release the mouse. And you can discard them at any time by pressing ESC. Therefore the commands can only be issued once the button has been released.

Regarding the selection UI: Looking for the documentation now. May take a bit. Will get back to you as soon as I have found it.

Edit: Okay, that wasn't so hard. The documentation is actually linked from within this thread. See here: viewtopic.php?f=7&t=4322&start=10#p47370

See especially the 3rd issue (#3871). But #3869 and #3873 are also kinda relevant.

unelsson
Posts: 94
Joined: 17 Mar 2018, 14:57

Re: Terrain Editing

Post by unelsson » 29 Apr 2018, 13:50

Zini wrote:
27 Apr 2018, 13:06
Example: You want to raise a piece of terrain. You would typically do this by a drag operation (press mouse button, then move mouse). You would then see the terrain deform accordingly. But the changes should take effect only once you release the mouse. And you can discard them at any time by pressing ESC. Therefore the commands can only be issued once the button has been released.
I see. Can this be achieved with auto-undo? Commands would be entered to macro, data would be changed during edit, but if ESC is pressed, then macro is ended, and whole macro is then automatically undoed?

User avatar
Zini
Posts: 5503
Joined: 06 Aug 2011, 15:16

Re: Terrain Editing

Post by Zini » 30 Apr 2018, 10:38

Nope. This would disrupt the Undo stack. Pushing a command to the undo stack and then undoing the command does not leave the undo stack in the state it was before.

aesylwinn
Posts: 243
Joined: 14 Dec 2015, 20:30

Re: Terrain Editing

Post by aesylwinn » 09 May 2018, 16:59

unelsson wrote:
29 Apr 2018, 13:50
Can this be achieved with auto-undo?
Another way to approach this would be to add a difference map tied to each Land record that gets committed in one go, similar to how it works in view/render/object.hpp with translations and rotations (though much more complicated).

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests