Terrain Editing

Involved development of the OpenMW construction set.
User avatar
Greendogo
Posts: 1374
Joined: 26 Aug 2011, 02:04

Re: Terrain Editing

Post by Greendogo » 10 May 2018, 01:55

@Zini: How does the Undo Stack function? Is each alteration (undoable act) pointed to by the previous one in some way?

Do we retain the Undo Stack in a saved plugin?

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

Re: Terrain Editing

Post by unelsson » 10 May 2018, 08:29

Difference map seems like the proper solution. I'll see how view/render/object.hpp does the difference map. I suppose terrain editing should change a temporary land&ltex arrays in cell.cpp. When land is edited, the edit is rendered, but not yet committed to actual records. When mouse is released, the edit goes to undostack.

There are many variables stored in one land record, including normals, heights, low-lod heightmap, texture map, rgb color, so storing all these might be excessive. To increase performance and reduce memory usage, perhaps only limited amount of these should be stored in temporary difference maps? Changing terrain textures is simple, it should only store temporary texture array, but in land shape editing, should changing land shape only store land shape and calculate normals only once after mouse is released?

This transient change support is somewhat big thing to do, and this gives some idea on how to develop it, but I'll concentrate on finishing the first version of texture primary editing without it first. The code now has a function that's called for pushing land edit's into command system, so I believe that can be later edited to push changes into difference map instead of directly into undostack.

Greendogo: Undostack is Qt's QUndoStack, it's not stored in saved plugins. All changes in OpenCS are stored in sequence as commands that can be undoed and redoed. There's some OpenMW-specific code to this too, but I'm not too familiar with all the parts.

User avatar
Greendogo
Posts: 1374
Joined: 26 Aug 2011, 02:04

Re: Terrain Editing

Post by Greendogo » 10 May 2018, 08:43

Ah, I see. I was just thinking how cool it would be if each edit was saved as an in-order linked-list so you could have a record of all game/plugin changes made to a plugin, in order.

User avatar
wareya
Posts: 221
Joined: 09 May 2015, 13:07

Re: Terrain Editing

Post by wareya » 10 May 2018, 11:34

Sorry to butt in, but if you guys are looking at the landscape texturing code, can you take a look at https://imgur.com/a/erRgi too? I haven't tested it in a few months so I'm not sure if it got fixed somewhere without the bug being updated, but landscape texture rendering is offset by one (texturing) vertex to the southeast. Whatever controls darkening is fine, though.
paying attention to #1751/#1816 #2473 #3609 #3862/#3929 #3807 #4297

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

Re: Terrain Editing

Post by unelsson » 10 May 2018, 13:24

wareya wrote:
10 May 2018, 11:34
Sorry to butt in, but if you guys are looking at the landscape texturing code, can you take a look at https://imgur.com/a/erRgi too? I haven't tested it in a few months so I'm not sure if it got fixed somewhere without the bug being updated, but landscape texture rendering is offset by one (texturing) vertex to the southeast. Whatever controls darkening is fine, though.
There is a strange thing in texture coordinates indeed, x had to be offset -0.5 and y +0.5 to make worldspacehit accurate. Logically they both should be -0.5?

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

Re: Terrain Editing

Post by unelsson » 12 Jun 2018, 22:42

It seems that this bug was fixed. "Landscape texture painting is misaligned" Was that related to the offset of terrain textures in north-south direction?
https://bugs.openmw.org/issues/3876

There's some code that kind of hacks the worldspacehit to hit the correct coordinate in cs, and while editing still feels okay, I'd like to point out the lines here that might cause problems in the future. Why y needs to be offset by +0.5, and ranges of x and y controlled in such an awkward fashion.
https://github.com/OpenMW/openmw/blob/a ... #L235-L246

User avatar
wareya
Posts: 221
Joined: 09 May 2015, 13:07

Re: Terrain Editing

Post by wareya » 12 Jun 2018, 23:12

It just seemed to be an oddity in how vanilla morrowind functions. That said I just noticed another terrain related bug.

https://imgur.com/a/nzGazLY

In OpenMW, the default terrain, brown dirt, bleeds through between texture transitions. This doesn't happen in vanilla.

Doesn't really affect anything done with terrain editing though.
paying attention to #1751/#1816 #2473 #3609 #3862/#3929 #3807 #4297

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

Re: Terrain Editing

Post by unelsson » 13 Jun 2018, 00:06

Oh indeed, I can confirm this, default texture does bleed. I tested this in OpenMW and OpenCS. When seen it can't be unseen!

edit: This should be in bug tracker, care to file a report?

User avatar
psi29a
Posts: 4198
Joined: 29 Sep 2011, 10:13
Github profile: https://github.com/psi29a/
Contact:

Re: Terrain Editing

Post by psi29a » 13 Jun 2018, 08:41

it's already on the bug tracker and wareya already has a fix for this that is pending review before merging.

User avatar
wareya
Posts: 221
Joined: 09 May 2015, 13:07

Re: Terrain Editing

Post by wareya » 13 Jun 2018, 16:49

Yeah I put it up on the tracker after they said to. Was just looking to see if there was already a bug up for it before I put it on the tracker.
paying attention to #1751/#1816 #2473 #3609 #3862/#3929 #3807 #4297

Post Reply

Who is online

Users browsing this forum: No registered users and 10 guests