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.

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.

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?

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