Difference between revisions of "Creating Large Worldspaces"
m
→Converting Your ESP to an ESM: Spelling correction
imported>Bruneauinfo (→Ready to Go: adding more content. more to come.) |
imported>Syscrusher m (→Converting Your ESP to an ESM: Spelling correction) |
||
| (6 intermediate revisions by one other user not shown) | |||
| 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== | ||
| Line 82: | Line 82: | ||
With tools in hand and some practical experience with using them you are now 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 [[Glossary#E|.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. | 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 [[Glossary#E|.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 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. | 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. | 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. | ||
| Line 96: | Line 96: | ||
''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.'' | ''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 | 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===== | =====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. | *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==== | ====Converting Your ESP to an ESM==== | ||
| Line 133: | Line 153: | ||
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. | 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 | *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 been verified in recent testing.) | ||
====Using the Heightmap Editor Part 2==== | ====Using the Heightmap Editor Part 2==== | ||