Terrain Editing
- DestinedToDie
- Posts: 1181
- Joined: 29 Jun 2015, 09:08
Re: Terrain Editing
I don't think anyone is working on this. It should be up for the taking.
Re: Terrain Editing
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.
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).
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.
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
Code: Select all
CSMDoc::Document& document = getWorldspaceWidget().getDocument();
CSMWorld::Data& data = document.getData();
CSMWorld::IdCollection<CSMWorld::Land>& landidcollection = data.getLand();
Re: Terrain Editing
Sorry for the late reply. It was another busy week.
We actually have a bit of a roadmap for this feature (viewtopic.php?f=7&t=2500). We decided to start with terrain texture editing (the easiest part). A developer had started to work on it but then went inactive.
Here is the PR: https://github.com/OpenMW/openmw/pull/1414
If you want to work on the terrain editing feature, finishing this would be the first task.
Edit: Oops I linked the wrong thread. Looking for the correct one. Stand by.
Edit 2: Lol, we are in the right thread (the one with the roadmap). Apparently I am getting old. Well, that's what you get for thread necroing![Wink ;)](./images/smilies/icon_e_wink.gif)
We actually have a bit of a roadmap for this feature (viewtopic.php?f=7&t=2500). We decided to start with terrain texture editing (the easiest part). A developer had started to work on it but then went inactive.
Here is the PR: https://github.com/OpenMW/openmw/pull/1414
If you want to work on the terrain editing feature, finishing this would be the first task.
Edit: Oops I linked the wrong thread. Looking for the correct one. Stand by.
Edit 2: Lol, we are in the right thread (the one with the roadmap). Apparently I am getting old. Well, that's what you get for thread necroing
![Wink ;)](./images/smilies/icon_e_wink.gif)
Re: Terrain Editing
I'm interested in developing this, but for now, with my skills, it's just going to be research on OpenMW data structures, Qt and C++ in general. If a more experienced developer wants to take this, I'm happy just to see how development goes on. I do have some time though...
Thanks for answering my questions on data though, and pointing out what's planned. I suppose terrain texture editing and terrain shape editing have a lot in common. It's hopefully something like values (height, textureid?) set on a x-y grid.
Thanks for answering my questions on data though, and pointing out what's planned. I suppose terrain texture editing and terrain shape editing have a lot in common. It's hopefully something like values (height, textureid?) set on a x-y grid.
Re: Terrain Editing
The data structures for terrain height are rather complicated (components/esm/loadland.hpp), Textures are a simple grid with indices into a texture table.
Unfortunately it doesn't look like we currently have any developer with enough time to tackle this feature. Its been dormant for quite a while.
Maybe you would be interested in a more simple sub-task that allows you to practise your Qt and C++ skills without going so deep into the data structures? We have for example this one here.
Unfortunately it doesn't look like we currently have any developer with enough time to tackle this feature. Its been dormant for quite a while.
Maybe you would be interested in a more simple sub-task that allows you to practise your Qt and C++ skills without going so deep into the data structures? We have for example this one here.
Re: Terrain Editing
I guess that brush-button is a good start! The functionality of the brush-button needs the texture editing implemented though, and I don't think the data structure itself is too complicated. Could you elaborate a bit on what would be the proper way of altering the data though - what file holds the functions and methods? Something like Data::Something::getmethod/updatemethod etc.? I went through the code regarding touching land records, so it seems there is at least qundostack hodling undo there..
Re: Terrain Editing
Commands system would be in commands.cpp & commands.hpp i assume ![Rolling Eyes :roll:](./images/smilies/icon_rolleyes.gif)
![Rolling Eyes :roll:](./images/smilies/icon_rolleyes.gif)
Re: Terrain Editing
CSMDoc::Document::getUndoStack
That returns a QUndoStack, which has a push method. You should be able to find the Qt documentation online, if you haven't done so already.
Commands can indeed be found in apps/opencs/model/world/commands.hpp. The most important is the ModifyCommand. Plenty examples in the code on how to use it. The table that contains the index-bitmap is CSMWorld::UniveralId::Type_Lands (this maps to a CSMWorld::Land collection on the lower level). The textures are listed in CSMWorld::UniveralId::Type_LandTextures (this maps to a CSMWorld::LandTexture collection).
That returns a QUndoStack, which has a push method. You should be able to find the Qt documentation online, if you haven't done so already.
Commands can indeed be found in apps/opencs/model/world/commands.hpp. The most important is the ModifyCommand. Plenty examples in the code on how to use it. The table that contains the index-bitmap is CSMWorld::UniveralId::Type_Lands (this maps to a CSMWorld::Land collection on the lower level). The textures are listed in CSMWorld::UniveralId::Type_LandTextures (this maps to a CSMWorld::LandTexture collection).
Re: Terrain Editing
Here is a pull request for brush-mode buttons. I don't really think it's good for a merge, but I thought it wouldn't hurt to put it out there in this early stage.
https://github.com/OpenMW/openmw/pull/1665
It's based on what Plutonicoverkill worked on earlier, editmode and instancemode. Brush modes don't yet hold any data regarding brush configuration, no sliders/boxes for brush size configuration...
https://github.com/OpenMW/openmw/pull/1665
It's based on what Plutonicoverkill worked on earlier, editmode and instancemode. Brush modes don't yet hold any data regarding brush configuration, no sliders/boxes for brush size configuration...
Re: Terrain Editing
Continuing the discussion in the PR ...
btw. you should assign a issue to yourself. I just gave you the necessary permissions on our bug tracker.
btw. you should assign a issue to yourself. I just gave you the necessary permissions on our bug tracker.