Difference between revisions of "Creating Large Worldspaces"
imported>Bruneauinfo m (→Notes) |
imported>Bruneauinfo (→Practicality: added a note on size of the world space) |
||
Line 9: | Line 9: | ||
===Practicality=== | ===Practicality=== | ||
Before starting your project consider the practicality of it. Take a moment and think over what you are hoping to | Before starting your project consider the practicality of it. Take a moment and think over what you are hoping to achieve. Will you and/or your team be able to complete the project you're envisioning? Large world spaces require a lot of hours of work. The process of creating them can get very tedious at times. Unlike a basic quest mod that takes place in a vanilla world space, a large world space can require several weeks if not months of work and preparation before you can even start placing buildings, NPCs, dungeons, etc. To top all of this off large world spaces can take a very long time to load in the CS. If at all possible consider breaking your worldspace down into multiple plugins rather than creating the entire worldspace in one go. Waiting ten minutes or more for your world space to load in the CS can be very discouraging. Especially later on in your mod when debugging scripts causes the CS to crash frequently. | ||
The purpose of this warning is not to discourage you. What is being suggested here is before you start your project, and as you work on it, try to do two things. Try to keep it practical, because if it's not practical it probably won't get finished. And secondly know what you're doing. If you know how to use your tools the work will go much more efficiently. When a project is moving forward it helps motivate you to continue. If a project keeps running into delays because steps were skipped or a useful tip was ignored requiring a return to an earlier point in the project - this is what can kill a project. | The purpose of this warning is not to discourage you. What is being suggested here is before you start your project, and as you work on it, try to do two things. Try to keep it practical, because if it's not practical it probably won't get finished. And secondly know what you're doing. If you know how to use your tools the work will go much more efficiently. When a project is moving forward it helps motivate you to continue. If a project keeps running into delays because steps were skipped or a useful tip was ignored requiring a return to an earlier point in the project - this is what can kill a project. | ||
So from the start have a mindset of sticking to the important elements and trimming away the fluff. As you go through this process you should also take a look at the article [[Developing Successful Mods]] for help on making your new world space a successful project. | So from the start have a mindset of sticking to the important elements and trimming away the fluff. As you go through this process you should also take a look at the article [[Developing Successful Mods]] for help on making your new world space a successful project. | ||
==Essential Skills== | ==Essential Skills== |
Revision as of 17:48, 13 February 2011
Before You Begin
This article is written for those who are contemplating the creation of a large world space. If you're intending to create a world space smaller than one quad this article can still be helpful as a reference. This article contains valuable information for any sized world space project. However, with small world spaces certain steps in this article may not be necessary.
Direction
There are more than a few reasons to create a large world space. No matter what the reason or the size there is a basic suggested method to follow. These suggestions are not to hamper your creativity. They are here to help you get your mod done as efficiently and trouble free as possible. A world space mod should generally develop as follows: First, create the landmass for the world. Second, populate the world with generic objects that give your world a natural feel. Generic objects are trees, grass, and other plants as well as rocks and weather. Last comes the unique content that creates adventure in your world. These are npcs, monsters, animals, dungeons, activators, buildings, roads, fences, signs, quests, etc.
Practicality
Before starting your project consider the practicality of it. Take a moment and think over what you are hoping to achieve. Will you and/or your team be able to complete the project you're envisioning? Large world spaces require a lot of hours of work. The process of creating them can get very tedious at times. Unlike a basic quest mod that takes place in a vanilla world space, a large world space can require several weeks if not months of work and preparation before you can even start placing buildings, NPCs, dungeons, etc. To top all of this off large world spaces can take a very long time to load in the CS. If at all possible consider breaking your worldspace down into multiple plugins rather than creating the entire worldspace in one go. Waiting ten minutes or more for your world space to load in the CS can be very discouraging. Especially later on in your mod when debugging scripts causes the CS to crash frequently.
The purpose of this warning is not to discourage you. What is being suggested here is before you start your project, and as you work on it, try to do two things. Try to keep it practical, because if it's not practical it probably won't get finished. And secondly know what you're doing. If you know how to use your tools the work will go much more efficiently. When a project is moving forward it helps motivate you to continue. If a project keeps running into delays because steps were skipped or a useful tip was ignored requiring a return to an earlier point in the project - this is what can kill a project.
So from the start have a mindset of sticking to the important elements and trimming away the fluff. As you go through this process you should also take a look at the article Developing Successful Mods for help on making your new world space a successful project.
Essential Skills
This article assumes you have considerable experience working with world spaces and the CS. This article contains some very useful pointers in these areas, but if you've never used the CS before, or you've never worked within a world space you should attempt some of the tutorials listed before getting started on this project.
It is of course expected you have familiarized yourself with using both the Heightmap Editor and the Region Editor. If you haven't used these tools it is recommended you start a test world space and learn at least the basics of how to use them. This article contains some pointers on using them, but if you haven't used them before expect to do a lot of trial and error work at first.
Important references and tutorials:
- Heightmap Editing - Use this as a reference.
- Heightmap editor - A useful 'How To'. Written a little on the cautious side.
- Basic Landscaping Tutorial - Knowing how to use the landscape editor is required. Get started with this tutorial.
- Regions - You'll need this for a reference at the very least depending on how you decide to create your region data.
- New World Space and Region borders drawing- Brief example of what this article attempts to teach, but it focuses on small world spaces.
As has already been said time can make the difference between completing a project and abandoning it. Knowing the most efficient workflow can be a game saver.
It is very important for large world creation and editing to learn how to navigate with the landscape editor most efficiently. The method is contained in the points below.
- When using the landscape editor it is extremely helpful to arrange the cells by cell number in the Cell View Window. This makes it much easier to find a particular cell that needs correction or inspection. You do this by clicking on the header titled "Location" in the Cell View window. This will order the cells numerically so you can find cells most efficiently with the mouse wheel.
- Press 'A' to turn on enhanced lighting. This makes it easier to see what you're doing.
- Navigate the map from a bird's eye view using the arrow keys to move the camera when hunting for errors and making corrections instead of the mouse, spacebar, shift key, etc. Details:
1 - Start by pressing 'T' to get the camera oriented properly for using the arrow keys. The arrow keys do NOT work relative to the camera position. Rather the 'Up' arrow always moves the camera north, the 'Down' arrow always moves the camera South, etc. Pressing 'T' will orient the camera to a bird's eye view perspective where up will be North, down will be South, etc. This will make the arrow keys match the direction the camera is moving on-screen. You can press 'T' at any time to restore this position.
2 - After pressing 'T' to get the camera oriented properly use the mouse wheel to zoom out. Zoom out until you see the edge of the currently viewable cells. Navigating from this perspective will allow you to see errors and rips which will usually appear as purple just as long as the land is above water. Rips under water will require zooming in closer to find.
3 - Make the mental connection between Cell coordinates and how the coordinate system is related to the world you created in the heightmap editor. To do this start by finding Cell 0,0 in the landscape editor and loading it. Then follow steps 1 and 2 directly above to get the camera oriented properly. Now go to the heightmap editor and figure out where 0,0 is. Note how the Cell coordinates change on the heightmap editor as you go North, South, East, or West. You should be able to pick a cell from the heightmap editor and navigate to it manually in the landscape editor using only the arrow keys.
4 - Find errors in your landscape textures in the heightmap editor and then locate them in the landscape editor using the error keys. Correct them in the landscape editor using 'Soften Vertices' or 'Flatten Vertices' then save your corrections in the CS - BUT NOT IN THE HEIGHTMAP EDITOR.
5 - Avoid using the 'Shift' key and 'Space Bar' for navigating except when making corrections that would be difficult to make otherwise. Once these types of corrections are made press 'T' again to restore proper camera perspective and zoom out.
Notes
- When navigating with the landscape editor set your keyboard over to your left(if you're right handed) so that your left hand can easily work the arrow keys while your right hand works the mouse. Left handed folks won't need to do this.
Required Tools
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 (Wrye Bash also accepted)
- TES4Gecko - Needed to move world spaces, 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. TES4LODGen no longer uses VWD flags and ignores them completely.
TES4Gecko Notes
- In particular TES4Gecko can be tough to get working right with the shortcut, but the additional memory setup through this shortcut is NECESSARY for merging.
- TES4Gecko will work fine without the Shortcut on very small files. However, with large world space files the Shortcut is required.
- An example shortcut is included with the program. Consider making a copy of it before altering it so you can easily start fresh again if you have trouble getting it right the first time.
- After right clicking on the original shortcut select Properties. You want the Shortcut Tab.
- For a particularly long Pathname try typing it out in a text editor so you can see the whole thing at once and make sure you have formatted it correctly. Then copy and paste it into the appropriate location.
- For Windows 7 users you need to put quotes around the Path name to get TES4Gecko's shortcut to work properly. Example:
"C:\Program Files (x86)\Java\jre1.6.0_18\bin\javaw.exe" -Xmx1200m -jar "T:\(install_path)\TES4Gecko 15.2\TES4Gecko.jar"
- The above example is what you enter as the Target in Windows 7. And the example below is the portion you would use as the Start in: entry. Note the example below is the same as the latter portion you entered from the above example.
"T:\(install_path)\TES4Gecko 15.2\TES4Gecko.jar"
- The readme file included with TES4Gecko contains additional instructions. Also, if you have trouble you can always search the internet.
Ready to Go
With tools in hand and some practical experience with using them you are now ready to go.
In keeping with the suggested order of things as discussed at the start of this article a large world space mod begins with the creation of a landmass. This is done using the heightmap editor. The recommended way to do this is through a new plug in, i.e. a new .esp. Oblivion.esm is not needed at this point so it should not to be loaded. The reason for this is simple. Oblivion.esm requires RAM. Not having Oblivion.esm loaded means more RAM is available for the CS. This will help prevent crashes, and it will mean shorter load times when starting the CS.
Even if you have already started work on other aspects of your mod you will still want to start the new world space portion of your mod with a separate plugin. As you go through this article the reasons will probably become more obvious. If nothing else starting a new .esp decreases the chance of corrupting your previous work and vice versa.
Next you'll want to define your world space in the CS (World > World Spaces > New, give your new world space a name, and adjust the settings as desired within that window. You can change climate and water settings later. The map will come last. Now, before you open the heightmap editor save the mod again. Now if the CS crashes during your first session you will at least have your world space defined.
Heightmap Generation
Before you open the heightmap editor and start building your landmass a few things should be said about planning your terrain. This does not entail generating highly accurate elevation plans. This is about taking a practical look at the scale of your new world space and the way changes in terrain translate in the game world. In other words, mountains in the real world can be tens of thousands of feet higher than the foothills and plains surrounding them, but in the CS creating this difference in elevation isn't practical. Oblivion Units is a good place to start.
Another important piece of information to keep in mind as you plan is a quote from the Heightmap Editing article:
It's important to know how the height units in the heightmap editor relate to the actual terrain elevation when the map is saved to the plugin. Water level (defaults to z=0 in exterior cells) corresponds to z=4096 on the height map. Moreover, all differences from this value are doubled in the generated terrain. For example, z=4196 doesn't give a terrain height of 100, but 200 instead. Following this formula, the default height in the heightmap editor (3072) results in an ocean depth of -2048 units.
Accurate and detailed elevations in the heightmap editor are not necessary for good looking terrain. Generally, a guideline to follow is to keep your elevation changes within several hundred units for traversable terrain, and a thousand for impassable or nearly impassable terrain. Elevation changes greater than a few thousand do not translate in game well and will create rips (errors) in your heightmap texture.
You'll also want to have at this point a fairly detailed plan for your new world space terrain. You want to know where you will have plains and where you will have mountains. You want to know the general locations of rivers, lakes, and any other important landmarks. Again, you don't need to be too terribly accurate as you can probably adjust your content to match the results when the time comes.
A sketch of all these ideas should be generated in a graphics editing program such as the GIMP (although you can also do this on paper as well). A highly accurate scale is not as important as the idea of a proportional scale. The heightmap editor works in quads which are square in shape (again see Oblivion Units). You need to draw your landmass in GIMP in such a way that your final graphic can be divided up into squares. Using the heightmap editor you will manually transfer these squares into each of the quads you plan to use. This "translation" is going to be in some ways an artistic feat on your part and doesn't need to be mathematically perfect or in any particular file format. It is something for your eyes to look at and will act as a guide so you don't get lost as you work. This is especially important if your world space will be larger than 4 quads as you will see shortly.
Notes
- A simple conversion to remember is 32 units equals a yard. So divide by 32 and multiply by three to covert CS units to feet.
Using the Heightmap Editor Part 1
Before getting too specific on a good method for generating your landmass a number of important methods and notes are included below for review. Keeping these firmly in mind will help make your new world space creation happen as efficiently as possible. The following have taken several weeks of testing and trials to discover and were written here to save you a lot of time. Keeping these points in mind will help get your mod finished with the least amount of time and frustration.
The 4 Quad Rule
You should know by now the heightmap editor only shows 4 quads at a time. Experience has proven there is a reason for this - during heightmap generation you should only work on 4 quads at a time. If your world space will be larger than 4 quads blending between sets of quads will be necessary but will be done at a later point. The world space graphic you created should be used to plan your work so that you can match your heightmap elevations between these 4-quad work sessions. One way to do this is to take notes on edge elevations when your heightmap extends beyond the edge of the current workspace. This includes things like where rivers will meet up in bordering quads and where mountain ranges begin and end. Perfection is not required at this point as errors can easily be resolved at a later step. Try to balance the care you take in these early steps of landmass creation with the amount of convenience such care will provide when you make these corrections later. You can waste time trying to make it perfect at the start. But you can also waste time if you're sloppy and have to do a lot of work fixing things later.
Sharp Elevation Change Rule
The greatest number of errors (rips) on a texture are created in the hightmap editor where land is not properly blended before saving the texture. Any large, abrupt changes in elevation are prone to tearing. These are indicated by hard lines between two colors. There should be no hard lines left on your texture in the hightmap editor before you save it. Make sure all hard lines are blended with either the blending tool or the noise tool. Your finished work should look more like it was applied with a paint sprayer than a paint roller. A good exercise is to look at the Tamriel world space in the heightmap editor. When all is finished with your new world space they should share a lot of similarities. Much of that finished look is the result of using the noise tool.
The Edge Rule
In reference to the above rule tears can be prevented at the exterior perimeter of your New World by blending the last few cells into the water rather than having the land just suddenly stop and drop off. Blending can be done with the blending tool or with the noise tool depending on the terrain type you want at these locations. It is true that if your world space is 4 quads or less you can hide the edges by leaving a buffer between the edge of your quads and playable regions. However, when working on your world space with the landscape editor you will notice decreased performance as the Render Window tries to load terrain at the edges of your world where there are rips and other errors. Region generation will also produce errors at these locations. It is well worth your time to prevent and fix any errors that occur outside your playable world space. The best way to prevent these errors is to blend your edges in the heightmap editor. And when they do occur you should repair them with the landscape editor (more on this later).
Glitches in the CS
There is a known glitch in the heightmap editor where errors are created when you save your heightmap. A common location for errors to occur in the heightmap is at 0,0 as well as at the centers - like 32,32 -32,-32 64,64 etc. These errors can regenerate themselves repeatedly each time their heightmap area is saved. Correcting these errors will be described shortly. Just know this phenomenon happens and can not be prevented. Also understand it's a pretty minor thing to fix.
Cake Method
With a graphic representing your new world space in hand it's time to start creating the landmass. A safe and efficient way to build your landmass is to think of your terrain as a large traditional layered wedding cake. With this type of cake the layer on the bottom is the largest. As the cake rises higher the layers get smaller and smaller in area. The method is simple, straightforward, and gets the job done.
Working on your first quad you start by using the terrain raising tool, set its size to 150, and raise a patch of terrain anywhere in your workspace to use as a sample palette. Holding the mouse button down for a couple seconds should generate a spectrum of colors representing various elevations. Some will recommend changing the hight definitions of these colors. This isn't necessary using the cake method. Instead of focusing on color you will be focused on the 'Z' elevation value.
What your're looking for at first is an elevation slightly higher than the water - 4500 units or so will work perfectly. Using the Eyedropper tool hover over the color spectrum you created. You'll see the 'Z' value start to move up and down as you pass over the spectrum of colors. You want to get something close to 4500 units plus or minus a couple hundred. It really doesn't matter.
Once you get an acceptable elevation with the Eyedropper you can use the Paintbrush to spray out a swatch of color. Just spray enough out so you can sample it. You want to make sure the sample matches the elevation you thought you selected. It will rarely match exactly. If it's way off use the Eyedropper and try again.
Using the Flatten tool set to a size of 100 - 150, hover over the color swatch. Once you are sure the Flatten tool will utilize this elevation color use it to spread this color-elevation all over the four quad section. Only leave out areas where you intend to have bodies of water. If you have a specific size and shape for the body of water shrink the Flatten tool and work from both the water elevation as well as the first dry land elevation layer and sculpt the body of water and land until they are the shape you desire. If you plan on having 4-quad sections bordering this one you should shrink the Flatten tool diameter further and get the first elevation color as close to the edges of the perimeter as possible.
Repeat the above steps with the next elevation. Each later should be smaller in area than the one below it. How you build these layers up will depend what you want your final terrain to look like. If you want a rough and mountainous terrain you may only need to build up half your elevations with this method and then switch to the noise tool. If your world will be smooth and rolling you will want to build all your elevation with this method and finish by smoothing your work out with the Smudge tool. No matter how you plan to build your world make sure before you save your work in the heightmap editor that you reference and follow the rules mentioned at the top of this section to prevent errors.
After finishing work on your first 4 quad heightmap you should save your mod in the CS and follow the directions in the following two sections.
Converting Your ESP to an ESM
When working on large world spaces you should convert your .esp to an .esm regardless of how you intend to release your mod. There are two reasons for this:
- Due to limitations in the CS, and potentially your system, working on too many cells can lead to instability and frequent crashing. The more cells a world space has, the more the CS has to load into memory while you're working. 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 world space and plan to release an .esp, it is still suggested you use a .esm during creation so you can take advantage of the benefits this format offers.
- By using an .esm you always retain a backup of the world space at the last point of merging (more on merging in the next section). Your .esm file is after all just a series of .esp files merged together. So if you screw something up horribly while heightmapping, you don't have to start from scratch. This doesn't mean you shouldn't make backups of your .esm files. It's just a handy feature of .esm files.
Keep in mind that if your new world space project will make changes to a world space located within another .esm - like for example the vanilla Oblivion world spaces located in Oblivion.esm - those changes must be kept in an .esp file rather than an esm. Otherwise odd errors and undesirable behaviors will occur in the game. (Essentially, not following this guideline wipes out all non-persistent objects in the edited world space.) So, if your world space will be saved in an .esm file, and your mod will makes changes in a world space in another .esm, your mod will require a separate and additional .esp for any changes you intend to make to any .esm-based world spaces. An .esm CAN safely link to another .esm's interior cells, and it CAN include scripts to place objects/NPCs into another .esm's world space without using an .esp - as long as these changes do not actually make edits to the world space directly. Still to be safe you should try to make all these types of changes in an .esp that will remain an .esp at release time.
- Once you have trees and other content, you will also need to clear out all the VWD flags for your world space using TES4Edit in order for your world space 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. (Note: This final note has still not be verified in recent testing.)
Using the Heightmap Editor Part 2
For world spaces larger than 4 quads when blending the borders between 4-quad sections in the landscape editor it isn't necessary to to blend these perfectly to your finished specifications. Your only goal is to fix tears - i.e. the errors. Getting a good finished product can be just as time consuming or more in the landscape editor as it is in the heightmap editor - despite all of its seeming random error generation. Here is the suggested methodology:
1 - Design and finish the layout of 4 quads
2 - Save in the heightmap editor
3 - Make error corrections in the landscape editor, save in the CS, and create .esm with TES4Gecko
4 - Start new .esp and design/finish the layout of the next 4 quads
5 - Save in the heightmap editor
6 - Make error corrections in the landscape editor, save, and merge with your world space.esm
7 - Repeat above steps designing additional quads following this pattern and merge
8 - After all heightmaps are created and merged start a new esp
9 - Edit the borders in the heightmap. Multiple esps will be required for large worlds. Merge each "border-edit" esp with the esm as they are created. Also as you edit the borders scan the heightmap you're working on for errors and fix them as you go. These will appear as sharply contrasted squares/rectangles.
10 - After all borders are edited use the landscape editor to correct errors in conjunction with the heightmap editor. DO NOT make corrections with the heightmap editor at this time, and DO NOT save any more textures in the heightmap editor. At this time you will only use the heightmap editor for finding errors in your textures. Make the actual corrections using the landscape editor. Merge with the esm.
Notes
- Using the above methodology to create world spaces larger than 4 quads will eventually generate a great number of .esp files as well as .esm backups. It's a good idea to create a folder to hold all of your original .esp files as well as another to store your .esm backups. This will reduce the clutter in your Oblivion Data folder. Within your .esp folder it will also be a good idea to create separate folders to hold the different types of .esp files. Then if you need to backup to an earlier part of the creation process you will have multiple avenues to getting your world space to a previous point.
- It is also a good idea to number the .esp files you merge as you create them. For example: MyWorld_Heightmap_Part1.esp, MyWorld_Heightmap_Part2.esp etc. You can do the same thing for your heightmap blending files and region generation files.
Testing the New world space
When first testing your new world space.esm you should always have it loaded in the 01 Mod Index - in other words directly after oblivion.esm. If you don't know how to do this you should take a few moments and read up on Oblivion Mod Manager or Wrye Bash and learn how to manage your load order.
The reason you do this is because for one, other mods may interfere with your new world space.esm. These problems are rooted in some common issues that have a relatively easy fix. Since it's likely that placing your world space.esm in the 01 Mod Index will interfere with other mods you should employ the simplest temporary fix for the purpose of testing and have only oblivion.esm and your world space.esm active. Start a new game with a new character for testing and then "cheat" your way into your world space. There are several ways to do this. See below for two methods.
Method 1: Create an Exploration Plugin
Create a door in the Imperial Prison cell where you start the vanilla game. Set the door up so it teleports you to a door in your new world space. Just make sure you never merge this .esp file with your esm. It might also be handy to drop a horse in your new world space using this same temporary plugin so you have something to explore the terrain with. Make sure you give ownership to the Player so the horse doesn't run off when you dismount. Keeping this plugin handy can also help when testing regions later in this article. You can move your door and horse to various locations around your world space as you generate your region test areas.
Method 2: Use the Console
Open the console (~) while in the game.
Type: COW Myworld space 0,0
Replace 0,0 with whatever cell location you want to visit.
Replace Myworld space with the ID of your world space.
Distant LOD Issues
This is a quick explanation of the "problems" mentioned in the above section Testing the New world space. This information has been inserted here to help you understand the "problem" so you can find the solution later when you start creating the DistantLOD for your world space. This was taken from the Landscape LOD Tutorial.
If your distant LOD land does not show up, it is recommended that you use TES4Gecko to add your world space to the Master Index, which will make it appear in the game regardless of other moderations and regardless of load order.
To do this: Download TES4Gecko (http://www.tesnexus.com/downloads/file.php?id=8665)
Install TES4Gecko according to the instructions included with it.
Once you start TES4Gecko, go to the "Move world spaces" function.
Then select the .esp that contains your world space.
This will edit your .esp so that the game sees your landscapes as part of the original game rather than as a moderation. It also changes the names of the files in \meshes\landscape\lod and \textures\landscapelod\generated to match the changes made to the .esp.
Region Generation
Before doing region generation make a backup of your new world space .esm file. Before starting you should have all the terrain you planned to use merged with the newworld.esm. To create regions you're going to need data from from Oblivion.esm. So from this point on you will need to have Oblivion.esm loaded as well as your new world space .esm file.
There are at least two methods for creating regions. One is to start from scratch. The other is to use existing regions from Oblivion and edit them to your liking. In fact, some regions in the Oblivion world space may be exactly what you're looking for and require no editing at all. Keep this in mind since using existing region content can save you a lot of time.
How To Re-Use Existing Regions
1 - Open the Region Editor
2 - Below the words Region Editor you'll see a select box for the current world spaces.
3 - Select Tamriel. The fastest way to get to Tamriel is to click on the selection box and press 'T'. This will show you a list of Regions used in the Tamriel world space.
4 - Click on a region name in the list and find it on the region map. You may need to navigate around the map to find where the corresponding region was used. Just hover your cursor over the map and press and hold the space bar while using the mouse to move the map around. Also use the mouse wheel to zoom out. The corresponding region will have a region border around it - a dark red line outlining where the region data has been applied.
5 - Right-click on the region map within the region border and click on 'View World Here' in the pop-up. This will show you what effect the Region Data had on Tamriel in the Render Window.
6 - If you like the region right-click on it in the list on the left and select 'Create Data Copy'. The copy is created at the bottom of the list and given a generic name that includes a number. Select this Region in the list and give it a new name on the right under the 'General' tab.
7 - Now find your world space in the select list. You will see your copied regions there. Once you apply a region to a world space it will no longer appear under all world space region lists - just the world space where you used it. You may repeat these steps above as many times as you need to borrow region data from Tamriel and other world spaces.
Create Your Regions from Scratch
See the topic Regions for more on creating Regions from scratch.
Notes
- For either custom or recycled regions you should consider doing 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 world space 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.
- It can take a great deal of time to generate regions. You will get "Not Responding" messages for the CS while generating regions. Note that these are different than crashes. In Windows 7 when the CS crashes all CS windows become highlighted and a warning box pops up. However, when the CS is terribly busy you will see Not Responding messages at the top of the CS window. One way to check to see if the CS is locked up or not during a Not Responding message is to open the Windows Task Manager and check to see if the CS is still using CPU cycles and to see if the amount of memory it is using is still climbing (keep in mind memory use will climb very slowly). With a quad core Intel i7 at 2.6 GHz 12 - 13% of CPU is used and several Kilobytes of data are added every few seconds.
- All of this merging of files will cause your world space.esm file to grow significantly. Don't be surprised if loading your .esm in the CS starts taking a long time. This is normal.
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 haven'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 each other 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 world space 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 world space simply because I had to figure out most of this stuff and deal with crashes when the CS ran out of memory). For larger world spaces, 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 (Optional)
Often overlooked is the purpose of using dummy terrain instead of just making your world space 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 world space, 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 world space 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 "Myworld spaceTerrainDummyEast.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 world space 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 world space 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 world space. 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 world space. 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 in-game, 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 world space 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 in case 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 world spaces within a non-playable parent world space, as a means of unifying them all together, but this can become rather difficult to manage.