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

1407447--1269733--sam_logo.png 1407447--1269736--streamable_worlds_bundle_logo.png 1407447--1269739--terra_slicer_logo.png

S.A.M. - The Streamable Assets Manager
Terra Slicer
Streamable Worlds Bundle

Website | Discord Server | S.A.M. API | Contact Form
SAM Documentation | Terra Slicer Documentation

Users of both SAM and Terra Slicer, PLEASE READ

With the movement of the In-Editor Guide info to my website, some code changes were required to the Core DLL. If you have both products int eh same project, it’s very important that you update SAM to 1.4.0 or greater and Terra Slicer to 1.2.0 or greater, even if you only need to update one of the products. If you do not do this, you will likely see an error in the console!

Warning! Please Read! Products may be shown as discounted after free purchase

I have had reports from users that after getting Terra Slicer and SAM for free, they show as available for a discount.

This is an Asset Store bug that I have notified the store team about. Please do not purchase Terra Slicer or SAM again in these instances!

If you have not gotten the Assets for free yet, and you believe they should be free (based on being a TS&DLK or SWB owner) but they are showing as not free (but discounted), please contact us!

Hello and welcome! This forum serves as a shared space for Terra Slicer, S.A.M - The Streamable Assets Manager, and the Streamable Worlds Bundles (which includes TS and SAM).

Feel free to post questions or anything else related to these products, or use our website contact form or discord channel!

If you are looking for the Terrain Slicing & Dynamic Loading Kit, don’t worry, you’re not crazy! That kit has been converted to the Streamable Worlds Bundle. Please read the first two spoiler messages below for more info!

Terra Slicer and S.A.M. Have Arrived!
More Information About The Arrival

Terra Slicer and S.A.M. - The Streamable Assets Manager are now live on the Unity Asset Store! The Terrain Slicing & Dynamic Loading Kit has been converted to the Streamable Worlds Bundle, which includes these two products.

  1. If you purchased the TS&DLK in the past, you will now see the Streamable Worlds Bundle in your Asset List - When you add Terra Slicer and/or S.A.M. to your cart, they should show as free.

  2. If you purchase the Streamable Worlds Bundle - When you add Terra Slicer and/or S.A.M. to your cart, they should show as free.

  3. If you purchase S.A.M. - When you add the SWB to your cart, it should show as costing $30.

  4. If you purchase Terra Slicer - When you add the SWB to your cart, it should show as costing $80.

If you purchase both S.A.M. and Terra Slicer individually, you cannot get the discount, so please make sure to get the other products (when you have one) by purchasing the Bundle instead.

Redeeming Terra Slicer & S.A.M - For purchasers of the TS&DLK or the Streamable Worlds Bundle

If you purchase or have purchased the Streamable Worlds Bundle, or purchased the TS&DLK in the past, please follow these steps to gain access to Terra Slicer and S.A.M.

  • Navigate to each products asset store page using the links at the top of this post.
  • Add each product to your cart.
  • Checkout - Each product should show as 0$
  • Download each product separately.
  • Note, after steps 1-4, the products may show as available for a discounted price (as if you never purchased them). This is an Asset Store Bug. Do not purchase the products unless it is for free!

Support

Use Our Website Contact Form: https://deepspacelabs.net/html/other/contact.php

Or post here/use Discord (link above)

If you have emailed us and we have not gotten back to you after a full day, please send us another email, post on these forums, or on discord. Chances are the email was lost somehow!

If you are seeking support for an error, please check the “Known Issues” spoiler below this one to see if the error has already been reported. If it hasn’t, when you contact support please include:

  • Screenshots or Descriptions of Errors.
  • Steps to reproduce the error (if possible).
  • Screenshots of the settings from components/assets that you think are related to the error (Streamable Grid, Slicer asset, etc.)
  • Your invoice number and which product you purchased (if it’s the bundle or TS&DLK, let me know).
  • Which version of Unity you are using

This will help speed up the support process.

Please remember that both Terra Slicer and SAM include abundant inspector tooltips (settings with * in their name) and comprehensive In-Editor Guides. If you have a question, the fastest way you will find an answer is by using these resources rather than seeking support from us. If you can’t find what you’re looking for, let us know!

Known Issues (Unresolved)

  • You may see this console error: Burst internal compiler error: Burst.Compiler.IL.CompilerException: Error while verifying module: DISubprogram attached to more than one function - I have logged a bug report with Unity on this and am waiting to hear back.

Known Issues (Resolved) Known Issues (Resolved)

  • A MissingReferenceException may be thrown when using the Standard Hierarchy Organizer and hierarchy pooling (setting found on the World)(Fixed in 1.3.2).
  • The About SAM asset may list the version as 1.2.0 and the Last Updated date may be wrong. Check the Package Manager to confirm the actual version of SAM you are using (Fixed in 1.3.2).
  • There is a bug with the Scene Chunk Streamer resulting in correctly added Build Setting scenes not being detected properly (most likely results from spaces being present in the Group Name of your LOD Group) (Fixed in 1.3.1).
  • There are some bugs with the Default Asset Creator when creating both Prefabs and Scenes with the same Creator (Fixed in 1.3.0).
  • An ObjectDisposeException appears after entering Play Mode 2+ times, but only when the Reload Domain setting is disabled (in Project Settings/Editor) (Fixed in 1.3.0).
  • You may see Native Collection Leak errors both in the editor and Play Mode (Hopefully all have been in 1.3.0).
  • Some active tabs in Inspectors and Editor Windows may appear as inactive (Fixed in 1.3.0).
  • A NullReferenceException is thrown when using the SAMInitializer’s InitializeSAM_Gradual method without a SAMSlider or SAMText object assigned (Fixed in 1.2.0).
  • A Compilation Error appears in Unity 2020.3 and 2021.1 if the Addressables Package is not present in your project (Fixed in 1.2.0).
  • There is a bug in the ScaleTransitioner component that makes it not work correctly with the World Designer Tool (Fixed in 1.2.0).
  • When using Unity’s Light Editor Theme, the Main Controls Window of the Loading Blueprint Editor and World Designer Tool makes use of a dark background rather than a light one (Fixed in 1.1.0).

Important Notice about Compatible Unity Versions

We have tested both Terra Slicer and S.A.M. from versions between Unity 2020.3.37f1 and 2022.3.0f1 (but all LTS versions should work).

No testing has been done on 2023 versions yet and you purchase at your own risk for these versions!

Looking For More Information About The Products?

Please use the Asset Store Page Links at the top of the post to find out detailed information about each product!

I’ve found a couple of issues when working with terrain that use up a lot of memory (large groups and/or high resolution terrains). Unity currently has a 2GB limit, which I unfortunately forgot to take into account in a couple of places, like when using the prefab tool and when calculating world grid data. I have already fixed the world grid data calculation issue, and am going to try and do a thorough sweep of any code that might produce problems.

If anyone wants these fixes early, email me with your invoice number and I’ll get you the updated files.

At this time, there is still an issue where trying to build projects can cause out of memory errors. Not sure if this relates to the resources folder being too big, or project size, but I’m looking into ways around the issue. It’s possible using scene loading will avert this problem; that’s something to add to the testing plate for this week.

Again, all of this should only be a problem when using many high resolution terrains. Of course, one of the reasons I created the dynamic loading kit was to reduce the memory footprint during runtime (success) and make creating large high resolution worlds possible (still within sight, but currently a no go), so I am not happy with these issues.

Good news! Using Scenes does indeed get around the 2GB memory limit of Unity. I just got done testing a world made up of 64 2049x2049 (1km x 1km) terrains. The only thing you need to make sure of is to rename your Resources folder (_Resources, for example) so that Unity doesn’t load the assets stored in it.

I withheld from adding a Scene loading method for Unity Indie users (using LoadLevelAdditive) because I felt it was kind of pointless. I figured it would be doing the same thing as the Prefab Instantiator. However, seeing as how using scenes (or asset bundles) is the only way to get around the 2GB limit, I will be adding a new loader immediately that utilized the LoadLevelAdditive method.

More updates to come.

Edit: Seems this was a case of premature jubilation. Although I am able to play the scene when using 64 2049x2049 terrains and the scene loader component, I cannot actually build the project. I am investigating this issue (which goes back to 2010), and actively searching for a solution.

Edit 2: Turns out my folder with all my prefabs got renamed to Resources and I didn’t realize, and that is why the build was failing. I am not sure if there is a limit to the build size when using scenes, since scenes are generated as separate assets. I am going to conduct some test, but for the time being, it looks like large high resolution world are in fact possible!

Looks like there’s a bug in Unity 4.3. The kit worked fine in 4.2, but as soon as I updated the project to 4.3 it started crashing. I’ve submitted a bug report, but for the time being it looks like you’ll have to keep your project at 4.2 if you want to use this kit :(.

Update: The crash only occurs when destroying objects, so a temporary workaround is to use the pooling primary sub controller component rather than the non-pooling one. Keep in mind, however, that this component keeps the objects in memory for the duration of the program (or scene), so if using objects that take up a lot of memory this method shouldn’t be used (though you’re free to try it if you wish).

Update 2: The crash only occurs when trying to destroy a GameObject that has a Terrain Component (aka a Unity Terrain), so if you’re not using a Terrain, you should be okay. Please let me know if anyone else is experiencing crashing!

Good news; I think I have identified the root cause of the crash and believe I can work around the problem. More info to come . . .

I am happy to report that the issue has been identified and fixed, and will be available in the next update (which should hopefully hit the Asset Store sometime next week). Here is a taste of some of the fixes/improvements in that update.

  1. Fixed crash when destroying Terrains in Unity 4.3. It should be safe to update now!

  2. The CreatePrefabs tool, Scene Generation Tool, and Calculate Data button on the World Grid ScriptableObject should no longer cause Out of Memory errors when working with objects/terrains that use up a lot of memory.

  3. Added a new cell object Scene Loader component type: this component is a non-asynchronous loader that can be used by Unity Indie users. Scene Loading is necessary when dealing with object groups that utilize a lot of memory, as loading Resources causes an out of memory errors due to a 2GB (3.5?) limit on the Unity Editor. In order to create this new type, a new base abstract class was created, and much of the logic from the Async Scene Loader component was moved to this base class. SceneLoader and AsyncSceneLoader derive from this new class (BaseSceneLoader).

  4. Fixed a potential bug with the SliceTerrain tool.

  5. Added an error dialog to the GenerateScenesTool that pops up if the user did not select a tag for the Unbound Tag Name field.

  6. Changes to some tool tips.

  7. It is no longer possible to initiate an active grid shift or move if a shift or move is currently in the process of executing. The ControllerCurrentlyExecuting property will tell you if a shift or move is currently in the process of executing. The ShiftActiveGrid method of the DynamicLoadingController class also now returns false if the shift could not be executed, or true if it could.

Note: execution of the shift happens over several frames, so when the ShiftActiveGrid method returns true, the shift has not been completed yet. When the shift is completed, the ActiveGridShift event will fire, but be advised, this event must be fully processed (subscribers must all return control to dynamic loading controller) before another shift can be initiated.

  1. The BoundaryMonitor class was changed so it does not stop monitoring when it detects a boundary has been crossed. Keep in mind, however, the dynamic loading controller will stop the monitor while it is performing a grid shift/move. When it’s done, it starts the monitor. This change is only noteworthy if you’re using the Boundary Monitor for some different use outside of the Dynamic Loading Kit.

  2. Small improvements to existing code in various places.

Interesting. How do you feel about performance, with terrains that are just terrains (not full of trees/grass)? Specifically, when loading/unloading terrains, any noticeable hitches or fps spikes?

Something that would go hand in hand with this (almost a necessity) is being able to specify low terrain detail for distant terrains, and also have something that stitches the borders between distant and near terrains. Any thoughts on this?

It’s hard to say what kind of performance you’ll get, since it depends largely on the terrain you’re using. If it’s any indication, I have run some test on the world in the Island Demo and performance has been really good (this was a while ago, I need to re run the test since I’ve redone a lot of stuff). I am also always open to taking people’s world and running test to see how well they perform using my kit, but of course, those test would not be accurate since my system is different than everyone else (for better or for worse). I’m also in the process of using World Machine to generate large worlds full of high detailed terrain, so I’ll be able to run more substantial performance test.

I’ve tried to limit the performance hit of my own code by spreading the load across frames, although there might be additional things I can do. And of course if using Unity Pro the Async Scene Loader should perform better than non-async scene loading or prefab instantiation. In practice, the AsyncLoadLevelAdditive is not as good as it should be. The docs state that using this method should allow you to load levels with no impact on performance, but this is not the case in reality. Hopefully that can be rectified by Unity in the future, but I doubt it, since I don’t see a lot of clamoring for it.

As for a sort of level of detail system, that’s something I definitely want to add. To be honest I haven’t done any research on that aspect, however, so I can’t speak on the challenges associated with it. Your point about the borders needing to be adjusted is a good one. Stitching the terrains during run-time shouldn’t be a problem.

The update has been submitted. As always, you can get it straight from me if you email my your invoice number.

Here’s a couple more changes:

  1. Small improvements to existing code in various places. Also changed the return types of many methods to IEnumerable (from IEnumerator), in order to remove various StartCoroutine calls. There is now only one StartCoroutine call for each load cycle. This change reduces some garbage generation.

  2. Updated Undo system in Blend Edges and Tileable Terrain Maker tools for 4.3 users. Alphamap undoing is still not working, so I am still using my own system.

  3. GameStateObjectSwitcher was placed in wrong folder before and has since been moved, so you may have a duplicate file error after updating the package from the Asset Store. Delete the .cs file that is located in DynamicLoadingKit_SourceCode if this is the case.

Next I will be focusing on documentation.

I just began working on a comprehensive document that should help you understand and use the dynamic loading kit. Currently it is incomplete and limited, however I will be updating it daily and it should be completed soon. You can download it (and future versions) from my website.

Link

Hi ! this ratter Seams a very interesting and very UNIQUE solution …

Thanks for the Updates / And mproving this SLicing Kit to Dynamic loading …


I read the Full PDF guide : http://deepspacelabs.net/files/Dynamic%20Loading%20Kit_Full_Guide.pdf

And I like the Grid / cells / Method …

The Dynamic Loading Kit utilizes a grid based system, where each cell in the
grid is identified by a row and column number. At any given time, a number
of cells are “active,” which means the objects associated with those cells are
loaded into the scene or enabled. This active grid can move up, down, right,
or left, and doing so activates cells (in the direction of the move) and
deactivates cells (in the opposite direction).

SO as far as i understanded We must :

  1. Setup a World Grid … Were Each Terrain Will be loaded ?

Ok …So Some Questions :

  1. How far Can we go with this Dynamic Loading kit ?
    How Far can we push The Grids ?
  • Can we Have a World grid… lets say like 60 Per 60 rows ?
  1. Is this made just for First person / races ? X/Z Loading
    For example In a case of a ScyFy Flying / With Landing Game …
    Can We Have a Full Cubic X/Y/Z Grid With Dynamic Loading Also ?

  2. Is it Possible ( in the case of a fly game ) to have LODs Substitutions in the distance of Distant cells in the grid ?

  • This that we can See in the far distance the Other grids content… but Then be Swapped by LODs version according Fly Distance …
    • My idea is to have In the Grid LODS Replacements untill Once The Player crosses the Grid “full level load” boundary…
      • This could Should be made in the Editor So we Save load from disck new cells content - but also specify a LOD Replacement a series of Prefabs 1-4 Geometry Lod Prefabs of the Entire Cell that will Load in the distance being the Level 5 a simple Large Bilboard
  1. Could be possible further in thsi development the Loading of Individual “Cubic grids inside each others” ?
  • A friend mine posted here about that Cubic Grid Cubes Areas inside Areas on triggers concept : http://goo.gl/2OqpyK
  1. And About the “GRID CELLS” 1 grid Cell must be Tight Down to 1 Terrain Cell ?
  • Can we for example have many terrains inside 1 Cell in the grid instead ?
  1. Can we with this sistem go over Unity 32Bits Editor Memory limits ? How does the Editor Workflow Works ?
    … Can we for example Select a Cell in the grid / and Save / load and Unload That cell from Editor ?
  • Loading that Cell In the editor and runtime will load also All Objects Contained in that Cubic Cell Space Right ?
  1. How about the Loading Trigger System ? Can that Allow to have More grids inside Grids ?

8 ) Do you have a Roadmap ?
What are your plans for this Amazing extension in the near future ?

Sorry for the Overload of subjects …
But im reaaly interested in make this kind of Better Game Dynamic Loading Management system be possible in unity…
ANd from all the many developers in all unity you are surely the most advanced in your methods to make all this possible from this sistem so far - My sincere congratulations for that !

I think this Product Needs more Bumping and Awareness, as this is one of the most needed features for big Levels
Thanks so Deeply much for your Development. Keep Going !

Wishes of a happy Holidays and Most Prosperous new Year.

Best Regards !

Hey Triax employee :), thanks for your interest!

Let’s tackle your questions.

There should be no limit to the number of rows and columns you have in your grid. Unity does have some memory limitations, where if your terrains in your scene take up too much memory, Unity will crash. This means when creating your world you will have to be careful, and you will have to use one of the Scene Loading components when using the Dynamic Loading Kit (rather than the prefab instantiation component).

However, the World Grid asset doesn’t require terrains to be in the scene in order for its data to be calculated; the terrains only have to be stored as prefabs in the Resources folder. The data calculation method has been optimized to free memory after each prefab is processed, so theoretically it should be able to process an infinite number of terrains (or other objects). Again, you’ll want to use a Scene Loading component, so once the data for the world grid has been calculated and you’ve created the scenes (using the Scene Generation Tool), you’ll want to rename your Resources folder to something else so Unity doesn’t try to load it when building your game.

Unfortunately it is only designed to work on a 2-dimensional grid at this time. Honestly I never really thought about doing a full cubic grid; I will look into that and see how much work it will take. I have some other stuff to finish first though, so it’ll probably be at least two months down the road before it would be added.

Keep in mind also, though the kit only works on a 2D grid, you can use it both of the X-Z plane and X-Y plane, which means you can use it when making a 2D side scrolling game.

A LOD system is something I have thought about and definitely want to implement. One hurdle another user brought up is making sure the borders of the lower resolution terrains match up with the borders of higher resolution terrains. Another issue I can foresee is in the transitioning from a lower resolution object to a higher resolution object. My plan is to introduce some kind of user defined component that controls the transitioning, but I am not sure how feasible that is. Other than those two issues, I don’t believe a LOD system should be very hard to implement.

I read through about half of that post, and wow; there are some very interesting ideas there to say the least! Unfortunately, while the cubic grid idea you mentioned before definitely sounds doable, I am not sure I could incorporate the ideas from that post with my kit. I believe it would involve rewriting a ton of my own code, to the point where it would be a separate project. If you wanted to try and implement it yourself, I would be happy to share my experience working with dynamic loading and help out in any way I can!

Yes you could, but I am not sure if you’d want to. You have complete control over the load dimensions. Take a look at Chapter 1, Section 2 in the full guide document (if you don’t see this section, download the newest version from my website!). Basically you can control how many terrains/objects are loaded at any given time, so there’s nothing stopping you from having 25 grid cell locations loaded, or 36, or whatever you want (game performance and memory usage being the only limiting factors). If you did want to implement multiple terrains in a single cell, it will take some work.

  1. Create an empty game object, then make all the terrains you want in a single cell children of this game object. This object will serve as the main cell object associated with the cell, and when it’s loaded/destroyed the child terrains will be loaded/destroyed.

  2. The World Grid will not be able to calculate the dimensions for the grid cells, since the parent game object has no dimensions. You will need to work out the dimensions for each cell yourself, and create a .txt (or other TextAsset) with the necessary data (see example.txt in the asset package or the full guide for details).

  3. This will ensure the terrains are loaded correctly, but unfortunately the terrain neighboring will not be handled by the dynamic loading kit. You’d have to do this yourself, which might be a bit of a pain.

If you can make an argument for why this functionality would be useful, I will be happy to try to implement it myself.

Yes, you should be able to go over the Editor memory limits, but it requires that you make use of scenes (or Asset Bundles, which will be added later and only available to Pro users). I say “should” because I have performed test on terrains that use a ton of memory and have had no problems with building my sample project, but there is always the possibility that I may have missed something. If for some reason you do get editor memory crashes when using my kit, and you are taking the correct steps (using scenes), and we cannot find a solution, I will be happy to offer a full refund as long as an invoice number is provided. I am confident you will not experience any problems.

As for loading cells in the grid, there is functionality on one of the components that allows you to load the entire grid, but obviously that is not a viable option when dealing with terrains that eat up large chunks of memory, as you will get editor memory errors if loading every cell. If you have not yet created scenes for your cell objects, you can simply drag the prefab for whatever cell you want to load into the editor; you’ll just have to make sure to apply changes you make. This is not ideal, since the prefabs will not be positioned correctly when dragging them into the editor.

I will probably change the grid loading functionality mentioned previously so that instead of loading every grid cell, you can specify a range of cells (you’d specify a row/column and then the number of rows/columns you want to load, so for instance if you wanted to load the first two cells on row 1, and the first two cells on row 2, you’d specify row 1/column 1 and 2 rows/2 columns.

Finally, if you have already created scenes out of your prefabs, you can just open the scenes to edit the terrains/other objects in that scene (and just save the scene when you’re done editing). Obviously with this method you can only view one grid cell at a time, so it may not be ideal.

I have rethought the triggering system and I don’t think that’s something I am going to add, the reason being that it is really completely separate functionality from what my kit offers. There is no way to merge a triggering system with the dynamic loading so they both can function at the same time (no way that I can see at least), so there is really no point to implement it.

If you did want a triggering system, I don’t believe it would be hard to do. You’d just have a script on a game object with a collider that has a public variable where you drag the object you want to load when the collider is crossed. When the collider is crossed the appropriate trigger or collider method will fire and in that method you’d load the object. If using terrains you’d have to do some terrain neighboring, but that wouldn’t be too difficult.

Right now I am working on completing the documentation/video tutorials/etc.

After that, I will probably create a video or two that details the benefits of using the kit (mainly the memory usage benefit). I might also create a Demo.

As far as adding functionality to the kit, the next addition will be adding the Asset Bundle Cell Object Loader component for Pro users. I don’t think this will take much time, but I will need to do some research on Asset Bundles since I’ve never used them before. After that, I plan on adding a more sophisticated partial pooling primary cell object sub controller component. Once those two components are complete, I will begin work on the LOD system, as well as any additional changes I think up or others request.

The full guide is my number one priority, and is being updated daily. I really want to get this done, especially the parts detailing how to create your own components. From the beginning I knew creating a comprehensive dynamic loading solution would be impossible, so I tried to make adding your own functionality as easy as possible. While things like the 3D grid you mentioned previously will need to be added by myself, this customization should allow for better integration with individual projects, and should also give the kit a better chance at being future proof. For instance, down the line Unity may introduce a new way to load objects into the scene, and you may want to use that method with the dynamic loading kit. Because of the component based nature of my kit, as well as the easy customization (well, it will be easy once the documentation is complete :wink: ), adding a new loading method is relatively painless!

Thank you for those kind words! I completely agree about the bumping and awareness; I will definitely ramp up my own efforts in that department once I get some more of the documentation/video tutorials/etc. completed. In the mean time, anything users can do (reviews here and on the asset store) is much appreciated and goes a long way to helping me out!

The package has been updated and the current version is 1.52. This is minor update, with the following two changes.

  1. When setting the data on a world grid asset for an object of type “Other_No_Renderer”,
    you can now simply drag the Text Asset that holds the required data onto the appropriate
    field, rather than typing the path where this file is stored.

  2. Changed ShiftActiveGrid’s return type from void to bool. The returned bool return true
    if a grid shift was initiated, or false if a shift was not initiated (if the grid was locked
    or the input directionToShiftGrid was None).

If those changes are of interest to you, feel free to update. If not, you hold off until the next update.

WHOW ! AAAMAZING !! You got here a Real Amazing product Done and Even more to become …
this Product Power Is even better than what i was expected …

And man ! Finaly someone that can Write As much as me About this subjects …
I just Love Passionate people about is work as you Big Friend !

Thanks so much for the Long Explanations / And Im Extremely Sorry for mess up with your Development time …

Hope my Input helps Debug Your product in What it is and will be also for other Potential Customers…
I think this extension power is reaaly unknown, and people are not seeing what this can do actually .

In a Short Resume i would say its the Same as bringing the Exclusive power of HeroEngine Seamless 2 levels into unity you know :
http://hewiki.heroengine.com/wiki/Seamless_World_2.0
http://hewiki.heroengine.com/wiki/Seamless_world
http://hewiki.heroengine.com/wiki/Seamless_area_link

Less technical people im sure cannot grasp the real power of seamless Dynamic Level loading …

THANKS FOR YOUR AMAZING SUPPORT !

Im completely Sold out At this point ! Soo…

YOU GOT HERE A NEW CUSTOMER …
And hope many more Follow Up my Enthusiasm !!

Gona try to buy this Extension before new year !
( As right now im dealing wth late cristmas Gifts and preparations and stuff ) ; )

This Development reaaly Deserves All Support one can make and should have !

THANKS FOR EVERYTHING ! In this product Development support …
Keep Improving it please ! I will be back …

Happy Holydays !!

TRIAX STUDIO Team Admin

Wow, thank you so much for the support! I hope you are as happy with the product once you purchase it ;).

As for those links, I don’t have experience with HeroEngine, so I’m not familiar with their Seamless linking technology, but from what I gather, you are correct that my kit can be used to implement similar functionality. Even though my kit works by loading entire rows/columns of cells (not the whole world grid, just however many cells are defined by the active grid dimensions), there’s nothing stopping you from only having one cell contain a terrain/other game object, and the other cells on the row/column being empty. The single non-empty cell could act as a corridor where the adjacent level is loaded, much like the seamless linking technology does.

The only limitation at this time is Unity’s loading methods. While LoadLevelAdditiveAsync is the fastest method and does a good job loading assets in a background thread, the actual moment when the assets are completely loaded still incurs a performance penalty. I have to think by Unity’d wording in their documentation for this method that this performance penalty is unintentional. The relevant quote:

“This allows you to create a completely streaming world where you constantly load and unload different parts of the world based on the player position, without any hiccups in game play.”

I am going to start a thread on this matter in the hopes of find out if this method is performing as intended, and if not, hopefully bring it to Unity’s attention so they can fix it.

Sorry, went on a bit of a tangent there. Thanks again for the kind words!

Just submitted another update to the Store which should be available in about a week. The main feature of this update is the ability to define either the horizontal axis as endless, vertical axis as endless, or both axes as endless. Previously there was just a single option that when checked, made both axes endless.

This new functionality is especially useful for endless runner type games, where you might just want your terrain or game world to run endlessly in a single direction.

Here’s the full change log.

  1. Changed the endless world functionality. Previously, checking the “Endless World” option on the Dynamic Loading Configuration Form would make the world endless on both the horizontal and vertical axes, which may not be desired behaviour. This option has been replaced by two new options, “Endless Horizontal Axis,” and “Endless Vertical Axis.” Checking both options will produce the same effect as the previous single option, or you can check only one or the other to make the world endless on that axis. This is especially useful for endless runner type games, where you have a single terrain/tile piece which you wish to extend endlessly in one direction.

  2. World Grid Asset Creation has been improved. Instead of being created in a default folder, the world grids are created in whatever folder you have selected. The folder must be actively selected for this to work (blue highlight - if the folder has a light grey highlight it will not work). Alternatively, you can right click a folder or inside a folder and choose “Dynamic Loading Kit/Create World Grid.”

  3. New Property added to The Dynamic Loading Controller component. This propery (called ShiftInProgress) will tell you the Direction of the current active grid shift in progress. It will return Direction.None if no shift is in progress.

  4. New option called “Destroy After Starts” added to the Dynamic Loading Configuration Form. This option, when checked, will tell the form component to destroy itself after all Start Methods have been called. Useful if you want to free some memory. This should only be used if you are prepared to retrieve the Dynamic Loading Controller component(if needed) using the GetComponent method.

  5. Added Word and PDF versions of the Dyanmic Loading Kit Full Guide document. This is a work in progress and is constantly being updated. New versions will be included in future updates, or in the mean time you can go to http://deepspacelabs.net/files/Dynamic%20Loading%20Kit_Full_Guide.pdf.

The update described in the previous post is now live on the asset store!

Hello all,

I wanted to take some time to talk about what I’m currently working on, and to also (hopefully) get a little feedback on some planned improvements. I’m going under the assumption that anyone reading this has some knowledge with how my kit works. If you don’t, you probably won’t understand this, but feel free to ask questions and I will explain.

The main component that drives my kit is the Dynamic Loading Controller; if you want to manually shift the active world in a certain direction or move it, you do so by calling the appropriate method on this component (let’s call these commands). Or if you’re using a Boundary Monitor component, when the player crosses a specific boundary, a signal is sent to the controller and the appropriate shift command is initiated.

It’s important to note that the actual shifting and moving actions generally occur over several frames, which helps spread the performance impact in order to avoid massive game hiccups. Currently, when one of these shifts or moves are in progress, the controller is locked down, and any additional shift or move commands are ignored until the current action completes.

I do not like this approach personally, so I’ve been considering a change that will allow you to queue commands. So, for example, if a right shift is in progress and a down shift command is sent, the left shift will execute immediately after the right shift completes.

Adding such a system to the current implementation would not cause any problems, but there are some additional changes I am working on that confuse matters a bit. Basically these changes amount to adding three different states to the Dynamic Loading Controller, which can be changed via the following methods:

public void DisableController()

This method disables the Dynamic Loading Controller. Disabling the controller means any present Boundary Monitor is disabled and all active cell objects are disabled (and most likely destroyed, though that depends entirely on how your sub controller components are setup).

DisableCellObjects()

This method disables all active cell objects. The cell objects are guaranteed to be deactivated, and depending on your sub controllers, may be destroyed. You’d use this option if you want the dynamic loading controller and boundary monitor to continue tracking the player and shifting/moving, but you don’t want terrains or other cell objects to be displayed. Why would you want to do this? I have no idea, but I think it could be useful to someone :).

DisableMonitorIfPresent()

This method disables the Boundary Monitor if one exists. This will stop the player from being tracked, effectively shutting down the dynamic loading of the world. Note that you can still manually shift/move the world if you choose, and using this method does not change the state of cell objects, so if they’re currently visible, they will remain visible. You can use this method to freeze the world in a specific state.

EnableCellObjects()
EnableMonitorIfPresent()

These methods will reverse the effects of the two previous methods. Note, however, that calling these two methods will have no effect if the controller is currently disabled.

EnableController(bool enableCellObjects, bool enableBoundaryMonitorIfPresent)

Enables the controller, and additionally enables the cell objects and Boundary Monitor if the corresponding parameters are set to true.

Now, why does the addition of this functionality make the queueing I discussed before more complex? Quite simply, the problem is I don’t know what you want to happen.

For example, say a left shift is currently executing when a down shift command is sent to the controller. Because a command is being executed already, the down shift is added to the queue and will occur after the left shift has completed. But what happens if you call the DisableController method at this time? Should the controller be disabled immediately after the current command (the left shift) is completed, or after all queued commands are completed (in this case, just the down shift is in the queue, but in other cases, there might be several actions).

Like I said, it’s impossible to know what you want to happen in this case, and in several others. With that in mind, there are three options I am considering.

  1. Assume that all commands should be executed in the order that they arrive.

  2. Assume that disable/enable commands should be executed as soon as possible. This means they will be executed after the current command has finished executing, and after any other enable/disable commands that were previously sent in.

  3. Add a new ExecutionPriority enum type that will allow you to specify when the command should be executed. Something like:
    a) ExecuteAsSoonAsPossible
    b) ExecuteAfterCurrentCommandsInQueue
    c) ExecuteAfterCommandQueueIsEmpty

Option a) would be the same behaviour as described in number 2) above.

Option b) would simply add the command to the current command queue.

Option c) would ensure that the command queue is empty before executing the command. This means that other commands added to the queue (via option b) would execute before the command with option c), even if the commands were sent in after the command with option c) was sent in.

So, what do you guys think (if anything) about all this. Any and all feedback is welcome!

If you made it this far, thank you, thank you, thank you! And another thank you if you provide some feedback ;).

Hello all, time for another update!

I’m going to be making some changes soon that will improve the functionality of the kit, but unfortunately will also break existing projects using the Dynamic Loading Kit.

The reason for this is two fold:

I am going to be moving the World Grid scriptable object class into the dll. This is necessary for several reasons that I won’t get in to. I’m not actually sure if this will break anything; I still need to test the change and see.

The second change will definitely break things, but don’t worry, it won’t be hard to make the necessary changes to get your project up and running again. Basically I am going to be removing the Dynamic Loading Configuration Form component and adding two new components: The Active Grid component and World Component. The options you previously setup in the DLCF will be split between these two components.

These changes will allow for two awesome new features:

  1. The ability to have multiple players in a single player game. To do so, you just added multiple Active Grid components. Note that you don’t necessarily have to have a player associated with the active grid, but “Dynamic Loading” won’t work without one. Without a player, you have to manipulate the grid manually.

  2. The ability to have multiple worlds. Again, to do so you just add multiple World components. Each world is associated with a World Grid (either different ones or the same one). This will allow you to combine different terrain groups easily and a host of other possibilities.

In addition to these features, I will also be adding support for 3D worlds! Unity terrains can only operate on the 2D XZ plane, but if using other game objects, you will be able to utilize this new world type! In addition to rows and columns, 3D world will utilize a new property; layers! Layers operate on the Y axis, while rows operate on the Z axis and columns operate on the X axis (note that this is only for 3D worlds, you can still have a 2D XY world where rows operate on the Y axis; for a 2D side scrolling game for example).

With these three new features, there are a ton of new possibilities! Expect these changes in a week or two!

Nice :3