Terrain Editing

Involved development of the OpenMW construction set.
unelsson
Posts: 227
Joined: 17 Mar 2018, 14:57

Re: Terrain Editing

Post by unelsson »

I've tried to press every button in CS, but only window I find is Preferences. Pressing "Add new record" button in almost any "Edit record" view also changes the view slightly as it opens up a dialog, but I don't know if this is what you mean. Examples would be helpful, or perhaps a clarification on what this transient window means in this context?

Texture dropping to toolbar buttons didn't work with ModeButton for some reason. It doesn't accept drops even if the whole class is set to accept them. Probably requires a new class (like BrushModeButton) anyway, I'll try to implement that when I understand where these brush buttons should be in the first place.

Editing code has issues, and I'm aware of many of them. I think I fixed some of the worst issues today. Anyway, I'll make a reviewable clean PR when this brush feature is settled.
Since the land record and the land texture records must have the same modification state it is necessary to touch the land texture records (and pulling them out of base state) when modifying a Land record that is still in base state.
Um... Partially understanding this. With "modification state" are you referring to qUndoStack, mChanged variable (that, I'd guess marks that the record is modified), or something about the actual land/landtexture data stored in records?
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Terrain Editing

Post by Zini »

I've tried to press every button in CS, but only window I find is Preferences. Pressing "Add new record" button in almost any "Edit record" view also changes the view slightly as it opens up a dialog, but I don't know if this is what you mean. Examples would be helpful, or perhaps a clarification on what this transient window means in this context?
It seems I remembered incorrectly. The only transient button-anchored window we have is the right click list for the start OpenMW button (5th from the top, may require configuration with a debug profile first). This is a good example for the right click menu for the brush button (see feature description in the first posting). In fact it may be a good idea to generalise this window, so it can be used for both lists.

But there isn't currently an example for the window we are talking about. Still, we probably want a more condensed layout (to stay consistent with the overall style of OpenMW-CS) and the window must still be transient (close when a click outside the window happens).
Texture dropping to toolbar buttons didn't work with ModeButton for some reason. It doesn't accept drops even if the whole class is set to accept them. Probably requires a new class (like BrushModeButton) anyway, I'll try to implement that when I understand where these brush buttons should be in the first place.
I thought we had that working with debug profiles, but apparently we can only drag debug profiles to the scene, not to the button. This won't do for the brush. So yeah, that needs to be addressed.
Um... Partially understanding this. With "modification state" are you referring to qUndoStack, mChanged variable (that, I'd guess marks that the record is modified), or something about the actual land/landtexture data stored in records?
No. Take a look at CSMWorld::Record. This class has to fields: mBase and mModified. All records from all but the last content file in the content file list are collected in mBase (if any). The matching record from the last content file (the one we are currently editing) is stored in mModifed (again, if it exists at all).

The modification state is specified by CSMWorld::RecordBase::State. This is pretty well documented.
unelsson
Posts: 227
Joined: 17 Mar 2018, 14:57

Re: Terrain Editing

Post by unelsson »

Turns out changing window to transient window (Qframe, Popup) is very simple. Getting the drag&drop to work is a whole another issue though.

Buttons in toobar only follow what's told to class Scenetoolmode, even though ModeButton's (EditMode and TerrainTextureMode) are actually what is visible. Therefore, one has to apply changes to Scenetoolmode, at runtime, to change setAcceptDrops value accordingly. Even if that can be done, I have some serious trouble passing drop events to TerrainTextureMode. And that is pretty much necessary for changing the brush textures. Something like that had been done at worldspacewidget.cpp when dynamic_casting editMode (perhaps similar logic would work at pagedworldspacewidget.cpp... Will have to look that later though... definately sauna time right now.

edit: Problem with drag&drop solved. Connecting qDropEvent etc. from scenetoolmode to Texturemode's slot handleDropSoOn works and handling setAcceptDrops accordingly. If other modes wish to use the same button for other functions, there has to be more data checks etc. along the way. Will clean up the code a bit and commit to github.
unelsson
Posts: 227
Joined: 17 Mar 2018, 14:57

Re: Terrain Editing

Post by unelsson »

Changes to brush button done and committed, but broke git somehow as I merged the new commits from master to my local, and then back to PR. I don't know what's the best way to solve this. Rebasing something? Making a new fork and a new PR?

Brush overlay code (for osg 3.6) saved in a different branch, and code has backup locally out of git's reach. No PR, as it's not compatible yet.

Texture primary edit has a local branch that kind of works. I'd like to make an early PR, but I'm a bit worried as it seems that my master branch carries some merges that will break pull requests.

I assume land shape editing should follow similar logic that texture edit, with x-y map's of normals and height data. Haven't done any actual coding on that yet, as it should be easier to develop after the texture editing primary mode works in a good way.
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Terrain Editing

Post by Zini »

The heightmap is more complex than the textures (both from a data structure point and regarding the required editing tools). Once you finish up the texture editing and if you still want to continue, I strongly suggest you do the selection mechanism first; starting with texture tile selection and then moving on to terrain vertex selection.
unelsson
Posts: 227
Joined: 17 Mar 2018, 14:57

Re: Terrain Editing

Post by unelsson »

I'm bombing this thread with questions.

When editing a plugin, land textures are not shown on land textures table. How should the user select texture brushes in plugins? Is command CSMWorld::ImportLandTexturesCommand related to that - essentially, does user need to click somewhere to import land textures for use?

edit: I was able to create a plugin that alters land textures. I created two new textures, pointed them to random Morrowind texture filenames, and chose texture with id 1 and painted all over with that (I knew index 1 would be translated to 0 because texture indexing reserves 0 for default texture). Game log says "cant miss texture this and that, using default texture". That is probably because altered cells try to load textures from plugin, and as there are none, it reverts back to default. It's pretty much expected result. I wonder what's the correct way to do handle landtexture-data in plugins though? E.g. should opencs go through modified texture grid's and then copy all land textures not specified by user from morrowind.esm, or is it okay to have this "Unable to find land texture index" error behavior, or is it "modders responsibility" to do whatever they wish with the data?
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.
Texture editing new game based on Morrowind seems to work fine even through straight data editing, bypassing command system. Obviously this should go through command system, and through direct data editing there's the issue with drag-like painting, when every drag-event would need to have an undo, and one stroke would likely result in something like dozens of undo-events. Working with a copy is possible, but without the layer, painted terrain won't be rendered until the drag is finished. For alpha version, I think this might be tolerable (I'd be happy if something like this was available in 0.44), but are there also other things hidden behind the data layers that I'm not picking up?

edit: Hmm.. mBase and mModified. With one file it's all the same, but more than one file.. hmm..

Below is a screenshot from Seyda Neen. There's one texture that fails in both opencs and openmw: textures/tx_lavacrust00.dds (86 as brush, it's probably 85 by real id number). Other textures work fine.

https://imgur.com/i7DEWnD

Here's an early PR for feedback. https://github.com/OpenMW/openmw/pull/1680

edit: Here's what the PR does, https://youtu.be/caN1x3Mdy7Y?t=23s
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Terrain Editing

Post by Zini »

Remember that land and land texture records need to be in the same content file; meaning if you modify a cell that was in base it is pulled into modified (automatically). But in this case you also need to pull the required land texture records into modified. I believe the command you mentioned is related to that, but not 100% sure.

If the user is using a new texture that was not previously used as a land texture in the modified content file you need to add a new land texture record.

I don't think the transient change issue applies here. That is for changes that are visible but have not yet gone into the document data. We don't necessarily have this case with texture editing.

Having multiple commands issued isn't a problem IMO. I would however (in case of drag operations) check if a change doesn't actual change anything and if that is the case, avoid issuing a command. If this does become a problem though, maybe we can batch changes up in a low time interval (like 0.2 s or something)? That should be able to cut down on the command spam.

If that all doesn't work then we would indeed have to use transient changes, which is a major problem because we still have no idea how to do it. A first iteration without dealing with this problem (one way or another) would be acceptable.
unelsson
Posts: 227
Joined: 17 Mar 2018, 14:57

Re: Terrain Editing

Post by unelsson »

Seyda Neen valley (land shape edit)
https://imgur.com/VCYRqyY

Seyda Neen lava eruption (texture edit)
https://imgur.com/i7DEWnD

I started experimenting with land editing in a local git branch, but so far pretty much just experiments... I've been concentrating on getting the texture primary edit finished, so that it would be easier to work on land editing. Selection modes feel currently a bit far fetched, unknown territority, but well.. So far everything I've implemented has been full of learning new stuff, and when I've thought that learning something new is going to take a week or a month, it has taken a day. I've got much farther with coding than I ever expected. Now, regarding land editing, it took me less than an hour to get everything from texture edit converted into land edit to get different brush shapes working etc... Surely, it's just proof of concept that land heights data can be edited. :)
unelsson
Posts: 227
Joined: 17 Mar 2018, 14:57

Re: Terrain Editing

Post by unelsson »

I've thought of different submodes/brushes for land shape editing and played with some algorithms. Circle brush shape is probably most useful, as it's a natural shape - U-shaped curves algorithms can work quite nicely. It would be great if one could rise table mountain shaped plateau's with single tool. On the other hand, fairly sharp peaks should be possible too. Even with smoothing algorithms in place, altering circle brush size could achieve precision - you could even use brush sizes 1-10 to create spike-like features. Maybe shape editing tool settings frame could have an extra slider for curve peak width, essentially applying S-shaped smoothing only after certain percentage of brush size. If brush strength would be even without any smoothing, circle shape would create plateaus, but with quite sharp edges. Land rising or depression can be done either with two different brushes or with drag&drop. There are advantages and disadvantages to both. Drag&drop does reduce the amount of needed tools, but requires a lot of hand movements to build shapes. I would vote for two different tools, for the ease of use. Also, a smoothing tool and flattening tool would be useful, if not mandatory.
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Terrain Editing

Post by Zini »

Wow, complex issue. I haven't given much thought to the terrain editing tools yet. Your ideas sound mostly reasonable. But there need to go a lot more design work into it before we can get started with the implementation.

I feel it is a bit early for that. We still don't have a selection mechanism and there is still the elephant in the room, namely the issue of transit changes. We can get away with a first version of texture editing without it. We can absolutely not get away with a first version of shape editing without it.
Post Reply