Creating Large Worldspaces

Introduction

As opposed to small worldspaces (4 quads or less), working on large worldspaces (4 quads or more) requires almost a completely different method from the very start. Before starting your grand project, you should first take a moment and think over what it is you are hoping to achieve, and how much of it is doable by you or your team. Large worldspaces, like the large projects which require them, require rather excessive amounts of hours of work, however unlike with that quest mod that takes place in mostly vanilla spaces, work on a large worldspace often requires several weeks of work and preparation before you can even START on placing buildings, NPCs, and quests. As such, it is not something which should be taken lightly.

Getting Started

First, you should ensure you have the following 3rd party programs installed and working as you will need to make use of each of them at some point. [Oblivion Mod Manager] - load order management (Wyrebash also accepted) [TES4Gecko] - Needed to move worldspaces, remove records, convert to/from .esm and merge. [TES4Edit] - Needed to remove records and remove VWD flags from objects. [TES4LODGen] - Needed to generate distant objects after VWD flags have been removed.

In particular TES4Gecko can be tough to get working right with the shortcut, but the additional memory which is setup through this shortcut is NECESSARY for merging. The readme file contained with the program can tell you more.

Before continuing, this primer assumes that you have already briefed and familiarized yourself with using both the heightmap editor and the region editor as well as have considerable experience in working with worldspaces and the CS. If you have not done this, you should probably take a few days to play around with those two tools to see how they work on a worldspace you aren't particularly tied to completing. The following links should be of particular interest. [Heightmap Editing] - Technical details [Heightmap editor] - Practical details [Basic Landscaping Tutorial] - Some work with the landscape editor will ALWAYS be needed [Regions] - Technical stuff about setting up regions [New World Space and Region borders drawing]- Not needed, but very useful.

Once you have a handle of the related tools, you can begin. Even if you already have significant aspects of your mod completed, you should ALWAYS start a new worldspace within a new .esp. The reason for this is simple, if you're only loading your worldspace in the CS and not some other mod, the CS has more memory free so crashes are less frequent. The added benefit of not having some chance of screwing up the mod you already worked on is pure bonus.

Start a new .esp, loading only Oblivion.esm. As soon as the CS is done loading, save this .esp with a name you will recognize later. Now define your worldspace in the CS. Don't create any terrain for this worldspace quite yet, just have it defined. Save the mod again. Although this may seem a bit redundant, some aspects of the heightmap editor (notorious for being problematic as you probably know) don't work particularly well when working on a worldspace which has not been saved (it's a memory thing); saving the mod records the definition of the worldspace within the .esp, so it is more stable (or something). Now you can begin within the heightmap editor.

In the heightmap editor, you now have to make a very important choice about how large you want this worldspace to be. If 4 quads (64x64 cells) is enough space for your mod, you can skip to the next part. If you need more space, or want to have your worldspace offset from 0,0 several quads, you should "generate overview" now, and move to where the quads you want to start on should be located (don't save any terrain). Although your worldspace may eventually be larger than 4 quads, for the sake of memory and stability, you should never work on more than 6-8 quads at any time.

The World You Have Created

When you've finished creating the terrain for those 4 quads you have active, save the terrain in the heightmap editor, and fix the holes you get at 0,0 and the corners of the quads as you normally would before saving. Then close the editor.

When working on worldspaces 4 quads or larger, you should convert the worldspace to a .esm regardless of how you intend to release that mod. There are two reasons for this. 1, by using a .esm which just has .esp files merged into it, you always retain a backup of the worldspace at the last point of merging, so if you screw up something horribly while heightmapping, you don't have to start from scratch (should still make backups of those .esm files). 2, due to limitations in the CS and your system, working on too many cells can lead to severe instability and/or frequent crashing. The more cells a worldspace has, the more it needs to load into memory while you're working on it. .esp files larger than 40mb (8 quads) usually cannot be loaded in the CS without some sort of error popping up. Even if you are only using 4 quads for your worldspace and plan to release as a .esp, you will still want to use a .esm during creation just so that you can take advantage of the benefits of this format.

When testing your .esm, always have it loaded in the 01 index so that extra steps (in particular moving worldspaces and removing vwd references from trees) aren't needed in order to get an idea of what the terrain really looks like. If you don't know how to do this, you may wish to take a few moments with [Oblivion Mod Manager] or WyreBash to learn how to manage your load order. If placing your .esm in the 01 index interferes with other mods, you may just want to create a new character with only your worldspace active and just cheat your way to this space.

For a particularly large worldspace, you have no option other than using .esm format for release, and will need to make adjustments related to this as far as connections, quests, and LOD data is concerned.

Use TES4Gecko, convert the mod to a .esm, then base all further work on that mod as a .esp with both that .esm and oblivion.esm loaded. When whatever work is done within that .esp, merge the .esp into the .esm with TES4Gecko. Keep in mind that within a .esm you cannot have any changes to a vanilla worldspace (even placing a door in a vanilla exterior) without causing the landscape to get screwed up. Once you have trees and other stuff, you will also need to clear out all the VWD flags for your worldspace using TES4Edit in order for your worldspace to show correctly when loaded anywhere other than the 01 index. You would need to do this cleaning after every change which adds more trees, but thankfully, you only need to clean out those things which were added/moved.

When it comes to blending the landscape from 1 four quad group with another, you should probably do this in the landscape editor rather than edit the two bordering quads within the heightmap editor. The reason being that it saves you from having to fix holes which form in already finished areas, and makes the .esp to be merged a more manageable size. The general method of editing should involve smoothing the terrain along that border (in landscape editor) so that both sides are within no more than 4000 units of eachother and there is no rip between quads, then use the standard raise/lower tool to get the desired result. You can increase the landscape sensitivity to make movements faster within the CS options (same tab as grid settings), but this can often lead to jagged looking terrain, so may need some selective smoothing with a smaller tool before region generation. If you are working on a space that is 4 quads, you won't need to do any of this and can neglect the edges of your worldspace and hide them by leaving a buffer of about 3 cells between the edge of your quads and playable regions. However, you should still take note of this incase you decide to come back to this to generate dummy terrain so that your world has LOD terrain which extends into other quads.

Regions

Before doing region generation, make sure you have a backup of the .esm, and have merged all terrain that you planned to do. As you setup your regions, it is suggested that you do some small test patches (4 cells 2x2) with that region to see how it will texture and place things. Once you have a region to your liking, remove it and all objects generated by that region within the same CS session, and move on to testing the next region. DO NOT SAVE YOUR MOD WITH ANY GENERATED ITEMS IN YOUR WORLDSPACE AT THIS TIME, ALWAYS CLEAN BEFORE SAVING. Before defining actual region borders, save your mod, open it with TES4Gecko, and remove any entries which refer to edited cells. Merge this region mod so that the settings are contained within your .esm and can be reverted to later. Make a backup. Now, start a new .esp for your region borders. Only define the region borders DO NOT GENERATE THEM. This mod will have some small cell changes, so is not as easy to clean, which is why you did this as a separate .esp. Make sure it has no placed objects, then merge it.

There are two very important things to keep in mind when generating regions: 1) Larger regions mean not only more time spent generating, but also larger .esp size, and depending on system specs and density of items, can lead to frequent crashing (why we're using a .esm). The only thing you should be doing while working on region generation is generating objects for that region. Leave ALL other structures and statics until after you've generated EVERYTHING as these structures can often get buried during generation.

2) Once an object has been placed in a cell from region generation, and once that session has been saved and ended, the object can no longer be removed by that region. Meaning that if you want to change any settings related to region items, or have overlapping regions, you would have to manually remove them cell by cell if you've already saved the mod and started a new session. To make life easier, you should adopt a rather simple method of avoiding this problem all together. After every region you generate, select every bordering region and select "remove objects for this region". Even if you havn't generated that region yet, the region you generated placed objects slightly outside its border, and once saved, these objects may be doubled when that bordering region is generated later. This will leave only the space which exists only within the one region you generated as having items (the remaining parts will be mostly generated with those other regions. Save the mod, merge, and work on the next. For small regions, you can do more that one region per .esp, but should avoid generating regions which are near eachother within the same .esp. For larger regions, you should keep it to a single .esp per region.

No doubt you're staring at this a bit confused. Just take your time and work through it one region at a time. For a 4 quad worldspace which is entirely generated, it is to be expected that you will be spending no less than a week doing little else other than generating objects if you are using several regions and region types (took me a little over 2 weeks when I did one 4 quad worldspace simply because I had to figure out most of this stuff and deal with crashes when the CS ran out of memory). For larger worldspaces, significantly longer. The downside however is that in order to make the landscape work right as a .esm without requiring it to be loaded in the 01 index, you will have to go through a few thousand tree entries in TES4Edit and remove the vwd flags. It's not as bad as it sounds since most of the work is just lots of clicking on the little + boxes and expanding cell information, but there isn't any sort of automated script which does this to my knowledge. You would also need to use TES4LodGen to generate distant objects afterward, but that's a fairly quick thing.

Dummy Terrain

Often overlooked is the purpose of using dummy terrain instead of just making your worldspace larger in order to have those neat LOD vistas. Dummy terrain is simply terrain which exists as a LOD, but does not exist as actual terrain within the mod people have. The purpose of this is to give the impression of distant landmasses without adding the additional filesize. Keep in mind that in order for trees and LOD terrain to show up on this dummy terrain, you would need to include the LOD meshes, textures, and Distant Object files with your mod (as opposed to having people generate their own).

The way this works is to use the .esm containing your finished worldspace, and create a new .esp based on that .esm. As LOD meshes are generated 4 quads at a time, you will only be able to work on 4 quads at a time, and each .esp for dummy terrain should only contain 4 quads regardless of how large your worldspace may be. NEVER MERGE THESE .ESP FILES WITH YOUR .ESM. Do a 4 quad area, generate LOD regions (just trees, textures and rocks) for these areas, save the .esp, generate the LOD mesh for those 4 quads, save it, and start on the next dummy terrain. It is a good idea to use descriptive naming with these .esp files. Something like "MyWorldspaceTerrainDummyEast.esp" is more useful than "DummyTerrainMod01.esp" should you ever need to fix any problems with that terrain or the related LOD files.

Try to change as little of your completed worldspace landscape as possible. Some blending will still happen along borders, but the better you can match these dummy terrains with the existing terrain that exists within your .esm, the better. Although nothing you do within the .esp files containing the dummy terrain will take effect on the actual worldspace of your mod, less difference along borders means closer LOD approximation.

When you've done all of this, you should now have LOD meshes and textures for the quads surrounding your worldspace. Now we need to generate the records for distant objects in these quads. Have your .esm and ALL of those .esp files containing your dummy terrain marked as active in your load order, Then use TES4LodGen to generate the distant objects for your worldspace. This may take longer than normal since you may be working with 4-10 times the number of cells, be patient. Once it has a message saying that the process is done, close the program, and test it ingame, being sure to uncheck those dummy .esp files. If all went well, you should now have distant mountains and terrain which extends well beyond your worldspace border, which vanishes if you go through your border regions or get too close. If not, you may need to regenerate/fix some of the LOD meshes for those quads.

When you have a working dummy terrain, package the LOD models, the LOD textures, and the entire distant objects folder in a .rar or other container, make a backup of the file, and release it as an optional download for your mod. You should still file away your dummy terrain .esp files incase you need to make changes to one of those sections, or decide to expand into one of those quads with playable terrain (forcing you to release as a .esm, and have a larger file size). People will not need the .esp files to see the terrain, but you will if you need to fix anything in those areas.

This not the only way of generating dummy terrain, but is probably the most straight-forward. Another method likely exists if you are using several playable worldspaces within a non-playable parent worldspace, as a means of unifying them all together, but this can become rather difficult to manage.