[Released] Terra Slicer & S.A.M.

I submitted an update February 5th to ensure compatibility with Unity 2018.3, however it has no been approved. I am going to contact the Asset Store to see what the holdup is.

 

@ wumn

The update has finally been published to the Asset Store. This is update 4.4 and is only an update for Unity 2018.3 users. All other users are not affected.

Fixes

1) Fixed Null Reference Bug when trying to add terrain to Slice Configuration File.

New Features

1) Terrain Slicing functionality has been updated to take new 2018.3 features into account. New terrain settings from 2018.3 will be copied to slices. In addition, a new option has been adding to Slice Configuration Files called "Copy Texture Layers Exactly." This option, when enabled, forces your slices to use the exact terrain layers from your base terrain. With this option disabled, duplicate terrain layers are created for each slice, which will probably be necessary in most instances.

 

I am so sorry! I cannot believe your post slipped through the cracks. I only now just saw this . . .

I released an update recently to fix some compatibility issues, but no, all the updates I have been working on have not been released yet. I have had some life events that have gotten in the way of work. That really is a terrible excuse but it is what it is.

Where I'm at now. I just finished work on the Editor for creating Loading Patterns. The introduction of loading patterns is a great new feature that should increase the flexibility of the kit, and I need to ensure there is an intuitive way of creating/editing these patterns.

In addition, a lot of the core code has been altered to take advantage of all of the new features; the only thing that still needs work is the Active Grid class. This should be relatively easy work. After that, I want to implement the editor for editing Worlds. This aims to be a full feature that could probably be a separate store Asset in its own right (in regards to the amount of code that it will require), so it might take some time.

After that, a lot of testing is needed. So, there is no time frame, and unfortunately in the next three weeks I will not be able to put a lot of time into this, however, for the next month after that I plan on working on the update full time.

I will let you all know when there is an update on the time frame. I do realize I have been pushing the window of release back and back and back . . . it is unprofessional and I do apologize.

As to your other comments/suggestions, I love the idea of a Discord server. I will definitely look into that.

For the source code, it is really meant to be imported into a separate, clean project before you start working on anything, as existing assets/prefabs will break once you switch the source code. After importing the Asset Store Package into a clean project, you should be able to delete the .dll's and import the files into the same folders that each DLL is in. So put the DynamicLoadingKitDLLScripts files in the DynamicLoadingScripts folder, the DynamicLoadingKitEditorDLLScripts in the Editor folder contained in the DynamicLoadingScripts folder, and the TerrainSlicingKitSource files in the HelperScripts/Editor folder.

I know this in't the best way of doing things, however it is the way it is and changing it to use a different system would be very difficult (however, I will look into the publisher you mentioned to see how they do it). When you want to update the package, you'd download the package into your first project, then extract the files into the same folders mentioned above in the project that has the source files.

At least, this should work. If you see errors using this method, please let me know!

 

Haven't used this for some years, but just updated the tool and am trying it -- but I get an error when I drag a terrain prefab into the Slice Configuration inspector: The provided terrain cannot be sliced, as one more of its resolutions is too small..... but the terrain resolutions are all much larger than what's specified there: 875x875 width/height, 936 height, detail resolutions of 36. Using 2018.4. Any suggestions?

thx

 

Hi Gecko, I am sorry you are seeing this error!

You did not mention the alphamap or basemap resolution. Both need to be at least 32. The heightmap resolution should be 65 or bigger, which appears to be the case. The detail resolution is a little more complicated, as your detail resolution per patch setting is also factored in. Basically, the number of slices possible in relation to detail resolution is equal to detail resolution / detail resolution per patch.

So if your detail resolution per patch is 32, 32/32 = 1 possible slice (number needs to be 2 or larger for slicing to be possible), thus it will report an error. You would need to either increase the detail resolution or decrease the detail resolution per patch.

If none of that is at issue, please email me a Unity Package containing the terrain and Slice Configuration File!

 

Other than bug fixing, the loading pattern editor is now complete and I can move on modifying the code base to make use of the new loading patterns and other new features.

Once again, I apologize for the long delay with this update. We are still probably at least 2-3 months out to release. I am going on a long 20 day vacation soon, but after that will be dedicating my full time to completing this update.

However, I promise, and you can see from this video, progress is being made and the update will be completed!!!

Link:

 

Nice, looks like things are coming along well. Can't wait. : D

 

It is coming along very well in terms of the quality of the update, although I will be the first to say progress is too slow. That will change soon, but thank you for your support!

 

hi, any news about last update?

 

Hi! Yes, work is progressing at a more rapid pace now. The Loading Pattern editor took a lot more time than I thought it would but is pretty much done. I still need to do a bit more testing but I'm going to leave that work for now so I can focus on the coding changes that need to be made in order to update the Active Grid class (and other systems) to work with the new grid layer system. This work is moving along very quickly and should be finished in one to two weeks. After that, a lot of testing needs to take place to make sure all these changes are working as intended.

Other than that, I also need to commence work on the new World Editing stuff, however I am undecided on whether I will do that this update or wait so that I can get the new update out faster. I would really like to get it done before pushing the update out as its probably the biggest improvement coming out and will make a major difference in peoples workflow.

Once again, I can only say sorry that this update has taken so long!! Thank you everyone for your patience.

 

Hello everyone!

I wanted to provide a link to my new Discord Server, where you can view updates and get support for all of my products, including the Terrain Slicing & Dynamic Loading Kit.

Join My Discord Server Now!

Of course, you can always PM me through the Unity Forums or my email as well, but Discord offers a new way to get support and stay up to date on the kit.

 

A little update and a question:

Progress is going well. Most of the update is finished, but still in need of bug testing.

Question: Which version of Unity are you guys using? I am thinking about removing support of Unity 4 and 5 for this next version, and possibly the non limited time support versions of 2017 and 2018. As Unity changes versions constantly it is a big pain to maintain compatibility across versions.

So, unless someone comes forward with an argument against removing support for these various versions, I will probably remove support. Thanks!

 

Time for another update!

I have finished the core updates. There are a few more things I want to add but I have just started bug fixing and want to make sure everything is working correctly before adding these additional small features.

Two small but cool new additions I have recently added:

1) Revamped Async Scene Loading to make finding newly loaded scenes easier. This has removed the requirement for configuring scenes in a special way (having a top empty root object). Now all asset hierarchies are unified, regardless of whether they are in scene format, Asset Bundle format, or prefab format.

2) Added PDB files for better debugging. Previously line numbers were not printed on exception, but that has been corrected with the addition of the .pdb files for the DLLs. Not only does this make finding the cause for any errors you run into while using the kit easier (by an order of magnitude), it has also sped up the bug fixing phase I am currently in the middle of.

 

Hey all, it's been a while since my last post, but just wanted to update you and say progress is still going well. There's been some stuff related to the pandemic that has stalled things a bit, but work is starting to return to normal. I'm currently testing out some of the new features, which I what I want to show off today:

All of the spheres in the gif are part of the same grid layer, which is interesting for two reasons:

The grid layer for the spheres is three dimensional, while the base grid layer (the one the terrains are part of) is two dimensional. This is a cool little feature (only available when the base grid layer is 2D on the X and Z axes) that enables dynamic loading in the vertical space.

Second, you can see a basic example of LODs here, as the sphere comes in two flavors, a high poly LOD and lower poly LOD. You can see the LOD's transitioning very nicely, very similar to what is done with Unity's LOD Groups, and you can also see game objects belonging to new cells fading in, and game objects related to old cells fading out.

This behavior is the result of a new component, the Cell Visual Transition Controller, which as the name implies, controls how cell's visually transition in and out of the scene. This encompasses new cells being loaded, redundant cells being unloaded, and cells transitioning from one LOD to another.

You can assign controllers on a grid layer by grid layer basis to allow for different behavior for different types of objects (or assign the same controller to multiple grid layers). By default, the update will likely only include the controller you see working in the gif (more on how it works below), however like many other systems in the kit, you can create your own custom controller to fine tune how transitions occur in your game. For example, you could scale the game objects of new cells so they look like they are popping up from the ground.

The controller that will be included with the update works by manipulating a shader property over time using Material Property Blocks and animation curves. It will be up to you to utilize this shader property to do whatever you want with your objects, such as fading transparency in/out.

 

Update Time!

Most of my time has been taking up by three things:

1. Creating a nice fly through video to showcase the basic use of the DLK. While this may seem like something I should be working on after completing the update, creating this video has highlighted some bugs and also pushed me to work on integration with Map Magic 2 and Vegetation Studio Pro. I am still undecided on whether integration will be included with the product by default, or will require separate payment. I am leaning towards the former, but going the route of the latter creates more of an incentive to add integration with other Asset Store products. Since I am giving this next update away for free to current users, finding other revenue sources is an attractive option.
   
   
2. Fixing Bugs and adding some new features that were not planned, which leads me to my next and final point.
   
   
3. I have reworked the DLK to allow for non game object use cases. Previously, the kit was designed to only work with unity Game Objects, whether they be Terrain or non Terrain. However, with the introduction and increased use of GPU instancing, I realized that in some situations game objects are not necessary any longer. This change also should make the kit more compatible with DOTS based workflows, where Game Objects typically don't exist. How does this work?
   
   Previously, when a cell was loaded by the DLK, objects associated with the cell were also loaded by calling the Primary Cell Object Sub Controller (which would in turn call the Cell Object Loader). When game objects are needed, this is still how things work, however if you set your CellObjectType to None on your World Grid, the DLK will eliminate this step and avoid performing some other actions related to Game Objects. This can save on memory allocations and speed the loading process up a bit.
   
   Now, if that's all you do, you'll get a bunch of cells that just don't have objects. That's not very useful, so you'll need to take those cells and use their positioning to figure out what should be drawn with GPU instancing. This is easier to do now with the introduction of another new feature, Cell Listeners. Cell Listeners are special components you can add to specific Grid Layers. When that grid layer adds or removes cells, the listeners are notified. This allows you to track what cells are currently in the scene and perform actions based on that fact (by designing custom Cell Listeners). As an aside, Cell Actions are being removed since Cell Listeners can be used for the same behavior and are way more efficient.

Take a look at the following gif:

The grass you see is drawn using Graphics.DrawMeshInstanced. As the player moves around, you can see new grass popping in as new cells are loaded. The loading area is kept small so that the loading action is visible; in a real game you would want it to be larger so the player doesn't notice the grass popping in. The grass scatter algorithm is as simple as it gets, so doesn't take into account terrain texturing (spawning grass only on certain textures could be an option) or scatter the grass realistically. This is meant as a proof of concept to show the power and flexibility of the Dynamic Loading Kit. The ability to draw this grass with DrawMeshInstanced was introduced by a creating a single new component (Cell Listener) and did not require any modifications to the source code (beyond the modifications to allow for a non game object based workflow).

This has been and will continue to be a core design philosophy. Offering a component based approach that includes a wide range of functionality by default, but also allows for the introduction or integration of functionality without modifications to the source code, which are difficult to maintain with future updates to the product.

Sorry for the long post, but I hope you all enjoyed!

 

While working on the showcase teaser video, I realized having the ability to set the layer and game object tag of objects loaded via the DLK would be a handy feature to have. While this seems simple, it took a bit of effort, however I am happy to say the feature is working great!

Today I would like to show a little video of a dimensional rift effect. This is achieved with the layer setting feature, as the objects in the "other" dimension are on a separate layer not rendered by the camera normally. Through some script and shader magic, I think the effect turned out pretty cool!

 

Hello all! I wanted to provide a quick update. Progress slowed a little in the last few weeks but is picking up again. The trailer world is nearly complete, but needs a little more love. I have also completed an overhaul of the navigation on my website; this mainly is beneficial to API navigation.

In addition, I updated the Terrain Slicing Demo on the website. There was a bug in the WebGL demo that made the trees not match up between the slice and original terrain. In addition to this change, I also added a second slice to the demo so that the seems between slices can be observed. The Windows standalone download has also been updated with these changes.

The demo can be found here: http://deepspacelabs.net/html/terrain_slicing/demo.html

As a reminder, even though the API is intended for users who want to implement custom components or interact with the kit via advanced coding mechanisms, there is also a lot of general detailed information on all the components, such as detailed information on all the inspector options for different components.

That API can be found here: http://deepspacelabs.net/html/dynamic_loading_api/documentation_main.html

The website also has some great guides available, which I like to refer to as "Quick Guides"; these can be found here: http://deepspacelabs.net/html/dynamic_loading/learning_quick_guides.html

An overview of what's included in the kit (this includes components, misc tools, and actions which can be executed in the editor) can be found here: http://deepspacelabs.net/html/dynamic_loading/learning_what_is_included.html

Finally, the entire version history is hosted on the website for those interested: http://deepspacelabs.net/html/dynamic_loading/versions.html

 

Today I wanted to do something different and try to open a discussion on how I see saving/loading and server/client communication in a dynamic, origin shifted world environment. I'm not sure if there is enough of a following of this forum thread to do so, but it's worth a try! I wanted to offer up my thoughts and speak about how I will be approaching this topic within the Dynamic Loading Kit, and see if anyone has suggestions or sees any issues with this approach.

So, what am I talking about? In a fixed world, saving dynamic positions (objects loaded at runtime that have no fixed position relative to a scene) is very straightforward, as the positions of objects within the scene will always relate to fixed objects (houses, terrain, scenery that is saved with the scene) in the same way between gaming sessions, or between different clients in a multiplayer setting.

However, in a origin shifted environment, the scenes that were once fixed move around in order to keep everything close to the origin. Therefore, it's not possible to only save the raw position of dynamic objects (to understand what I mean when I say "dynamic objects", consider a fork that you can physically manipulate in a game like Skyrim, when you save the game the position of the fork is saved so you can move it around and not have it reset).

Clients in a multiplayer environment, even when two players are standing in the same position, may have a slightly different world configuration for a variety of reasons. The server cannot send the message, "Position of object A is at 0, 5, 20" to the clients, because that message does not take into consideration the world configuration (Scene 1_1 may be positioned at 0,0,0 for client 1, but at 0,100,0 for client 2).

The solution is to translate all scene position spaces into cell relative positions. That is, any time we want to save or make note of the position of an object, we need to first determine what cell the position is in. Once that's done, we can recalculate the scene position as a position relative to that cell. Of course, this is achieved via the DLK and a method will be available on the World class to do so.

When the position is sent back to the client, or reloaded from a save in a non-multiplayer scenario, the client/game takes the cell relative position, along with the cell, and the DLK translates it back to a scene position. The DLK has intimate knowledge of where every cell is located in the client's instance, so it can easily perform this operation for you (again, via a method on the World class).

Of course, saving or sending the cell to the server would be rather redundant in situations where multiple dynamic positions fall within the same cell, so there is some additional work to be done to remove this redundancy on your end.

What do you all think? Is this a good solution? To be clear, what I am offering via the DLK is two methods available on the World class, one which translates a scene position to a cell relative position (and also returns the cell), and one which takes a cell and cell relative position and converts it back to a scene position.

 

It certainly sounds like a viable solution, and definitely better than what I could probably come up with, but unfortunately, I personally just don't have enough hands-on experience with a system that keeps track of relative position in a multiplayer environment to be able to really foresee any possible technical or performance bottlenecks, or to be able to give much insight or feedback until I actually had my hands on it, saw the code, broke it, then fixed it, etc, lol.

 

I understand completely. Thank you for taking the time to respond!

 

Hello, just purchased the kit. Slicing worked fine but I'm getting an error when creating the scenes via SceneGenerationFile to set up the DLK. For the config I followed the quick guide and the only error I get is the one pasted below from the Console.

Code (Boo):

1. Error Generating Scenes
2. UnityEngine.Debug:Log(Object)
3. DynamicLoadingKitEditors.SceneGenerationFileBaseEditor:DrawInspector()
4. DynamicLoadingKitEditors.BaseEditor:OnInspectorGUI(Boolean)
5. DynamicLoadingKitEditors.SceneGenerationFileEditor:OnInspectorGUI()
6. UnityEngine.GUIUtility:ProcessEvent(Int32, IntPtr, Boolean&)

 

Thanks for reaching out to me via email! I will respond there but post the solution (when found) here for all to see.

 

Time for another update!

I completed the Loading Pattern a while ago however wanted to take another crack at it, because I was not happy with the performance of the tool when dealing with large patterns (an unlikely event, however I want to support any possibility).

The only way to improve performance was to switch to using the Unity C# Job System to get the benefits of multi-threading. While I have worked with the Job System in a side project in conjunction with Unity ECS, I have never worked with it in regards to editor code, so it has been difficult and time consuming to implement; however, I have started to make some real progress and I think I should be finished with the overhaul by next week. At that time, I will most likely perform some testing and then push towards releasing the next update.

Unfortunately, this will mean the world editor that was promised will not be included with the next update, mainly because I anticipate that work taking a little time and really would like to not delay this update any longer, as it still contains some awesome new features and improvements that I think everyone will enjoy.

ps: The Job System use only uses containers and other systems available in the default Unity installation, so there will not be a need to install additional packages or Unity ECS.

 

Unfortunately, testing and fixing the bugs related to the Pattern editor overhaul has taken longer than I hoped. It is going along, however, and I am happy to say that the changes have resulted in some massive speed improvements. What I've learned may be useful in future changes.

With the holidays coming up, work will be slowing and so the next update will likely only come after the New Year (sorry!).

I will be out of town (away from my computer) from 12/12 until 12/19, so support will be limited. It is best to use discord for this week as it is easier to access from my phone. I will try to respond and give the best help I can for any issues, however without my computer this will be difficult.

Happy Holidays everyone!

 

Hey Kyle long time no see, hope all's well with you.

I looked at your asset and world streamer quite some time ago, at the time did not consider either suitable for my
needs so decide to write my own streaming asset, having not coded for quite some number of years
I decided it would be good way to relearn old skills and Unity. My own efforts so far pale in comparison
to what you are currently doing and can't wait to see the finished product.

I've recently added a Floating Origin system in which the main scene has a single gameobject ( world anchor ) as a
parent for all objects that require shifting. I don't change the transform of any object other than the anchor,
this preserves their original transforms. The same applies for additive scenes, all objects in the
scene are parented to a root transform and on load/origin shift only the root transform is moved, all other objects come
along for the ride.

So when you say that "Therefore, it's not possible to only save the raw position of dynamic objects", how so?
As I see it the server should be able say object A is at (original transform)x,y,z it's then up to each client
to translate object A to it's respective world anchor.

I don't use asset bundles but rather Addressable assets/Addressables.LoadSceneAsync, originally I used
asset bundles or Addessables.LoadAssetAsync but found a major pitfall, when instantiating terrains that used
specialized shaders ie: microsplat, CTS, the terrains would be invisible and required the shader to be re-attached after
loading(not optimal) no such issues with LoadSceneAsync. So FYI you may face this issue if not already.

I've implemented a system that has 99.999% seamless transition from lo res to hi res terrain, not sure if it would work with your asset but if you're interested in the details PM me.

best regards Les Bosworth.

 

Hi, thanks so much for joining the discussion; it is greatly appreciated! Using a single root world object definitely makes shifting the objects much easier, however my concern with this system is that you are left with a world relative transform position (in the case of the root object) that is greater than 10,000 meters, and local transform positions (in the case of child objects) with greater than 10,000 meter positions. Perhaps I am not understanding how your system works, so please correct me if my assumptions are wrong, but how I see it working is like so:

Let's say you have a world that is 100,000 meters x 100,000 meters. Perhaps that is a bit unrealistic, but I'm using it to illustrate the potential problems. Your root object is initially at 0,0,0 and let's say the world is centered, so the world extends on each axis 50,000 meters. Any object near the edges of your world would have local transform values close to 50,000 meters. In addition, in order to travel to the boundary of the world and keep the player centered, the offset for the root object will need to be close to 50,000 meters (or -50,000). Is that correct, or am I horribly misunderstanding the situation?

If my understanding is correct, would such a value for this root object cause issues? Would the local transforms of objects having greater than 10,000m values present problems? Honestly, I am not sure. All my knowledge is pretty much theoretical, after this next update (or perhaps before I finish it), I need to do some testing to put this theoretical knowledge to the test.

I believe that what you are describing is very similar to my approach; the difference is you are using a world anchor as a reference point, whereas I propose using the position of the cell each object is in as a reference point. As I stated above, I have concerns with the world anchor, which is why I am using my system. But, if my understanding of the world anchor is incorrect (please inform me if so!), I may revise my choice, as the intent with my system is to keep all client positions as close to 0,0,0 as possible.

I am going to be taking a look at Addessables, as I agree they look like a better solution than Asset Bundles. I have done some limited research but have not explored them thoroughly. I will be sending you that PM, the system you describe sounds very interesting, and I am always looking for ways to improve loading performance!

Thanks so much for your input!

 

Hi all, I recently found a couple of bugs that I wanted to fix, and have published an update to the Asset Store (I'll let you all know when it's available). These include:

1) Fixed a bug with the Scene Generation tool that resulted in an exception when the 'Are Scenes Fixed' option was disabled.

2) Fixed a bug with Unity 2019 and above versions causing the slicing grid not to appear. Note, there may be other issues with Unity 2019, so upgrade your project at your own risk!

This update is only for 2017 and 2018 Unity users (both versions are also incremented to their LTS versions, 2017.4.34f1 [which is actually no longer supported by Unity] and 2018.4.26f1, so the main fix which is number 1, will not be seen by 4.1 -5.5 users. However, if you are a 5.5 user, I do have a version of the package available, it is simply that Unity has removed Asset Store upload support for 5.5, so I cannot update the Asset Store. So please email me if you need the fix.

This is obviously not the big update, and you'll see the version reflected (it will be 4.4.1, not 5.0.0).

When the big update comes, it will only be for Unity 2019.1 and greater versions of Unity. The reason is, Unity slowly stops supporting past versions over time, with 2018 LTS set to expire in spring of this year. When they do this, they also remove Asset Store upload support.

In addition, some of the new functionality of the kit will only work on 2019 and above. However, I will continue to fix any bugs that may arise with <2019 versions of Unity, so please email me with any bugs you find on these versions!

As for the next big update, again I must apologize for the delay. I am currently traveling back and forth between the Unitied States and Colombia (where my girlfriend lives), and this movement delays the project each time. Fortunately, I am currently in Colombia where my work pace is usually better, so I am hopeful the update will be available within the next two months (but no promises!). I am finally wrapping up work on the loading pattern editor, once I do so I will be ensuring the changes have not had a negative effect on the rest of the code base, and then continuing work on the demo (which also helps find any bugs).

Best Regards,
Kyle Gillen

 

Okay, so there was an issue with the latest update to the Asset Store. You can no longer include .exe files with an Asset Store package upload, which means the included Asset Bundle Manager is not allowed any longer.

What does this mean?

I have had to resubmit the 2017.4.34f1 and 2018.4.26f1 Unity version updates without the Asset Bundle Manager package. This package is no longer supported by Unity, so if you would like to use Asset Bundles in these versions of Unity, you will need to download the package from my website.

On the Asset Bundle Loader inspector (custom component of my kit that allows you to use Asset Bundles to load in cell objects such as terrain) and when using the 'Enable AssetBundle Integration For Current Platform' menu option, you will now see buttons that initiate a save file dialog box for the correct package for your version of Unity (again, the files are hosted on my website).

Click the button, download the package, and then import that package into Unity. Then, you will be able to Enable Asset Bundle Integration for your current platform of choice.

In addition, I have decided to remove the Unity 4.1 and Unity 5.5 versions of my product from the Asset Store. The 5.5 one had to be removed because it contained the Asset Bundle Manager and I am unable to update this version to remove it. If you are a Unity 5.5 user (or pre 2017.4.34f1 user), you can email me with your invoice number to receive an updated package with the fixes I outlined in the previous post. I removed the 4.1 version because it is just too old and almost impossible to support.

Therefore, the only versions available on the Asset Store for the time being will be for 2017.4.34f1 - 2018.4.26f1 users. To be honest, I have done some limited testing for 2019.2 and everything works well (the only issue being some lightmapping settings not being copied to slices when using the Terrain Slicing tool), so if you want to use the 2018.4.26f1 version on 2019.2, you should be fine. For any other versions after that, please email me to ensure compatibility.

Also note that with update 5.0.0, I will be supporting the following versions of Unity. 2019.1, 2019 LTS, 2020.1, 2020 LTS, and 2021.1.

Because the 2017 and 2018 versions will be very different and not contain the 5.0.0 update, I will likely remove those versions from the Asset Store to avoid confusion. I will continue to update these packages to fix bugs and those updates will be available via email to any existing customer that can provide an invoice number.

I think that covers everything.

Best Regards,
Kyle Gillen

 

Hi. I'm trying to go around current 8 lights per object URP Forward Renderer limit. Can I use this asset to split my terrain on many smaller pieces to be able to get more lights in result?
Thanks

 

Hi. This asset will allow you to split your terrain into smaller pieces, however I don't have enough experience with URP to answer your question on whether this will allow you to get around the light limit. You should be able to answer it yourself by manually creating numerous smaller terrain. Good luck!

 

Hey all. A user brought to my attention that a bug with the slicing tool was introduced. The fix has already been submitted to the Asset Store and should be available in no time, however, as always you can email me your invoice number and which version of Unity you are using and I will send you a download link for the updated package early.

 

Hey everyone, it's time for another new feature update!

I am thinking about adding an in editor guide that not only will help you with getting started with the kit, but will also be a great reference if you have specific questions during your use.

Of course, email, this forum, and discord will always be available to answer questions and provide support, but I am thinking that with an in editor guide, a lot of questions you might have could be easily answered right in editor.

Not only would this speed up your workflow, it would remove the need for an internet connection or internet use (although more advanced info such as API methods and such would still be hosted on the website).

In addition, because it's in editor, I can create buttons to launch editor tools, add components or game objects to open scenes, and so on, which will make setup much easier.

So, what do you guys think about this? Have you seen this used in other Asset Store tools? If you think of any ideas that would be great to have with the editor guide, let me know! Here's a little gif to show the design I have in mind. It's simple and functional (I think!).

 

The fix is live with update 4.4.2

 

Hi guys, it's time for another udpate:

I was doing some performance testing with the kit, namely trying to track garbage generation, when I noticed garbage generation was happening each time the World was updated. I tracked this down to my use of IEnumerator iterators, so I am currently rewriting a lot of methods to remove this garbage generation. Suffice to say this will add some time to the release schedule.

 

Update time!

In addition to continuing work on reusable Enumerators, I was also recently inspired by the Unity 5 tech demo, namely, the way world editing utilizes little images of your world to make it easier to see which part of the world you are editing.
This got me thinking if it would be possible to do something similar in the TS&DLK kit . . . and I realized not only would it be possible, but we can take things a step further and add dimensionality to the map preview!

Below is a video showing the feature in action. There is a new tool which can "miniaturize" your world assets, and these miniature versions are used rather than the full resolution assets. Currently, I've got it working with the Loading Pattern editor, however this feature will be implemented in the World Editing tool as well (once it is finished). Please enjoy this little gif showing the feature!

The colored lines on the edges of the tiles are showing which cells are inner area cells, and on the outer area cells, which LOD the cell is a part of (there is a color key table in the left part of the window). I am open to suggestions on changing this to something else; the important thing is that the user be able to tell the LODs by looking at the cells.

The best thing about my method (rather than using simple 2D images as Unreal is doing), is that it will work with three dimensional worlds (worlds that have cells on all three axes).

Edit: Another thing I should mention: because this work required some investigation into terrain simplification and terrain to mesh conversion, there is a strong possibility some sort of conversion tool will be added to convert terrain to lower quality terrain or meshes, for use as LODs.

 

I've been hard at work trying to improve the Loading Pattern Editor, as I was not happy with the way vital information about the cells (such as the cell's index and LOD the cell is a part of) was displayed. I've been working on a custom shader that allows this information to be overlayed on top of the mesh. Please have a look at tell me what you think!



Previously I was using GUI drawing code to display this information, and it was only displayed when you viewed the pattern from a 2D top down view. Now, not only can you view this information no matter the angle/view, the performance of the tool has improved dramatically with the use of a shader to display this information!

The little colored squares are the only thing I am not sure of. Right now, I pass color information to the shaders which is determined by the cell's LOD. Previously this was used to color the entire mesh (and will still be used in this way when not using miniature models) in order to differentiate between different LODs, however this technique is not suitable for the miniature meshes as it ruins the effect of displaying their vertex colors.

I like the effect of the squares because it allows you to more easily see the change between one LOD and another. The shape of the color is determined by a texture which you can change out on the material if you desire, but if you have another idea for displaying the LOD color, let me know!

 

Hello, I am considering whether the plug-in is suitable for the game in production. The game has a randomly generated open world terrain environment, which is randomly generated by the user when creating the world. Does the plug-in support segmentation of the entire environment after the terrain is generated at runtime? Or other feasible solutions will also be very helpful, thanks for answering

 

Hey, and thank you for your inquiry!

Currently, there is certain data that needs to be preconfigured in the editor (the dimensions of your world [number of rows/columns, as well as the row lengths and column widths] for instance).

What is actually loaded at runtime is determined by a special overridable component called the Cell Object Loader. There a few of these included with the kit. One loads prefabs, one loads scene assets, and another loads Asset Bundles. It does this by using a preconfigured (in the editor) base name that is then supplemented by the row and column number of whatever cell needs to be loaded. The component then loads the asset with that given name. There are two things to note here:

1) The base name can be modified at runtime, which allows you to dynamically change the assets which are loaded on the fly (think, loading lower quality assets as a result of the player changing a setting, or loading alternative snow assets for a winter themed event).

2) The Cell Object Loader is an overridable class, so you can create a custom loader that works differently than those described above. This is usually where I tell customers to hook into their custom procedural world generation. So instead of retrieving some pre-created asset, the loader could create the cell object (i.e., the land piece) on the fly. The method that retrieves cell objects is a coroutine, so you can spread the creation over multiple frames for better performance.

So, to answer your question: if you are simply changing what is loaded for each cell dynamically based on a procedural generation algorithm, my tool should work great! If, however, you are changing the dimensions and other data, right now it won't work, however this is something I could add support for in the future without much difficulty.

If you are still unsure whether my tool will work, please provide more information on what exactly changes between each World generated by players. Do the dimensions of the world change (100 rows in row 1 vs 88 rows in world 2)? Does the length of a single cell change (100 meters in world 1, 200 meters in world 2)? Whatever changes, please make a note of it in your post.

Also, something to keep in mind is that currently infinite worlds are not supported, as the tool requires your world to have preconfigured dimensions (i.e., it can not have infinite rows, the number of rows must be set to some value, for instance 10000). I may change this in the future because again, it is a simple change to implement.

 

Thank you for your reply. The game in this production has a fixed-size world. A large blank area in the world is just the ocean, and multiple island terrains with different sizes are generated at random locations.minerals, minerals, and trees.or other Resources are randomly generated on the islands.i will check it next week,thank you

 

Okay, so right now which cells are empty is another thing that needs to be preconfigured in the editor. Otherwise the default Cell Object Loaders will try to load and manipulate an asset that does not exists, which will result in some Null Reference Exceptions.

I will look into changing that, however in your case I do not believe it will be a major issue, as you are most likely going to need a custom Cell Object Loader, which you can setup so that when an empty cell is needed, it just creates an empty game object. I believe this will work without issue.

 

Hello everyone!

I made a quick demo showcasing the Pattern Editor working with a 3D world and miniaturized meshes. It's not a great example as I put it together quick and used simple cubes for the cell pieces, but it should give you a general idea of what to expect.

Please keep in mind that currently the LOD and Cell Index information on the meshes is displayed using the mesh UV's. I am researching alternative approaches because I do not like relying on the UVs since they are not consistent across non terrain meshes. If anyone has any suggestions on this front, please let me know!

 

@gilley033 I'm thinking of buying this, the forum here and the asset store are saying different things so I just wanted to confirm a few things.

1. I'm developing on Unity 2019.2.21, so 21 not 12, will this still be compatible? I'd need confirmation from you that everything is working without issues.

2. The reason why I'm interested so I just want to create a large terrain and then have it all split up, but I don't plan to do this in runtime, I'll just be doing scene changes which then load in another terrain. So the question here is, can I cut up the terrain in the editor and load them as needed or does this tool only work in runtime? I've had a few issues in the past with terrain tools that specifically only work in runtime and it's not clearly stated.

 

Hi Bantichai,

First, sorry for the delayed response, I just had a little mini vacation that was planned at the last minute and have not had access to my computer.

1) I forgot to update the original post here with the newly supported 2019.2.12 version when I submitted the most recent update to the package. Sorry! I have not tested on 2019.2.21, but normally with such a small version change there are not any tool breaking changes, so you should be okay. If you do find an issue, just email me and I will get a fix to you soon.

2) The slicing tool actually does not work at runtime; it only works in the editor. The tool creates either terrain game objects in the same scene as the base terrain, terrain prefabs stored in your project hierarchy, or both. If you have a large number of slices created, please note that you should use the option to create terrain prefabs only (by selecting the option to remove the game objects from the scene), in order to keep the memory footprint of the slicing tool low.

There is also a separate tool that allows you to easily convert a group of prefabs into scenes, if you have need of it. This can be used with the created terrain slice prefabs or with other groups of related prefabs if you desire.

Please let me know if you have any more questions!!

 

Okay, so I've been scratching my head trying to think of a solution to the text drawing issue, and I think I came up with a passable solution. This new solution uses the world position of the pixel on the mesh + the mesh's dimensions to calculate the pixel of the text to draw. Each axis of the mesh has a separate text drawing on both the positive and negative axis, so a cube for instance will display the text six times, one on each side. The normals of the mesh are used to determine which axis the pixel is a part of.

This will work well for continuous flat meshes, and it also works for miniature terrain assets created from terrain, as I've modified the normals of the terrain to all point straight up (as an aside, this does mean that these mini terrain probably won't work in a lighted environment, however there are not intended to be used outside of my tools anway, so this should not be an issue). Meshes with gaps will have not have text drawn perfectly, however for this instance and others that I will likely miss, I am going to provide the alternative text drawer that uses the mesh UV's as an optional material, so you can switch between the two different shaders. Hopefully this will allow most meshes to be covered and have correct text drawing.

To see what exactly I mean, please take a look at this updated GIF showing the Pattern Editor in action!

 

Edit: The information under "Original Information" is outdated and can be ignored.

Users of S.A.M., the issue mentioned below should no longer be an issue. S.A.M. can and will efficiently handle terrain neighboring and Unity's Built in Auto Connect setting should be disabled on terrain used with S.A.M.

Do note, you may still notice some garbage generation from Unity trying to auto-connect terrain, even though all terrain have auto-connect disabled. This is unavoidable, however the garbage generated should not be much.

vv Original Information vv

For anyone on 2018 or above that is noticing seems between your terrain while in game, the issue is with the new Auto Connect feature that Unity added. Unfortunately the way this method is implemented and called (whenever a new terrain is added or removed from the scene) results in the current way I manually neighbor terrain (which removes the seem) to not work correctly.

The only way to get around this issue is to make use of the Auto Connect feature instead of my manual neighboring. To do this:

1. Enable Auto Connect on your terrain and ensure all terrain used by a single World Grid have the same Grouping ID.
2. On the World Grid associated with the terrain group, change the Cell Object Type to "Other_Has_Renderer" or "Other_No_Renderer" (the difference only affects how World Grid data is calculated using the old calculation methods, so it should not matter).

And that's it. Changing the Cell Object Type will force the DLK to not using the manual terrain neighboring method, however Unity will still detect the terrains as they are loaded and auto connect them.

Please be aware, however, that the Auto Connect method is quite terrible and may result in a lag spike. I am seeking to overcome these issues in the next update, however it is a struggle (currently I have neighboring working, however there is a momentary flash of time where seems become visible).

 

Time for another update!

I just finished the overhaul of the core code base to eliminate all garbage generation due to coroutine use. Any coroutine that is used repeatedly within the code is now a reusable enumerator. This should significantly reduce garbage generation and collection!

The code base is feature complete and finalized at this point. The process of creating the reusable enumerators necessitated testing of most of the code base, so I would feel very confident releasing the package with the code that is in place.

However, the World Editing toolset is not complete yet, and I really would like to have this toolset be a part of the next update. What say you all? Should I release without this toolset, which will allow for much sooner release date, or just wait until the toolset is complete? To clarify, the toolset will be designed to allow you to easily edit your dynamic/streamable worlds in the editor. The best analogy I can make is to what was scene in the Unreal 5 video that was release a month or two ago, where the dev clicked on a tile piece and it was loaded into the scene for editing.

In either case, there are still two more items that need to be worked on before release:

1) The documentation: I need to update some of the existing documentation to account for all of the changes that have been made. In addition, I want to finish the In Editor Guide, as it will be an invaluable resource for both new and existing users.

2) I have been considering a rebrand of the product. Terrain Slicing & Dynamic Loading Kit doesn't exactly roll off the tongue, and I wonder if a rebrand would help elevate the product to new heights. However, I despair that existing/old users will have trouble finding the produce under a new name. If anyone has an opinion on this, please let me know!

 

Was there any update? I only find one from April 2021

 

Hi, the update is not complete but getting closer each day. If you are interested in getting the update early you can become a beta tester. Beta testing is available to users who have already purchased the product and who are open to using Discord.

Please note that some features are not complete, such as the new World Editing tool. In addition, documentation is still a WIP so beta testing is recommended only for users that don't mind figuring things out themselves (I will answer questions as best I can, but I don't intend to provide in depth guidance as it takes too much time out of the dev process).

Please message me on Discord if you are interested in becoming a beta tester; you can join the Discord channel using the link in the first posts, and then send me a PM on there.

Best Regards,
Kyle

 

I will be out of the office until next Wednesday (Nov 24). I will not have access to email at this time, so please contact me via these forums or Unity Discord if you have a question or need assistance.

 

I'm back again for another update!

Having completed work on the core code and Loading Blueprint Editor, I have moved on to working on the World Asset Editor. This tool is intended to make it easier to edit your assets, as it can be tiresome to do so in a streaming/dynamic loading workflow when you are dealing with potentially 100's of assets.

You might remember one of the Unreal Engine 5 preview videos where the dev opened up a 2D preview of their world, selected the terrain piece they wanted to load, and then loaded up the terrain into the scene to work on it.

That was definitely an inspiration for this tool, however I think you'll find my tool even better with the inclusion of miniature mesh assets. Here's a little video of the tool in action (please remember, it is a WIP and some things are likely to change).

The tool is based on the work I did with the Loading Blueprint Editor, so you will see some major similarities between the two. This preview is showing off the 3D workflow. 3D workflows are difficult because it is very easy for the selectable cells to get in the way of other cells. That is why I use a single layer based approach, where you can only select and work with cells on a single layer. All other cells are made transparent (and alternatively you can hide these transparent cells for an even clearer window).

Right now you can load and unload assets using this tool, though I am thinking about adding the ability to save assets as well. The difficulty here is that assets can come in a variety of formats, and each needs to be handled differently.

The tool comes with built in support for Prefabs and Scenes, however the mechanism for loading/unloading (and potentially saving) assets is extensible, allowing for support for other asset types. This extensibility also makes advanced functionality possible, for instance adding a system for "checking in/out" assets so that only one dev from your team can work on them at a time.

Let me know what you think. Any feedback or suggestions are greatly appreciated.