Procedurally Generated Terrain

Involved development of the OpenMW construction set.
Post Reply
JesterRace
Posts: 3
Joined: 05 May 2019, 01:23

Procedurally Generated Terrain

Post by JesterRace » 05 May 2019, 02:49

Hi, I've had some interest in the past of poking around with a hobby/side project related to procedurally generated terrain/meshes. I had a tendency to not stick to it because I didn't quite envision an end goal project, especially with my limited skills and time. Then I found the OpenMW project and am now looking for a bit of guidance.

I am a career engineer in infrastructure, but it doesn't involve programming (or very little) and related side pursuits have been at a beginner level, so I can't imagine I'd be of much practical use to the team. Still, I was thinking if this side project did produce anything of value, I guess that's something, but I don't want to get in the way either.

Back in college (10 years ago, lol) I was introduced to C++, prior to that was a bit of RPGMaker2k scripting (similar to Ruby? probably doesn't count haha), I did some basic C# tutorials a couple years ago, some TES/Creation Kit modding mostly trying to figure out how scripts work, messed around with Unity a bit, and have spent time doing some technical reading on various subjects related to game creation, hardware and related tech I suppose.

Recently, I have been trying to find the part of OpenMW project that reads the ESM files for the terrain coordinate data and once I "figure it out", or know enough to be able to read and write to a file at least, I figured I would try to write a program that would generate a random plane and see if I could view it in the editor. Then, build from there and see what I can make.

Basically, I was wondering if it was possible for me to focus my attention on particular files on GitHub to learn how they work? When I taught myself new things in the past, I usually work with the basics alongside a project example related to my end goal and gradually piece it together. I've been trying to look up programming terms and structure and then try to figure out what's going on in files of OpenMW, but I've noticed I might not be spending my time efficiently if I'm not focusing on the right part of the project.

I suppose if someone can guide me to a particular area of the project that focuses on reading and writing to terrain mesh data and has any other advice of course, I would appreciate it.

Also, thanks for keeping games like this alive, and improving upon them!

User avatar
Stomy
Posts: 47
Joined: 11 Dec 2018, 02:55
Location: Fhloston Paradise!
Contact:

Re: Procedurally Generated Terrain

Post by Stomy » 05 May 2019, 08:28

Unfortunately I don't think there's a particularly simple starting point for this sort of thing, and you do need a good grasp of fairly modern C++ OOP practices to be able to follow a lot of the codebase. If you haven't found it already though I would suggest focusing your attention on the contents of components/esm as that's what is used by both the game and the editor to load the format.

I also found the UESP page on the ESM format to be useful when diagnosing a problem with the editor's saving a few months ago, that way you can skip straight to the description itself rather than trying to parse out OpenMW's implementation of it.
Never attribute to bad code, that which can be adequately explained with clever hacks

JesterRace
Posts: 3
Joined: 05 May 2019, 01:23

Re: Procedurally Generated Terrain

Post by JesterRace » 05 May 2019, 09:00

No that's perfect. I had looked through that section at some point and then jumped to others while wondering if I was starting off the "right" way.

I know it's going to take me a ton of time to make small progress understanding any of it, but at least I know I'm starting in the right place.

Thanks!

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

Re: Procedurally Generated Terrain

Post by unelsson » 06 May 2019, 11:32

These PR's alter terrain shapes the way OpenMW-CS should (or I hope so). Maybe some examples can be found from there.
https://github.com/OpenMW/openmw/pull/2167
https://github.com/OpenMW/openmw/pull/2196

The logic is to use QT's UndoStack (QUndoStack class) to make all editor changes undoable. This is done via commands (apps/opencs/model/world/commands.cpp). One example of command use is at landshapemode PR's terrainshapemode.cpp though scaling PR's (2196) apps/opencs/model/world/scalingtool.cpp might provide a simpler and more straightforward example.

OpenMW-CS has layers upon layers how the data is handled, a starting point to understand this is apps/opencs/model/world/data.cpp , yet I feel the whole data structure is kind of deep, and it might not be necessary to understand everything in between. I can't say I understand it, but it might help to understand a little about it to make issuing proper commands easier.

The actual code that works with esm-format is at components, I'd see what's in components/esm , but something useful might be found also at components/esmterrain. Tesanwynn also does direct esm-altering, but it's not OpenMW-specific.

I have zero programming education either, and felt OpenMW-CS code quite intimidating at first glance. While it takes a lot of time to get into it, I think dabbling with OpenMW-CS code is a really good way to learn all sorts of things. At least my C++ coding skills have taken a leap since I started.

JesterRace
Posts: 3
Joined: 05 May 2019, 01:23

Re: Procedurally Generated Terrain

Post by JesterRace » 06 May 2019, 22:46

Great, I will look into these examples.

Yeah my vague take away from the layered nature of the project, which without using the proper terms, I think of as a giant tree of interconnected references. I assume the design is related to the purpose of OOP, which for this I see as every object or procedure in the game is it's own object/class to give the code in each object/class exclusivity from other code, but also give the ability to expand on that object/class. Hopefully that isn't too far off, any corrections to that are appreciated.



One side question I had related to my interest in ProcGen was, is there a hard limit to total map/cell sizes that is impossible to be exceeded due to something like subrecord size?

I realize this is outside scope and likewise my understanding right now, but I figured if there is a sort of easy answer it's worth asking. I think vanilla TES3-5 had cell limts of either 512 or 1024 total in one axis direction, which equates to around 20 to 40 miles. Skyrim had other additional practical limits related to Havok, not sure about TES3&4. This is more of a down the road concern, assuming I make progress of course.

Post Reply