Uniblocks: cube-based infinite voxel terrain engine

Hi!

I am been reviewing your asset. Would it be a lot of work to make the player fly around or does it just need a tweak here and there?

Thanks!

 

The player control scheme is not a part of this asset, making the player fly around would be something you'd need to do on your own or use some other solution. Of course Uniblocks will work with any player control setup readily, so I don't think you'd have any problems integrating it.

 

Thanks maap, understood! I went ahead and created a controller just to fly. Works with no issues

 

Is the Android apk demo an updated version or an old one?

 

The Android demo is an old version, but there weren't any changes in the latest update that would affect the demo. The PC demo was updated only to improve the visual quality a little (better lighting, etc).

 

Hey Maap, I was just checking in to see if you had done an update at all, and it appears that the link to your asset is now broken, it just redirects to the main asset store! Not sure if its just me or if anyone else has this, but other assets seem to work fine in the store page.

 

It was disabled without any warning because I didn't have a website linked in the publisher info. It's fixed now, just waiting for them to re-enable the package now.

 

Hey maap,

Downloaded this a few weeks ago and love it but you have missed a gaping flaw in performance!

Basically never call GetComponent or FindWithTag unless you really have to (in most cases you dont) and you shouldnt be storing chunks as GameObjects! If you instead store everything as a Chunk you see a far stabler FPS.

I could be wrong, have yet to sleep But to me I see no reason to store things as GameObjects in ChunkManager.

Hope this helps if not let me know and i shall endeavor to explain better once I have slept!
Jason

 

Chunks aren't actually stored as GameObjects anywhere, but I guess I understand your point. Perhaps a Chunk list to store all the chunks might be better in terms of performance than searching for GameObjects through FindWithTag, but it adds a whole lot of extra complexity, and other potential performance issues, since operations on lists can be quite costly. In this case I just chose the simpler option, even if it might be slower.

In any case, about 80% the performance cost when spawning/modifying chunks comes from building the mesh, so even if I removed every single GetComponent or FindWithTag the performance improvements would not be very significant.

Basically, from what I can tell there are far bigger performance bottlenecks than a few GetComponent or FindWithTag calls, and the extra complexity of managing a list of Chunks is probably not worth the marginal performance gain (assuming there would be any gain at all). Plus it's definitely not something that would be easy to modify, it's a very delicate and complicated issue and would require rewriting a lot of the core code, which I'd really rather not do at this point.

Looking through the code now I did notice one spot where some GetComponent calls could perhaps be eliminated - in the Chunk, the neighbor chunks could be stored as Chunks instead of GameObjects. That seems like it would be relatively easy to change so I'll try to do this in the next update, assuming it doesn't cause some unexpected problems.

 

Hello!

Is it possible to configure your engine so it will build a 2d map instead of 3d, i.e. if one can make a terraria-looking game with this engine?
If yes;
does it require much changing?
What needs to be changed?

 

It's pretty easy to do. Check this post:
http://forum.unity3d.com/threads/un...ite-voxel-terrain-engine.226014/#post-1550291

 

Hi maap, the asset is still not available in the store,. Any news when it will be available again?

 

I wish I knew myself. I've sent two emails to the asset store team, haven't received any reply yet.

 

But is there any other way to buy your engine, since it seems asset store eliminated it?
Do you know why they did it?

 

You can send me $75 directly via paypal (rawlionworkshop@mail.com) along with your email address, and I'll send you a download link for the package as soon as I receive the payment. I know it's not a very elegant way, but until the asset store situation is resolved, that's all I can do.

It was disabled because I didn't have a website linked in the publisher profile. Pretty annoying that they'd disable my asset without any warning just because of that...

 

Thank you @maap. I send you the payment just in a few minutes.

 

Don't underestimate these calls they can be expensive, especially find with tags in a game like this with a Lot of objects in the scene. One thing I miss spoke in my lethargy was a stabler FPS, its a stabler loading time (FPS was only effected slightly in a positive light). On one PC we switched from seeing single chunks spawning to rows of them at a time, sorry about that.

You really don't have to do anything complex to see a significant change. I barely scratched the surface of the source when I found this issue.

 

Hi! (first, sorry for my very bad english =P)

I have serious performance issues with uniblocks. In my game you can travel with wings, and the chunk spawn speed is a big problem. (the player can fall out easily before the chunk is generated, and the flying speed isn't high).

But I have a question. My game is an exploration rpg, I dont need the possibility of create or destroy blocks.

Is there a way to deactivate or modifiy the engine to completely disable this feature? And maybe generate a unique "chunk collider" per chunk? instead of "voxel collider"?.

I'm having this serious performance issues with no changes in the terrain generator script, and I want generate with 2 or 3 layers of perlin noise. (completely impossible in terms of performance). Any tip?

 

If you don't need to change the voxels at runtime, maybe it would be a better idea to use static meshes, loaded from a file? You can first generate your terrain in Uniblocks, and when it's done, save the generated meshes at runtime (like this). Then you could either put all the meshes manually into the scene, or let chunks load these saved meshes instead of generating new ones every time, which would improve loading times a lot.

Of course this only works if you can pre-generate the entire terrain. If you must generate terrain at runtime, or you want infinite terrain, you'll have to generate the meshes at runtime. In this case there isn't really much that you can do to significantly improve the performance, besides tweaking the Uniblocks performance settings. Reducing the chunk spawn distance and height range will help a lot with loading times. Also make sure that chunk spawn limit, chunk saves limit and mesh updates limit are as high as possible without causing FPS drops or stuttering.

You can disable editing voxels just by not using the DefaultVoxelEvents (or deleting sections for block editing from the script), but that doesn't affect the loading speed at all. You can disable collider generation completely, which would improve loading times significantly, but then you'll probably need to use some clever custom solution for terrain collision.

 

I'll try looking into it more before the next update. I don't know if it would be that simple to fix, but there might be some places I could tweak for some performance gains.

 

I played with the uniblocks performance settings a lot, and the best I can achieve is with chunk spawn distance of 9 and mesh updates limit to 4. I have a i7 2700k (4.8Ghz) and a GTX 670 and I only get 40fps with these settings.

9 for spawn chunk limit is a very low value (like minecraft with very low render distance) and with a high end PC for 40fps.

If I can't do nothing with your plugin, I dont need uniblocks. I expected some world voxel generator like cube world game. (more than 40 chunks distance, lot of render distance, and working very good in low performance laptops).

You accept a refund of the plugin?

 

I'm very sorry that Uniblocks didn't meet your expectations. I suggest you contact the asset store team for a refund, I can't actually grant refunds myself.

Also just to be clear, the performance of Uniblocks is not nearly as bad as you make it seem. It won't be able to provide instant loading times with hundreds of voxels of render distance, but with more realistic loading times (suitable for walking at a regular speed, not flying), I'm getting stable 40 fps with 14 chunks of render distance (that's a radius of 224 voxels, which is not small by any standards) on a machine much worse than yours.

 

No offense maap. Definetely you are a great programmer and you offer a very good support. Simply I can't make the game what I want with your engine.

Greetings

 

Hi maap, I gave another chance and I saw something strange.

The world is generated arround the player position (or gameobject position) with the chunk loader script.

The chunks appears in rows, but vertical sides are generated much faster than horizontal sides. This can't be right, no?

I recorded a video:

You can see in the video the settings. (at the end)

 

I think this happens because there are multiple layers of chunks being spawned vertically. With the faster side you're only seeing one layer, but you're not seeing the chunks above and below (because they're empty) that are being spawned between each horizontal layer. With the chunk height set to 0 it seems both sides take about the same time to spawn.

 

You right, but if the "invisible vertical chunks" (3D space, if I understand correctly) don't generate mesh, why the slow load time?
The generation of mesh and colliders should be the same for every chunk. I don't understand why one side of chunks load much faster than other x_x

 

The problem is that empty chunks still go through the process of generating a mesh. It doesn't take as long as non-empty chunks, but it's still a significant amount of time.

But the good news is, I did some testing and it seems that you can indeed improve the loading speed here, by disabling the mesh generation for empty chunks completely. However to do this we need to have some way to know which chunks are actually empty.

What I did was I added a bool Empty to the Chunk, which is set to either true or false during the generation or loading of data, either through the TerrainGenerator or ChunkDataFiles. (in TerrainGenerator, after the generation is done compare the first voxel to all others in a loop, if a different voxel is found, set Empty to false. In ChunkDataFiles, at the beginning of the DecompressData function, set Empty to true if data.Length == 2.

Then in Chunk's RebuildMesh function I added an if (!Empty) check, which would prevent the mesh rebuilding completely if the chunk is empty.

The Voxel.PlaceBlock, Voxel.ChangeBlock and Voxel.DestroyBlock functions should set the Empty bool to false, since if a voxel was edited, in most cases the chunk will not be empty any more.

One final thing, in ChunkManager's SpawnVoxelsForFreshChunks function, wrap the line
UpdatesThisFrame += ChunkManager.UpdateValue;
in this if check:
if (!chunk.GetComponent<Chunk>().Empty)
so that empty chunks won't count towards the chunk updates per frame.


Keep in mind that this is a quick and dirty fix, and it's possible that it doesn't work perfectly and causes some problems somewhere. I'll get this working properly in the next update which I'd like to release soon, because this is indeed a pretty big oversight on my part, so thank you for pointing it out.

 

Another thing you should Really look into is saving each chunk individually and only saving and loading them as needed via PlayerPrefs. Our scene starts loading almost instantly now on a pretty slow processor at that.

This also lets you effectively explore without generating more than 4MB of garbage....

Video for reference:
https://dl.dropboxusercontent.com/u/29289192/Faster loading and Exploring.mp4

Really dude I like the framework its a great starting point but you have missed some really fundamental stuff here! Saving and loading an entire region file each time you save a chunk is just crazy

 

Amazing. Waiting for the next update.

 

I know what you're taking about and I haven't actually missed it, I simply haven't been able to find a better way of doing it.

Storing each chunk in it's own file takes way too much space. Region files are necessary, and when saving a region file I need to read and write the whole thing. If there is a way to insert data into a file without reading/writing the entire file, please let me know!

In fact I'd very much appreciate it if you could tell me in more detail what you did to achieve this performance boost. I don't understand at all how you use PlayerPrefs for saving and loading chunks. Surely you're not actually storing the chunk data in the registry?

 

It might take a while... Even if I published the update today it would probably be weeks before it's approved. The asset store team seems to be extremely busy lately (or on vacation perhaps...).

 

I wouldn't worry about storage, its your smallest concern in this day and age were the average HDD is probably about 1 TB. I strongly doubt individual chunk files are bigger than a few MB.

Anyway for saving them individually that was more of a suggestion if you had a good reason for avoiding PlayerPrefs. Otherwise I strongly recommend you look into them, quick google will give you plenty of tutorials.

As for my exact implementation I used this:

http://wiki.unity3d.com/index.php/ArrayPrefs2

Then in ChunkDataFiles:

Code (CSharp):

1.     public static void DecompressData(Chunk chunk)
2.         { // decompresses voxel data and loads it into the VoxelData array
3.  
4.             int[] data = K2Saving.GetIntArray(chunk.ChunkIndex.ToString());
5.  
6.             if (data.Length == 2)
7.                 chunk.empty = true;
8.  
9.             int length = chunk.GetDataLength(); // length of VoxelData array
10.             int i = 0, currentVoxel = 0;
11.  
12.             try
13.             {
14.                 for (i = 0; i < data.Length; i+=2)
15.                 { // this loop will stop once the VoxelData array has been populated completely. Iterates once per count-data block.
16.  
17.                     int currentCount = data[i]; // read the count
18.                     int currentData = data[i + 1]; // read the data
19.  
20.                     int ii = 0;
21.  
22.                     while (ii < currentCount)
23.                     {
24.                         chunk.SetVoxelSimple(currentVoxel, (ushort)currentData);// write a single voxel for every currentCount
25.                         ii++;
26.                         currentVoxel++;
27.                     }
28.                 }
29.             }
30.             catch (System.Exception)
31.             {
32.                 Debug.LogError("Uniblocks: Corrupt chunk data for chunk: " + chunk.ChunkIndex.ToString() + ". Has the data been saved using a different chunk size?");
33.                 return;
34.             }
35.         }
36.  
37.         public static int[] CompressData(Chunk chunk)// returns the data of chunk in compressed string format
38.         {
39.             List<int> data = new List<int>();
40.  
41.             int i = 0;
42.             int length = chunk.GetDataLength(); // length of VoxelData array
43.  
44.             ushort currentCount = 0; // count of consecutive voxels of the same type
45.             ushort currentData = 0; // data of the current voxel
46.  
47.             for (i = 0; i < length; i++)
48.             { // for each voxel
49.  
50.                 ushort thisData = chunk.GetVoxelSimple(i); // read raw data at i
51.  
52.                 if (thisData != currentData)
53.                 { // if the data is different from the previous data, write the last block and start a new one
54.  
55.                     // write previous block
56.                     if (i != 0)
57.                     { // (don't write in the first loop iteration, because count would be 0 (no previous blocks))
58.                         data.Add(currentCount);//add the count of the voxels
59.                         data.Add(currentData);//and then which voxel
60.                     }
61.                     // start new block
62.                     currentCount = 1;
63.                     currentData = thisData;
64.                 }
65.  
66.                 else // if the data is the same as the last data, simply add to the count
67.                     currentCount++;
68.  
69.                 if (i == length - 1)// if this is the last iteration of the loop, close and write the current block
70.                 {
71.                     data.Add(currentCount);
72.                     data.Add(currentData);
73.                 }
74.  
75.             }
76.  
77.             return data.ToArray();
78.  
79.         }
80.  
81. public void SaveData()
82.         {
83.             int[] compressedData = ChunkDataFiles.CompressData(chunk);
84.  
85.             K2Saving.SetIntArray(chunk.ChunkIndex.ToString(), compressedData);
86.  
87.             //WriteChunkData(chunk.ChunkIndex, compressedData);
88.         }

Note that K2Saving is just what I have called the ArrayPrefs file linked above. Player prefs are Insanely simple to use and are cross platform. They are also incredibly efficient since, if I remember rightly, it essentially stores all data in a lookup and only saves it on application quit or an interval you set. We save and load with every block change with 0 noticeable impact on performance. This way will also only store one file for all your data

 

Thank you for sharing, that is a very interesting method. I think I'd like to include it as an alternative storage method, in addition to the default one. There are some advantages to storing the world data in a regular folders, such as the ability to easily transfer worlds between different machines, but having the option to get better performance at the cost of convenience seems like a good idea.


Also regarding the storage space, individual files actually take A LOT more space than the region files. The data of a chunk could be just a few bytes when compressed, but the file will always be at least 4KB. With thousands of files this adds up very quickly.

 

Hello,
I bought Uniblocks 2014-07-14, I did not find it any more on my assets list.
Do you know why this happens?
Thanks

 

The last minecraft world I was playing was about 140MB, per world. I think you will be fine

Even tens of thousands of files at about 4kb is about 40MB total, which is nothing. I think if you starting hitting world sizes of about half a GB then you can start to be concerned about files sizes but even then its still not a major concern compared to a stable FPS. If it takes someone ten minutes to transfer their world to a friends PC they will wait, if the game runs slow all the time they won't bother with it.

To put it in perspective League of Legends need about 3GB HDD space and World of Warcraft currently needs about 25 GB.. These days people will barely think twice about even a GB install, its just not worth worrying about a 40MB file/files

 

The package is currently disabled. I'm still waiting for it to be reenabled, but in the meantime if you need to download it again, you can send your invoice number to rawlionworkshop@mail.com and I'll send you a download link.

Sure, you're probably right. It just feels wrong to have a world take up 40 MB when the actual data only takes a few hundred kilobytes. The best option would probably be to just let the user choose between faster loading or smaller files.

 

Hi Maap, is any update coming soon?

 

I do plan to release an update soon, though not that soon (a few weeks perhaps?). It'll be mostly for the performance fixes mentioned previously in the thread, otherwise no major changes.

 

I ended up getting curious and looking up where PlayerPrefs are stored on PC and you are right (if this is what you meant when you mentioned registries previously) that they store values in the registry. Our first time using Unity for a PC project, doesn't do this on other platforms so far as I know so a mistake on our part.

Anyway the implementation I mentioned before will still apply you will just need to emulate how PlayerPrefs works and store text files instead, then it should give you the same performance with worlds you can share. All it is essentially doing (as far as I could tell from a quick glance) is keeping your values open in a hash map and only writing the map at set intervals and when the player quits the app. Saves you writing two systems.

We are not going to bother implementing this until development is closer to alpha (we have a quick system, why change it sort of thing) so no examples sorry but thought I would share our insights anyway.

 

Ah yes, I totally get it now. It's such a simple thing that I can't believe I missed it. I think I could actually keep the region files with this, since the files would be written only once every set interval instead of once for each chunk.
Thank you for posts, you've been very helpful!

 

No worries glad I could help

 

Hello!

Can you add Web demo with 256x256x256 map? Without infinite generated terrain.
I want to use your engine at AOS style game, and it very important to get 60 fps to play.
I cheked your demo with infinititr generated terrain and its to slow 20-40 fps looks.

Thank you!

 

https://dl.dropboxusercontent.com/u/262192534/Uniblocks 1_1 performance test web.html

Here's the demo for you, 272x272, with an FPS counter included. You should see stable 60 FPS once the terrain is fully loaded. The loading itself does take a long time, but if you're not using infinite terrain you only need to do it once at the start, and once it's loaded you don't have to worry about performance at all. Also, the loading times should be improved significantly in the upcoming update.

 

Wow it works fast! I think you should update your demo at asset store. Because first impression was that your engine is slow.

I got some questions before buy:

1) Can I add ready FPS camers asset to this engine? (UFPS or FPS Kit)
2) Can I add phisics to this engine?
3) Do you have map editor? How I can create maps ?
4) How I can adjust lighting to get more realistic picture with shadows? http://gyazo.com/98e17ef0fb440fe1ffaae79a72f0bcd0

Thank you!

 

Yeah, it's really only the loading that causes lower FPS, and in the original demo if you're walking around all the time, it will be loading all the time. In any case, the loading performance should be much better in the upcoming update, I'll update the demo once the update is released.

1) Yes, you can use any camera or control setup you want without any problems
2) Yes, the terrain uses standard mesh colliders which work readily with Unity physics
3) You can edit the maps using the demo scenes included, they allow you to place and remove blocks and save the map. You can also make your own map editor pretty easily, the functions for placing blocks, saving the map, etc, are all easily accessible to use in your own scripts.
4) Uniblocks works with standard Unity lighting and shaders, including dynamic shadows etc. To achieve the look from that picture you'd probably only need to tweak the colors of the ambient and main light, and maybe add some effects such as bloom or SSAO (these are available in Unity Pro).

 

How this bug can be fixed? http://gyazo.com/2acccaff9ae55b0dae556219911be20c

When I try to jump and place block under my feet. And I fall into that hole.

 

It's not really a bug, it's just that the default block placing setup doesn't actually check for player collision at all.

You can add this check in, for example, the DefaultVoxelEvents' OnBlockPlace function. Before actually placing the block, first check whether the voxelInfo's world position is the same as the player's world position (rounded to int). You can use Engine.VoxelInfoToPosition to get the world position from the voxelInfo. Then, if the VoxelInfo of the block being placed is at the same world position as the player, prevent the block from actually being placed.

This should work for most purposes. If you also need to check collision for other characters, or a player that's bigger than one voxel in size, you might need some more advanced collision checks, but the general principle is the same.

 

Hello maap!

We trying to connect Unibloks with Photon Cloud. And got some questions:

1) How to generate flat map with 1 cube height?
Because we need to test multiplayer with simple map.

 

This terrain generator script will generate a flat dirt map, just import it into your project and replace the ExampleTerrainGenerator attached to the Chunk prefab with this one.

https://www.dropbox.com/s/i1nlqvd7x1w4aw6/FlatTerrainGenerator.cs

 

Hi maap, I have a trouble. (ignore my bad english please =P)

I want to set "is trigger" for a collider for a block, but in the block editor isn't possible, and if I set the block with no collider, the chunk is generated but with a child object with the trigger collider, and without my custom scripts.

I have 2 layers for the terrain generator (ground and water) and I need customize the water for get character interaction.
I set the block with the components of my working water object, but nothing works.

btw, any news about the update?