I've been looking into this, kind of learning OpenMW and C++. My knowledge and coding skills are not yet up to the task. Luckily though, there seems to be quite a lot of infrastructure built for terrain editing already. Does anyone know whether the editor already duplicates the world terrain data into editable array? How about saving the terrain data (texture and shape) to omwaddon?
I can't find a documentation to find what part of the code does what, so I'll just drop my first findings here so that it's easier to continue on research later.
(BELOW THIS POINT ONLY RANDOM FINDINGS ABOUT TERRAIN EDIT CODE)
In worldspacewidget.cpp there are checks like mDragMode == InteractionType_PrimaryEdit . This seems to be checking that the user is dragging something in terrain editing mode (anything regarding either terrain texture or terrain shape). Worldspacewidget functions control parameters of event, QMouseEvent class that handles what user does with mouse.
view/render/editmode.cpp (funcion primaryEditPressed) is called, when right mouse button is pressed in any terrain editing mode.
In
instancemode.cpp there's an implementation of instance moving.
worldspacewidget.cpp controls the window where you can edit stuff.
This line sends the program to editMode.cpp / primaryEditPressed when one presses rmb in terrain edit mode. If there was land data on hand, it would be possible to use that as argument to editmode?
Data structures (TypeData) in model/world/universalid are mysterious.. There are both Type_Land and Type_Lands used, but that seems to unrelated to actual terrain editing. I wonder what these refer to anyway.
view/render/terrainstorage.cpp has code for land, but git commits label them as old, so maybe there are some new methods developed at related commits at
columnimp.cpp. Also
components/esm/loadland.hpp handles terrain.
Data structure QAbstractItem from
pagedworldwidget is handling land data, and there are several functions regarding land. Similar code in
worldspacewidget.cpp doesn't seem to hande land data. Haven't yet figured out the data flow here.
Had trouble figuring out connect-command. Here is a
tutorial for that.
Apparently editor stores data in templates for all data types, <Record<ESXRecordT> and land-records are accessed via "Record<Land>"..
model/world/universalid.cpp has typedef's for records. There are abstraction layers in between that are controlled by model/world/ref..whatever.
CSMWorld::Record< ESXRecordT > Struct Template Reference
model/world/nestedcolumnadapter.hpp - CSMWorld::Record< ESXRecordT >
model/world/data.hpp defines what goes in the base columns, and holds all sorts of mVariablesForData. Backtracing where this data is sent is probably key to understanding the data structures.
More about data structures. Apparently these functions will get some Land-related data moving, if one is in editmode. U
This code will get some data moving to editmode. Just need to dig deeper to Resource templates I think. This might be totally wrong kind of data though.
Code: Select all
CSMDoc::Document& document = getWorldspaceWidget().getDocument();
CSMWorld::Data& data = document.getData();
CSMWorld::IdCollection<CSMWorld::Land>& landidcollection = data.getLand();
If I'm on the right track, IDCollection Land holds Column LandHeightsColumn that has land height info. (again, might be totally on wrong track too).. (and I'm intentionally not using the standard variable naming convention yet for this testing phase).