[Released]Terrain Slicing Neighboring Kit

This thread is no longer used, please use this thread if you have any questions or want the latest updated information on the Terrain Slicing & Neighboring Kit

 

Can u explain the benefit of slicing?

 

Mobile / streaming.

 

This sounds absolutely fantastic. Good job. I'll end up using this.

 

There are a couple of benefits I can think of, and as RazorCut noted, streaming is one of them. If you want to stream terrains, you of course will need separate terrains. The issue most people run into is with this is that it's a challenge to create individual terrains that fit together perfectly, so there are no visible seems along terrain edges. This is where the slicing tool comes in. Instead of creating separate terrain pieces and stitching them together, or using some other method for making the edges match up, you can simply create a single terrain and then split it up into smaller pieces. The smaller pieces are simply replicas of a portion of the original terrain, so the edges match up exactly.

I would think normally if you were creating multiple terrains that fit together, you might be limited in the tools you can use to shape these terrains, as too much variation might make it impossible to match edges up. For instance, I would find it incredibly difficult to use the Terrain Toolkit found at http://unity3d.com/support/old-resources/unity-extensions/terrain-toolkit to shape 4 different terrains individually in a way that would allow them to stitch together or match up. With the slicing tool, however, you just have to use the toolkit (or other terrain tool) once on your base terrain, allowing you to abuse the tool to your hearts desire. The resulting terrain slices after slicing will still match the original terrain, no matter what it looks like.

Finally, using the slicing tool will enable you to create semi-different SplatMaps for the individual terrain pieces. Just limit your original terrains SplatMap to less than 4 textures, and after slicing each terrain will have slots open to add more textures. So for instance if you have two textures on your original terrain, each slice will have 2 texture slots open for their SplatMap. Of course, you will need to avoid painting the terrain edges, as it will make where the edges are obvious.

There are additional benefits I'm sure I'm forgetting/missing. I am by no means a pro at this Unity thing.

 

FYI, I have created a tutorial video showing how to use the slicing tool. This should have the added benefit of showing that the tool does indeed work (haha). Feel free to ask away if you have any other questions or concerns.

The video can be found at this link: http://www.youtube.com/watch?v=dGgYCED80ZU.

I plan on doing a similar video for the neighboring tool.

In addition, I have resubmitted the toolkit from Unity 3.5, so the requirement should be lowered as soon as the asset people approve the update. Unfortunately I had to comment out two lines of code referring to the Terrain member 'materialTemplate," since terrain materials were only introduced in Unity 4.0. All the guides provide instructions for finding these lines of code so 4.0 + users can uncomment the code. Strictly speaking, if you don't use terrain materials then there shouldn't need to uncomment the lines, but I still recommend doing so in case you use them in the future.

Thank you Razor for the endorsement! If you do end up buying the kit, it would be awesome if you could add a review on the asset store (that's if you like it ). If you don't (which means you're having some sort of trouble), don't hesitate to contact me via these forums. I don't foresee anyone running into any trouble, but you never know.

Finally, a quick reminder: You can find all of the instructional guides on my website here.

 

Just to clarify...the terrain geometry will be seamless, but the splats/textures will still show borders since they can't read between terrain splats to blend, is that correct?

 

At first I wanted to say that no,that is not correct; Splatmap/textures will blend together. But after further testing it does appear that you are correct with your statement, at least most of the time.

The edges between splat maps will become more evident with smaller control texture resolutions (or conversely larger terrain sizes). Using more textures on your base terrains splat map will also make edges more evident. Finally, dividing your base terrain into more slices (producing 16 vs 4 slices, for instance), will also make edges more evident, since the resulting terrain slices will by necessity have smaller control texture resolutions.

If you use a large control texture resolution and minimize the number of textures used in your base terrains splat map, often times the edges will not be visible (which is how I missed this problem to being with!).

If you do notice edges, you can delete the terrain slices and manually paint your base terrain at the trouble spots, so that only one or two textures are being used on that area (which will eliminate the blending Unity does). Then re-slice, and check if the edges have disappeared.

 

Okay, a quick update:

I think I may have thought of a solution to the alphamap/splatmap blending problem. I have tested this on a pretty basic terrain with a control texture resolution of 32, and it seems to work.

​

If the darker green box on the left represents the last splat map square on one terrains alpha map, and the lighter green square represents the first splat map square on a terrain sitting next to the first terrain, I have found that setting these two values to use the same values makes their blending the same, and thus it flows together and produces no visible seem between the two.

Unfortunately for this to work I'll have to find the average between the two squares (or four squares for terrain corners where four terrains meet), and replace each square with this new average, which means part of the base terrain is changing. My guess is that this change will be very small and hopefully not very noticeable.

I still have yet to test this on a more complex terrain, but as soon as I do so I'll let you know how it's working.

 

Aha, I think I've got it! I'm going to conduct some further testing, but for now it seems as though this new script I wrote works. It'll be added as an option to the slicing tool, as well as a standalone script in case you want to blend terrains you've created yourself.

Here's two pictures showing four terrain pieces along their edges before and after blending.

​

 

Very nice!

 

Another update : After conducting some more testing I found another issue with the slicing tool. In my testing, I consistently used a solid color as my terrain textures, which led me to miss a problem that arises when using a non solid texture, for instance, a texture which is suppose to represent pebbles and has small circles on it for this reason. Each terrain's texture has a tileSize (x and y) and tileOffset (x and y).

If your terrain width is 1000 and you set your texture tileSize to 200, this means the texture will be huge and repeat only 5 times across the terrain, sort of like this: <><><><><>. If we want to cut this terrain in half, we want the two new terrains to have a texture pattern like this:
1st terrain: <><>< ><><> - 2nd Terrain, so the two terrains side by side look the same as the base terrain <><><><><>.

However, currently each terrains texture map simply starts over at the beginning, so our two terrains look like this:
1st terrain: <><>< <><>< - Second Terrain, and the two together look like <><><<><><.

Luckily, I have already found and implemented the solution, which is simply to offset all the terrains' textures (except the first) by a certain amount, based upon the base terrains tileSize, the new terrain slices width/height and where the terrain slice lies on the output grid.

So have no worries if you decide to purchase the kit and find your terrains not fitting together as nicely as you hoped. I will be updating the kit within the next few days (will be v 1.2) with this fix (as well as the blending option/tool mentioned previously). Judging by how long my latest update is taking to be approved by the Asset Store people, it will probably be a week or two before v 1.2 is live.

As you can probably tell, I'm no good at testing. At the start, I wasn't really a terrain expert (though I'm slowly becoming one I fear! Haha), so there are things I just didn't think of to test. Hopefully you guys can see how quick I am to identify something as an issue and think up and impalement a solution!

 

Another update, for anyone who cares! I'm continuing the testing process to try and make sure there are no more issues before releasing v 1.2, like there have been for the initial release. Remember, you can contact me for solutions to the known issues if you can't wait for v 1.2 to be released.

I've also introduced a new feature (nothing too exciting). Currently the slicing tool takes all the tree prototypes and copies every single one of them to each new terrain slice, regardless of whether that slice actually has a tree painted on it. I haven't removed that functionality; instead, now you will be given a choice of whether you ONLY want to copy the prototypes to a terrain slice if that slice has the tree painted on it. That way, even if you have 15 tree prototypes on your base terrain, if you only use one of them on the section that will become your first slice, only that one prototype will be transferred to the new slice. Basically it'll reduce memory usage (which I doubt is that big of a deal), and make the prototype list for each slice smaller and thus easier to navigate.

That functionality has been added already. I plan on doing the same for detail meshes tomorrow.

In addition, I have improved the look and functionality of the slicing editor window. New tooltips have been added to each menu option, and they are very descriptive (they appear when you hover over a menu option's label). My hope is that these tooltips will be descriptive enough that you can use the slicing tool without having to look in the instructional guides.

Here's a picture of the new window with a sample tooltip.

​

 

Hi guys, I have created a little demo. It's just a scene with a base terrain and 4 terrain slices. You can move each of the terrains up and down, which will allow you to compare the original terrain with the terrain slices (includes trees and grass so you can compare those too).

If you purchase the kit, you will not see results as good as this demo showcase, simply because the demo includes the blending and tiling fixes mentioned in my previous post, which have not been updated to the Unity Asset store yet. You can always contact me and I'll provide you with the fixes though!

The demos are in the form of a Windows and Mac standalone build. The webplayer build was incredibly large, which is why I didn't use it.

Here's the Windows Demo
Here's the Mac Demo

 

V 1.2 has been submitted. v 1.1 still hasn't been approved, so it'll probably be a week or two before 1.2 is available. You can see my new logo design at the top of this page. What do you think?

 

I'm happy to report that v 1.2 have been approved, and the updated version of the kit is now available on the Asset Store.

This version has several fixes and updates.

1) Unity version requirement lowered from 4 to 3.5. Unity 4.x.x users will need to perform a couple of easy task to enable certain functionality (see below).

2) Visible seems between terrain slices due to incorrect handling of texture tiling has been fixed.

3) Visible seems between terrain slices due to incorrect handling of Unity's automatic alphamap blending has been fixed. Or I should say, it can be fixed if you select the option in the slicing window. In virtually all cases you'll want to use this option (It's called "Blend Alphamap Edges" in the window), but because it makes some small changes to the look of your terrain, I put it in as an option so it'll be your choice. I promise, the changes are hardly noticeable. There's a post on this page where I discuss this more thoroughly.

4) Changed layout of slicing tool, and added tooltips to increase ease of use.

5) New SliceTerrain.txt file added that has functionality for 4.x.x users. They simply have to delete the current SliceTerrain.js file and open/re-save the SliceTerrain.txt file as SliceTerrain.js. New .txt file added informing 4.x.x users what they have to do. New instructional guides added for using blending tool.

6) Added a new blending tool. This can be selected from the Terrain menu at the top of Unity. It uses the same Auto Fill algorithm as the SetNeighbors/SetNeighborsEdtior scripts so you can select a large group of terrains with minimal effort. Using the tool is exactly like using the SetNeighbors script, except you'll have to select the first terrain in your terrain group (since this script isn't dragged onto the first terrain like the SetNeighbors script). The blending itself is the same blending that has been added as an option to the slicing tool.

The use of this tool is two fold. If you want to try and slice a terrain without blending, you can do so, and if you don't like the results (you can see visible seems between terrains), you can then use the Blending tool to blend the terrain slices.

Secondly, you can use this tool on terrains not created with the slicing tool. Keep in mind, however, that for the blending to work, all of the terrains you wish to blend must have the same control texture resolution, and use the same splat map(s). This means the textures on the splat map must appear in the same order under "Paint Textures" for each terrain. This is automatically the case for terrain slices.

Enjoy!

 

In case anyone is wondering about future updates to this kit, here's some news.

I've designed a nifty little editor tool that makes making prefabs really easy. I designed this primarily for the terrain slices created after slicing a terrain. You'll be able to use an Auto Fill button to select all the terrain slices easily, like in the SetNeighbors and BlendEdges scripts. The prefabs will be created in a Resources folder, but you can obviously move them afterwards.

I made sure the script works with non terrain objects (or terrain objects not part of a terrain group) also. When you open the CreatePrefab window, there's an option (Is Terrain Group) you can deselect if the objects are not part of a terrain group. When this option is deselected, the window will change to work better with objects.

​

The main difference is the "Auto Fill . . ." button is replaced by a "Fill From Selections" button. Simply select objects from your scene and click this button to have them magically appear in the fields below the button. The number of fields will expand/shrink automatically to reflect however many objects you have selected.

The reason I created this tool has to do with my next update.

I'm currently working on a dynamic terrain loading system that is based around loading terrain prefabs from either the Resources folder or an asset bundle. The CreatePrefab tool was designed with this purpose in mind.

The script will have you select which method to use (load from resources or asset bundle). I'm hoping to allow you to have unusual terrain configurations, for instance if you have a 4x4 grid with 16 possible terrains, you won't necessarily have to fill each spot with a terrain. You might have 4 empty spots in the middle, like this for instance:

xxxx
xoox
xoox
xxxx

where the o's are empty areas and the x's are terrains.

Once I finish these two systems I'll update the kit. The second system might take a week or two, so I'm thinking of just updating the kit with the CreatePrefab tool immediately.

Enjoy!

 

would it be possible to cut terrain it into thin strips and edit in order to use with a 2D game, some thing like this:

http://forum.unity3d.com/threads/99072-E2D-free-2D-terrain-editor-and-generator

 

I'm not 100% sure what you want to achieve, so please let me know if the following doesn't fully address your question.

You can certainly cut a terrain into thin strips, but I'm not sure you will be able to edit them like you want. Let's talk about creating thin strips first, however.

Start by creating a terrain that is long in the x direction but short in the z direction, i.e., one with a large width but small length in the Set Resolution window.

Something like this:

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Then slice it by however many strips you need, i.e., 2x2 for 2 strips, 4x4 for 4, etc. This will leave you with something like this:
xxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxx (the space between slices won't be there in the actual Unity scene)

It sounds like you will only need the slices on the bottom row for a 2d game, and these slices will always end with _1_x (where x is the slices column). So just delete all the terrains that don't have this ending, and you should have the thin slices you want.

Now for the editing part. You can only edit these terrain slices in the same way as you edit other terrain. Therefore, you won't be able to create upside down terrains like with that other tool you linked. Second, if you edit the edge of a terrain slice, it will no longer match up perfectly with the slice next to it, so I recommend doing all your editing on your base terrain before slicing.

I'd recommend creating a terrain yourself and getting it to look like however you want your game to look. If you're successful, then this slicing kit might be able to help you. I can't say for sure, as I'm not really positive what your goal is.

If you'd like to provide some more details on what you're trying to achieve, I can hopefully provide you with a more clear-cut answer on whether this tool can help you.

Also, I see the tool you linked is free, so can I ask why you don't want to use it to create your 2d game?

Thanks for your interest!

 

Thank you for such a detailed reply!!, I'm not sure about the free E2D tool, it is very limited and specific however i am interested in this tool. I may have to purchase it, it seems like a pretty useful tool that might come in handy later!

 

After seeing this and watching the video, it's definitely an asset worth investing in. It's such a pain to have fluid terrain that doesn't coincide with existing terrain from previous areas. It will certainly save me time and extend my patience when working with this addition. Thanks very muchly.

A question: will this work with submerged terrain? and water surfaces?

 

Heh, I certainly believe it's handy! I'm also working on extending the kit by adding some scripts that will allow you to dynamically load terrains based on the players position. It's geared more towards 3d games, but it could easily be adjusted to work with 2d games as well.

See the post a couple post up to read more about this.

Please let me know if you have any more questions. The last thing I want is for someone to purchase the kit thinking it will do something it won't!

 

What is a submerged terrain? A terrain with a water mesh over it? If so, then there shouldn't be a problem. If regular terrains work with whatever you're doing, then the slices should work too. They are, after all, just regular terrains themselves. Also, they are created in the same place as your base terrain, so all your game objects/water/etc. will appear on the new slices in the correct spot. I intentionally leave the original terrain intact after slicing in case you want to go back and change something and then re-slice. I recommend saving this terrain as a prefab, so you can have a backup if you need it later for some reason.

 

A little update:

I've made progress on adding dynamic terrain loading. So far there are two options for loading the terrains. The first involves keeping prefabs of each terrain slice in the resources folder, and then using Resources.Load and Instantiate to load the terrain into the game.

The second involves creating individual scenes for each terrain and then loading them using LoadLevelAdditiveAsync. Both methods cause a slight hitch in game play. I expected this from the Instantiate method, but was hoping the Async method would not present this problem. I'm not sure if it has to do with the terrains being in view of the camera when they're loaded. I believe it has to do with Terrain Culling. Obviously further testing is needed (I have tried decreasing the backgroundloading priority for the async thread to no avail). I also plan on implementing www streaming with asset bundles.

As for the dynamic loading script itself, I've built in what I believe to be a nice level of control for the game designer. Rather than implement the usual system where the terrain the player is on is loaded in addition to the surrounding 8 terrains, I've created a more comprehensive system that offers a finer level of control.

You basically have two variables you get to set to control the loading behavior. The first is known as the inner grid, and defines the number of terrains that will server as a sort of "safe area." Combined, these terrains form a square boundary along their outer edges. As long as the player remains within the boundary, no new terrains will be loaded. By increasing the number of terrains in the inner grid, you increase the size of this safe area.

The second variable is the outer ring width, and defines how many terrains surround the inner grid. Combined, these two values allow you to control the max number of terrains that are loaded at a single time (the loading square). For example, a inner grid of 2x2 and an outer ring width of 1 would look like this:

x = outer ring terrains ---- o = inner grid terrains
x x x x
x o o x
x o o x
x x x x = 16 terrains loaded at a time (at most - sometimes it might be less if your on an edge)

You can move between the o terrains without forcing any additional loading.

You can still do the usual 1 inner grid, 1 outer ring width for this shape:
x x x
x o x
x x x = 9 terrains

My main problem with this method is if the player moves across a terrain boundary, loading will occur. If they then move back the other way across the boundary, loading will occur again. By using an inner grid size of 2, this can't happen.

The boundary is in reality a Vector4, storing a position in the game world. For example, one of the values might store the minimum X boundary of 200. The program compares the player's position with this number, and in the case of the minimum X boundary, if the player's x position is less than 200, the program will know the player has crossed the boundary, and loading needs to occur. When loading occurs, the loading square is shifted up/down or left/right depending on which boundary was crossed. Terrains are removed/added as needed, and the boundary is shifted properly.

The player's position and some other information is saved in PlayerPrefs, which enables the game world and player to appear as they did in their last game session.

 

In case anyone is interested in the dynamic loading script I'm working on, I'd like to ask you what features you expect/want from such a tool. Hopefully you all will have some ideas I haven't thought of, and this way I can work to ensure the script is as robust as possible before release.

Thanks!

 

i'm definitely interested - just found your tool today, looks very promising. so is the idea that we would have a single 'master' terrain that we'd work on for our entire world, and then the slicer would chop it for loading into the actual game scenes?

if so, would be nice if we could have it automatically chop the terrain at 'x' size, and then have some kind of manager script that we can define a stream threshold that would be used to trigger the loading of the next zone. this way the terrain loading / unloading would be handled behind the scenes, and all we need to worry about is moving the camera and game objects (characters etc) accordingly.

have you thought of things like resetting the overall world position at when a new terrain chunk is streamed in as well? for larger terrains this would be necessary - basically resetting everything back to 0,0,0 periodically so that you don't suffer from floating point errors, etc...

for placed / custom objects that are on the terrain, there could be some kind of parenting system that designers can use to parent their custom objects to a specific 'tile' of the terrain, and if a sub-terrain slice isn't visible / loaded, it would automatically cull and/or reposition the sub-objects as well...

could be very useful indeed.

cheers,
mike w

 

Yes, that's the idea. Unfortunately, this is not ideal for extremely large worlds, as the largest height map you can have is 2049, and when the terrain is extremely large, things don't always look great. I've noticed a diamond patter on the terrain, for instance. You could always make multiple terrains and then stitch them together before slicing each individually. I am contemplating adding a script which would do this, though I know there is already one out there for $5.

I am not sure if I catch you're meaning. Do you mean you'd like to specify the resulting slices size? If so, then you can do this by planning ahead. If you want your slices to be 1000 (x axis) x 500 (z axis), you could build a massive terrain that is 8000 x 4000 and then perform a 8x8 slice. Unfortunately all terrain slices must be the same size, because (as far as I'm aware) the resolutions must be square (same along x and z axis) and a power of 2 (or 2 plus 1 for height maps). Thus you can only divide a terrain by the same amount along the x and z axis (2 x 2, 4 x 4, etc), and the division factor must be a power of two itself.

Perhaps that's not what you meant, though. Please let me know!

Again, I'm going to guess at what you mean; please let me know if I'm wrong! You want to define a threshold on the world, that when passed by the player, triggers loading of the next world?

If so, this is how it works in the script I'm currently working on, except the threshold can't explicitly be set by the player. How it works is you define an inner matrix of terrains, which together form a rectangle. The edge of this rectangle (the outermost edges of the terrains) serve as the threshold. This matrix can be a single terrain, or any square combination (2 x 2, 3 x 3, etc.). As long as you stay within the bounds of the matrix, the player won't trigger any loading, but if they past the right boundary, new terrains will be loaded on the right and the terrains on the far left will be destroyed; if they go left of the left boundary, new terrains will be loaded to the left and the terrains on the far right will be destroyed, etc. Obviously the boundary is then recalculated when this occurs.

In addition to this inner matrix, there is an outer ring of terrains that surrounds it. Like this:
xxxx
xoox
xoox
xxxx

Where the x's are terrains on the outer ring and the o's are the inner matrix terrains. This outer ring can be 1 terrain wide or more depending on your preference. Unfortunately the larger your inner matrix and outer ring width, the more terrains have to be loaded at the same time. For instance, 2x2 inner matrix with an outer ring width of 1 would result in 16 terrains being loaded at the same time (at max, sometimes less terrains will be loaded if the player is close to the world edge).

As for the behind the scenes bit, I think that's how my script is working. The setup is very minimal, and all you need to is set your player/camera up wherever you want them to start, and the world is loaded correctly around them the first time. Their position and some other info is also stored in PlayerPrefs so when they exit and then re-enter the game, the world appears the same as they left it.

I had not thought of that. I didn't realize there was an issue with floating point errors. I will look into how hard it would be to add this functionality. Currently the location of where terrains are loaded is stored in the prefabs themselves, but I think I could change this easily enough. Thanks for bringing that issue up!

I haven't gotten around to testing this, but I think you could already do this. All the loading/instantiating (you get to choose which method you want to use) is done on GameObjects rather than Terrains, so theoretically you should be able to load as many objects as you want as long as their attached to the same GameObject. I would recommend just attaching them all to your terrain instead of an empty parent gameObject, but if you wanted to use an empty GameObject you could, as long as the GameObject is named the same as your terrain.

Of course, this will only work if you don't care about having your gameobjects destroyed/re-loaded, which might not be the case. For gameObjects that you don't want to be destroyed, I will look to adding a method for that as well.

I plan on making a complimentary script that will receive communication from the master script. This complimentary script will keep track of which terrains are currently loaded, and will be updated whenever new terrains are loaded/destroyed, i.e., when the player crosses a boundary. The complimentary script should enable you to add whatever additional functionality you want.

Actually, now that I think of it, it really wouldn't be very hard to add to this script and make a system that culls/re-positions a set of gameObjects based on which terrains are loaded.

Hopefully that address all of your questions/concerns/ideas. If not, let me know. You've certainly given me more to think about!

cheers,
mike w[/QUOTE]

 

Another short update . . .

I believe I can get the dynamic loading/paging system done by the end of the week. When I decided to implement an endless world type solution, I made the decision to ensure that anyone using the terrain slicing tool would be able to easily ensure their terrains would be seamless. This meant designing a script that adjusts the terrain edges of a single terrain so that when the terrain is repeated, there are no visible seems. I like where I'm at with this script, but there are still a few kink that need to be worked out.

There will be things left out of the first installment of the paging system, but I will of course continue to work on it even after release.

Just a heads up for anyone following things. Since there was considerable work and effort put into this paging system, and because I feel it adds quite a bit, I am planning on increasing the price for the kit to $10. So if you're interested in the slicing tool or new paging system, you can spring now for the kit for only $5, and you'll obviously get all the updates once they're released.

I'll make a new video for the paging system once I've finished it.

As always, feel free to contact me here or via email if you have any questions!

 

I've completed the endless terrain portion of the script, and thought it would be a good time to make a video showing the script in action. This iteration uses LoadLevelAdditiveAsync to load the terrains. I do plan on introducing world resets to avoid floating point errors when the player moves too far from the origin at 0,0,0. This resetting will be optional, however.

The world in the video is pretty small. It's a 2000x2000 world broken down into a 4x4 terrain grid (so each terrain slice is 500x500). Obviously you'd want to use a much bigger world in your game, so the player doesn't see the terrains being loaded.

Anyways, here's the video : https://www.youtube.com/watch?v=nvoG9Ti2Avc

 

i just brought ur tool
but blendedfes and setneighbors not work
show error
can
update this tutorial in youtube?
not slice is blend
i want blend two terrain in one

 

Hi uncle TIN, I will be glad to help, but first I need to understand exactly what problem you're having.

Could you try again in different words to tell me your problem? Just guessing, but it sounds like you want to take two different terrains and blend them together? The blending tool currently available in the kit is meant to blend the alpha maps only. It will not alter the height map (the actual geometry of the terrain) of each terrain so they match. There is another stitching tool made by someone else if you want that; or you can wait until I release my own stitching solution (which is not guaranteed at this point, but will be added to kit if I do decide to make one).

If that did not address your problem, please refer to this page : http://deepspacelabs.net/terrain_slicing.html

You will find a list of documents on that page, one of which refers to blending and one of which refers to the set Neighbors script. Please read through those and see if you can find a solution to your problem. Note that you will need to either a .doc reader or PDF reader to read those documents.

Also, could you please post the error that Unity is giving you when you try to use these scripts? That will help me troubleshoot the issue you're facing.

Thanks,

Kyle

 

I've added another video to YouTube, showcasing an endless world where the terrains are loaded via the Instantiate Method. This video also shows off the handy resetting option which you can use (or not). If you're using an endless world, I recommend using the reset option, as eventually the floating point numbers will get too large as the player moves away from the origin.

There are two reset methods available. Reset to origin simply moves the terrain the player is on when they cross the limit (which is specified by you, the developer) back to the origin. For example, if the limit is 2000, and the player moves in the positive X direction past this line, the entire world and player are moved in the negative X direction so that the terrain the player is on is at 0 position (along the x axis : the world is only moved in the Z direction when the player moves too far north/south). So far the move hasn't been noticeable, but I still need to test this with more complex terrains. Also keep in mind that this reset method can also be used with a fixed (non-endless) world.

The second method simply resets the terrain the player is on to its original x position or z position when the limit is crossed, and then moves the rest of the world and player that same amount. I'm honestly not positive why you'd choose this method over the reset to origin method. I guess it's useful to know that each terrain will appear only in certain spots. Also note that this method is only useful for endless terrains. On a fixed terrain, each terrain is already located on its original position, so resetting it will have no effect.

As always, I will respond to questions/concerns, and if you don't want to ask something here, please contact me at kgillen@deepspacelabs.net.

Video Link Here

 

Time for another update . . .

I keep saying this thing is going to be done by the end of the week, but then that doesn't happen. I have been sidetracked by a couple of things. For instance, a customer asked for some help creating a specialized tool that would allow you to cut out portions of a terrain to create smaller sub terrains. I am happy to say I was able to complete this, and have decided to add it to the kit when I update it next. It has some limitations, for instance the largest size you can cut is 1/2 the width of your base terrain x 1/2 the length, while the smallest is dependent on your resolution data.

These limitations are unavoidable, but I still think the tool is pretty handy. I'll provide a picture in another post of what it looks like in action.

I also made this nifty little tool that when added to a terrain, shows the detail patches. This has to do with the detail resolution and detail resolution per patch values in the "Set Resolution" settings for a terrain. Basically the resolution/resolution per patch = number of patches on each terrain axis, and the total number of patches is equal to # on x axis * # on z axis. By using this tool you can get a visual clue of which patches your meshes are contained in.

This could be useful if you had say, two rocks side by side on the edge of a patch, so one rock is in one patch and the other rock is in another patch. Because they're in separate patches, they'll result in separate draw calls. In this case, you could perhaps move one of the rocks over to the other patch and only have the rocks use one draw call. I'm sure there are other ways it could be useful as well.

In addition to these two tools, I have been doing some testing on the Dynamic Loading Scripts (Instantiate and Load from Scenes via LoadLevelAdditiveAsync), in order to optimize their performance as much as possible. I decided to use a level that was pre-built and had good performance, something you could expect to find in a game, so I grabbed the Island Demo and conducted some testing on it. I am happy to say I noticed no visible lag with either loading methods.

I am still unsure about one thing, and perhaps I could get some advice on this.

There are two methods on the async loading method I can use when actually loading the levels. The first is to load a level, wait for it's background loading to complete, and then begin loading the next level. The second method is to queue up all levels for loading, and then wait for them all to complete before proceeding (with the loading code that is . . . yield async is used so your other scripts continue running while the levels are loading -- this is a pro only feature).

The first method is slower and results in steady spikes in frame completion time (not enough to cause lag), every 4-5 frames, while the second method is faster but results in several spikes in frame completion time in a quick span (say 5 frames).

The spikes in frame completion time are the same for both methods, it is merely a difference between single frame spikes every 4-5 frames over a longer time period, vs 4-5 spikes in a row over a short time period. So what's better?

Thanks!

 

Another day, another distraction . . .

The culprit this time around? ScriptableObjects!

Previously I had my entire dynamic loading code in a single class (one for Loading from Scenes, one for Instantiating Prefabs, etc). What this meant is anytime you wanted to change from one loading method to another, you'd have to reset a lot of variables, such as the grid name (the grid is just an imaginary object, with each cell in the grid holding a terrain), grid width (how many max terrains on a single x axis), grid length (z axis), etc.

I decided to split this grid information into a separate class, and after much research ultimately decided to make this class inherit from Scriptable Object. Inheriting from ScriptableObjects allows (among a few things) for the creation of a grid asset which can be used across scenes and on multiple game objects at the same time. Basically this grid asset represents your terrain group.

So here's the current workflow.

Take your base terrain and slice it up into individual terrains (or you might have a group of terrains already made). These terrains must share a common name (which happens automatically when using the slicing tool). For instance you might have Terrain_1_1, Terrain_1_2, Terrain_2_1, and Terrain_2_2. This would for a 2x2 terrain grid, with a common name (which serves as the grid name) of Terrain.

Convert these Terrains into prefabs using the included Convert GameObject to Prefab tool, which allows you to select multiple objects in the scene and convert them to prefabs (or convert them to prefabs yourself manually -- yuck!).

Store these prefabs in a folder called 'Resources'.

Create a new Terrain Grid asset and configure it for your grid.
One of the steps of this configuration involves getting the widths, lengths, and empty terrain locations of your grid columns/rows. This can be done automatically if you are using Unity Terrains and your Terrain Prefabs are stored in a folder called 'Resources'.

Otherwise, you can create a txt file with this information and get the data that way.

This information is necessary for the loading behavior to operate correctly.

Next you'll add the loading component (whichever one you want) to a gameObject, and then drag the terrain grid asset to the appropriate slot on this component. The terrain grid is designed in such away as to allow you to edit it while it's on this component, or by selecting the asset directly in the project view.

Oh, if you want to use the LoadFromScenes loading component, you'll have to create the scenes which hold your terrains. This is done very easily if you have your prefabs stored in a folder called 'Resources', as I've included an editor tool which automates the process. I am planning on doing the same for AssetBundles, but I will probably need to leave that for a later update, since this is taking so long.

Enjoy!

 

If I don't have Unity Pro, will your dynamic loading of terrain work for me without any framerate hiccups? AFAIK LoadLevelAdditiveAsync is the only way to load things without blocking the main thread, but since that's available for Pro only...

I don't see how a paging terrain system will work smoothly on non-Pro version but if you found some way, let us know!

 

Considered doing the same myself but with such a scheme you have to make the slices so small that you can't realistically use to create natural terrain, even Kansas isn't that flat on the seams.

 

Honestly, even the Async method will not be completely smooth in some cases probably, but I have tried to spread the load out as much as possible (by using co-routines) to reduce the impact on performance. For instance, the instantiating of terrain prefabs loading method (which will be the method available to non-Pro users) never instantiates multiple terrains in the same frame. In fact, the amount of time that should occur between Instantiate calls is completely under your control, so you can play around with different values to see what works best.

Whether there is lag when the terrain loads will depend on the complexity of your terrain, so there is really no way for me to know whether you will experience lag. However, I have attempted to run some test on the terrain provided in the Island Demo, and have got good results. There was perhaps the tiniest sliver of a hiccup when using the Instantiate method, which a player wouldn't even notice.

However, I do have a pretty nice PC, so it's hard to say if others would get the same performance. If people wanted to send me there terrain I could test it, but again, the results I got might not be the same results others would get, so I don't know if that's something people would be interested in (not to mention I'm sure people would be weary of sending a stranger their work!).

Once I finish the new scripts, I would be interested in sending them out for testing to some users. Hopefully that will give us a better understanding of the performance impact for non-pro and pro users alike.

 

I'm not exactly sure what you mean by this. Are you talking about the Dynamic Loading scheme? What does the flatness of seems have to do with it?

Thanks!

 

I have a problem with this one. When i divided my original terrain into 64 pieces (8x8 grid dimension) , frame rate of my game was very low ( from 110 fps down to 25-30 fps). Can we improve performance in this case ?

 

If you want all 64 terrains to be loaded at the same time, then probably not. However, if you use the dynamic loader I'm developing now to only load specific terrains around the player, then the performance should improve. Is that what you want, or do you need all terrains loaded at the same time? The loader will have several different implementations (instantiating from prefabs, loading scenes, asset bundles, loading all terrains in deactivated mode at start, and activating/moving the terrains around when needed). It will also be free for you since you've already purchased the kit.

Can I ask what your desire was for slicing the base terrain? Were you looking to create some kind of dynamic loading system, or create terrains you could texture separately (to some degree at least). Or were you looking for better performance?

Thanks!

Edit: FCFan, I sent you a private message with some additional information.

 

In case anyone is interested in what the next update will include, here is a list. I think this is everything, but I may have missed something.

1) Single files for every user, regardless of whether what Unity version they're using.

2) A new script that can be added to a terrain to get a visual indication of how it will be sliced up.

3) A tool that allows you to cut a region out of a terrain. There are some limitations to the cut size that cannot be helped, but it's still a pretty handy tool.

4) A script that allows you to convert multiple objects into prefabs.

5) A script that when added to a terrain shows the detail resolution patches. Read up on Detail Resolution Per Patch and Detail Resolution to get an understanding of what this tool is showing.

6) And finally, the dynamic loading scripts, which will come in several different flavors

A) Load terrains from prefabs using Instantiate method and Resources.Load​

B) Load all terrains at start, deactivate all but the ones that are needed, then move/activate terrains as needed while the player moves around​

C) Load terrains from scenes using Application.LoadLevelAdditiveAsync (Pro Only)​

D) Load terrains from Asset Bundles (Pro Only, may not be immediately available with the rest of this update)​

E) Possibly - Load terrains from scenes using Application.LoadLevelAdditive (so Indie users can use). I have to test whether there is any benefit doing it this way over method A (Instantiating prefabs) to see if there's any reason to even include this method.​

 

This plugin is for me the best for slicing terrains and do some other things, this man helped me with the plugin, and he's a fantastic person. He gave me an awesome support.
The plugin fixed me a lot of weird issues for mobiles that i couldn't fix.
I recommend it !!

 

Thanks for the support Kirby!

 

Hi does this work with Unity's Flash. Thanks.

 

Unfortunately I don't know. I don't own Unity Flash, so someone else would have to test it to see if it works.

Does Unity flash support Unity Terrains? If so, I don't see any reason why this tool wouldn't work on it.

Update: From what I've read, Flash does not currently support Unity Terrain. Therefore, I don't think this kit would work with it. Sorry!

 

Hello all!

Instead of waiting for the dynamic loading scripts to be finished to release my next update, I'm going to go ahead and update the kit with some new tools immediately. You can find a video showcasing what's going to be included with this update here <--- video

I'm going to increase the price to $10 also when this update goes live, so if you're interested in this stuff, you can purchase the kit now for $5!

Any questions?

Edit: The update has now been submitted. Hopefully it won't take too long to get approved.

Please note, I changed the file structure around a bit, so you should delete the folder titled "Editor" and the script titled "SetNeighbors.js", which both can be found directly under the "TerrainSlicing" folder.

Also, there is a single script for every user now, regardless of what Unity version you're using!

 

I saw your video, that's awesome, thanks for updating the package .

 

No problem!

Since I'm sure this will come up, I'm going to explain how and why the cutting tool will work the way it will once released, in case anyone is interested.

Basically, it's impossible for me to allow you to cut out any size piece from a terrain. This isn't my choice, it is simply a limitation relating to how Unity Terrains work (or more accurately, how any resolution based terrain system works). As anyone who has worked with terrains knows, most of the resolutions have to be powers of 2, and have a minimum allowed resolution (16 in most cases). Also, regardless of the size of the terrain along the x and z axis, the resolution is the same for each axis. So even if you have a 1000 x 2000 terrain, if your heightmap resolution is 65, it's 65 along the 1000 side and 65 along the 2000 side.

When you cut a terrain with the cutting tool, you are basically taking a snap shot of each resolution map and projecting it onto a new, smaller terrain. Therefore, the new terrain has to conform to the same rules that govern the old terrain, i.e., each resolution cannot fall below a minimum allowed resolution, each resolution must be a power of 2 (in most cases), and each resolution must be the same along both axis.

This means several things in regards to the cutting tool:

1) Because the new resolution must be a power of two, you can't just use any size region for the cutting region. There are certain pre-calculated region sizes which are based on the base terrains size and resolution. You cycle through these sizes with two buttons.

2) Because the new resolution must be a power of two, the next smallest resolution after the base terrains resolution is 1/2 the base terrains resolution. This means that the largest cutting size possible will always be 1/2 the size of your terrain (in both directions).

3) Because there is a minimum possible resolution for each cut, there is a minimum possible region size you can cut out of each terrain, i.e., you cannot make the cut size as small as you want.

4) Because the resolutions must be the same along the x and z axis, the cutting regions size along its x and z axis will always be proportionate. Note that this does not mean the cutting region has to be a square. If you have a 1000 x 2000 terrain for instance, the largest cutting region is 1/2 the width x 1/2 the length, or 500 x 1000. The next smallest region will be 1/2 of that, or 250 x 500, and so on.

5) There is one final limitation that is a bit hard to explain, but I will do my best. To form the region cut size, every resolution has to be taken into account. When you're moving the cut region around your base terrain, you'll be able to move it anywhere inside the bounds of the terrain, but where you move it will not accurately reflect the region that will be cut. This is because you might move it to a place where one or more resolutions are not divided evenly to form a power of two. Or you might have it on a place where one resolution can be divided correctly, but another resolution cannot. To help account for this problem, there is a simple button you can press that will align the cutting region to the nearest point where each resolution can be divided correctly. In most cases, your cutting region will not be moved much from where you placed it originally.

Please let me know if you have any questions!

 

Here is a little picture that will hopefully give everyone a better understanding of how the Dynamic Terrain Loading scripts will work.

​

This "Load Area" represents the terrains that are loaded at any given time. Each square is a separate terrain. The green "Inner Area" represents a sort of safe zone. As long as the player remains within the boundary of the safe zone (represented by the red line), the world remains the same. When the player crosses one side of the boundary, new terrains are loaded and old terrains are destroyed. Looking at the example above, if the player crosses the right side of the boundary, 4 new terrains are loaded to the right, while the four terrains on the left most side are destroyed. Thus the grid is maintained, it is just shifted by some distance to the right.

As you can see, there are four possibilities for when the player crosses the boundary. They cross the northern side of the boundary, the southern side, the western side, or the eastern side. If the player crosses two sides in succession, whichever one was crossed first will be processed, and then the second one will be processed.

As far as the size of the load area, you have (almost) complete control over it. The inner area can be whatever size you want (besides 0). 1 Row x 1 Column, 5 Rows x 8 Columns, it doesn't matter, any and all values will work (though obviously the more terrains you load, the more powerful computer you'll need!). The outer ring can also be any value you want (except 0). This means the smallest load area possible is a 3x3 grid (1x1 inner area with a 1 terrain wide outer ring). Also note that for each increase in the width of the outer ring, you're total number of rows/columns goes up by 2.

Finally, it is possible to have empty cell locations. Before using the loading scripts, you will have to create a Terrain Grid Scriptable Object representing your world. The picture above represents the terrains that will be loaded at any given time, not your world. The world is all of your terrain objects as a whole. The scriptable object accesses terrain prefabs stored in your assets folder to compute and store information about your world (things like number of rows, columns, size of each row/column, size of the entire world in x and z direction, etc). If you want there to be an empty location, you would just delete the prefab for a given terrain at whatever cell you want to be empty. By using a scriptable object, you will only ever have to make one terrain grid for each of your worlds. You can then use the same grid in different loading scripts across different scenes.

There are a couple other features worth mentioning.

1) You get a choice of using an endless world. This is simply an inspector menu option, so you can switch from an endless to a non-endless world and vice versa easily.

2) You get a choice of using a resetting world (also a simple menu option). When using a resetting world, you will define right, left, top, and bottom boundaries. If the player travels past a boundary, the world is reset along either the x or z axis. For instance, if you define a right boundary of 20000 and the player moves to point 20001, the world is reset along the x axis. There are two reset methods available. Reset to Origin moves the load area so the bottom left terrain is situated at whatever your origin is (probably 0.0). Reset to Original Position moves the load area so the bottom left terrain is at it's default location in the world grid (and the rest of the terrains are moved by the same amount).

3) Probably some other stuff I'm forgetting, but this post is long enough as is. Any questions?

 

The terrains will be destroyed or simply disabled?, Thanks.
And you can choose the distance?