Terrain Editing

Involved development of the OpenMW construction set.
User avatar
Zini
Posts: 5120
Joined: 06 Aug 2011, 15:16

Terrain Editing

Post by Zini » 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).

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

Re: Terrain Editing

Post by Zini » 12 May 2017, 15:01

Okay, this duplication of functionality (brush and selection) irritates me to no end. Maybe we could just use the brush from the brush button for the selection. I need to think about that.
But that does not affect the main question (is there any interest).

User avatar
DestinedToDie
Posts: 1048
Joined: 29 Jun 2015, 09:08

Re: Terrain Editing

Post by DestinedToDie » 12 May 2017, 15:22

There are 2 features which I greatly anticipate.

1. Doormarkers.
2. Terrain texturing, as you said.

After that, I would add a third one.

3. Snap to Grid.

With doormarkers and snap to grid, you could make a house mod, which is a very common beginner's task to learning CS (or OpenMW-CS, in this case).

I think it makes sense to finish these areas before moving on to the behemoth that is terrain editing. People might not be able to edit terrain for a while, but at least they could make house mods. I don't think a lot of mods even use landscaping and ambitious projects that add new landscape could keep making their landscape in CS, but move all other work to OpenMW-CS.

There is also the question of merging .omwaddons. OpenMW-CS simply wants to merge everything (unless I'm mistaken?). Projects like Tamriel rebuilt keep multiple .esm files and they wouldn't want to be forced to merge Morrowind.esm, Tribunal.esm, Bloodmoon.esm, Tamriel_data.esm TR_mainland.esp into 1 .omwgame file. Being able to choose what you want to merge might also take higher priority over terrain editing.

All in all, I don't think terrain editing is really *that* important (at least at the moment). If we fix these other things, I can tell modders with confidence that it's time to switch over to modding on OpenMW-CS. Terrain can come after 1.0 for all I care. :D

User avatar
raevol
Posts: 2400
Joined: 07 Aug 2011, 01:12
Location: Caldera

Re: Terrain Editing

Post by raevol » 12 May 2017, 21:02

Zini wrote:Little we can do about speeding that up.
But what can we do about speeding that up? It's ridiculous that we're sitting here on our hands while only one major feature is sitting between us and almost being done. Can we pool our efforts and tackle this?

Maybe scrawl can share his knowledge of how the renderer works? Zini can share his knowledge of how the engine is structured? And then we can start piecing together how to get this implemented?

Biboran
Posts: 80
Joined: 03 Feb 2016, 12:50

Re: Terrain Editing

Post by Biboran » 12 May 2017, 21:22

raevol wrote:
Zini wrote:Little we can do about speeding that up.
But what can we do about speeding that up? It's ridiculous that we're sitting here on our hands while only one major feature is sitting between us and almost being done. Can we pool our efforts and tackle this?

Maybe scrawl can share his knowledge of how the renderer works? Zini can share his knowledge of how the engine is structured? And then we can start piecing together how to get this implemented?
Sorry guys, but what about all that AI issues in roadmap? :oops:

PlutonicOverkill
Posts: 16
Joined: 25 Apr 2017, 08:54
Location: New Zealand

Re: Terrain Editing

Post by PlutonicOverkill » 13 May 2017, 05:56

I'd be interested in giving this a go. Granted, I haven't worked with this part of the code before, but I think I could figure it out. I just have no idea where to start.

User avatar
raevol
Posts: 2400
Joined: 07 Aug 2011, 01:12
Location: Caldera

Re: Terrain Editing

Post by raevol » 13 May 2017, 09:39

PlutonicOverkill wrote:I just have no idea where to start.
You basically need to start by delving into the code and figuring it out yourself. Only one person on the team has had anything to do with this part of the engine for our entire development, and he hasn't shared anything with the rest of the team. I gave it a shot a while ago but was thwarted by my lack of ability. I may give it another try while I am free from classes for the summer, but don't expect much from me.

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

Re: Terrain Editing

Post by Zini » 13 May 2017, 11:16

PlutonicOverkill wrote:I'd be interested in giving this a go. Granted, I haven't worked with this part of the code before, but I think I could figure it out. I just have no idea where to start.
With "this" you mean the terrain editing task? Or one of the other issues brought up here?

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

Re: Terrain Editing

Post by Zini » 13 May 2017, 11:17

raevol wrote:
Zini wrote:Little we can do about speeding that up.
But what can we do about speeding that up? It's ridiculous that we're sitting here on our hands while only one major feature is sitting between us and almost being done. Can we pool our efforts and tackle this?

Maybe scrawl can share his knowledge of how the renderer works? Zini can share his knowledge of how the engine is structured? And then we can start piecing together how to get this implemented?
IIRC the shadow issue is related to a problem in OpenSceneGraph. scrawl would the right person to talk to about this topic. I have no further knowledge that could be useful regarding this issue.

PlutonicOverkill
Posts: 16
Joined: 25 Apr 2017, 08:54
Location: New Zealand

Re: Terrain Editing

Post by PlutonicOverkill » 14 May 2017, 05:40

Zini wrote:
PlutonicOverkill wrote:I'd be interested in giving this a go. Granted, I haven't worked with this part of the code before, but I think I could figure it out. I just have no idea where to start.
With "this" you mean the terrain editing task? Or one of the other issues brought up here?
The terrain editing task. More specifically, one of the smaller subtasks. Just something that's not too difficult for a beginner.

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests