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 »

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 »

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.
JesterRace
Posts: 3
Joined: 05 May 2019, 01:23

Re: Procedurally Generated Terrain

Post by JesterRace »

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: 227
Joined: 17 Mar 2018, 14:57

Re: Procedurally Generated Terrain

Post by unelsson »

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 »

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.
unelsson
Posts: 227
Joined: 17 Mar 2018, 14:57

Re: Procedurally Generated Terrain

Post by unelsson »

There's no sensible hard limit on map size, but currently objects that are too far away from the world origin begin to wobble because of some float/double imprecision. I'm not sure what the limit is currently.

For the procedural generation, having a system that branches into "trees" of interconnected references is of course possible, but that is getting fairly specified. I made a simple system for the base, and for my purposes it's quite enough. More refined system probably needs some constraints and further details.

I can think of a system of moderate complexity: A generation tree, where a generated object would call for a sub-class of instances to be generated. For example, when the system generates an instance for a pine tree, it then generates a few suitable mushroom species somewhere close-by. This kind of system is not overly complex to design.

This kind of system can be developed further.. kind of mimic a more refined generation system. For example, one could just set a variables for min-distance-from-parent-object and max-distance-of-parent-object and various other parameters. A more complex system has plenty of cool-value, but requires a ton of work to implement: Such as where the system generates a subclass of surface-following roots that go in curved paths around a generated tree, having mushrooms (as subclass of roots) that stick to the surface of their parent object, and then having randomly placed lichens and vines to hang from the branches of the trees... Trees themselves could be procedurally generated, but that kind of system requires plenty more of work in design and modeling: 3d object design, game environment design, coding... If done real-time, it also takes more processing power, so at some point there are limits in this too.

--------

Another thing is that what should we do with the current proc-gen-branch? It's yet another feature that has an idea, but is unpolished. What kind of UI should this have? The current system uses an extra window for tuning parameters, saves the procgendata into a text file, and details can be tuned in text editor too.

edit: Also, is this basic system wanted for the editor in the first place? Do we want a more fancy run-time proc-gen system? Do we instead or also want to have generation objects that place child-objects around them during engine run-time? Do we need hovering generation objects, or should these generation objects omit the z-coordinate in order to always stick to the ground level?
Lamoot
Posts: 176
Joined: 22 Apr 2016, 12:03

Re: Procedurally Generated Terrain

Post by Lamoot »

Procedurally Generated Terrain can refer to a few different things so let's clarify. I can think of the following three meanings:
  • Procedural generation of terrain height map
  • Procedural "painting" of the terrain with textures
  • Procedural placement of objects and instances
The first two would be easier to get by having an option to import a heightmap or similar maps to distribute the textures. There are very capable programs available and by "only" importing the maps produced by these programs, OpenMW would plug into a world of possibilities (and quality terrains!)

The third one, procedural placement of objects is what looks to be currently in the works. This one would fit into OpenMW-CS and would drastically reduce the work required to populate the world with filler props.
Post Reply