Uniblocks: cube-based infinite voxel terrain engine

Thanks but I mean if the landscape is procedural created, there is no landscape visible in editor where I can place prefabs, right? Since the landscape will generated during runtime?!

 

Landscape is only being created during runtime right. You can see it's voxels in the Editor during runtime only.

 

Hello again , Just wondering if anyone has taken a look at my code i posted a while ago and if so has anyone managed to get it working correctly without the chuncks messing up.. ?
i feel like i have tryed everything to get it working but still nothing i tryed seemed to fix it :l ...

 

Question, does this support biomes?
If so, can you provide a picture?

Another question, does this also support random structures? If so how?

 

Biomes - Yes they can be built, but you'll need to code them yourself into the terrain generator. There is no included functionality, but you could say it's technically supported.

Structures - Yes, but again you'll need to code them into the terrain generator. There is an example function included that shows how to place trees, but it is limited to the fact that the tree (or in your case a structure) has to fit inside the chunk it's attempting to be placed on.

 

Hello,

I want to have a base texture and a normalmap for each material.
I tried the both the standard shader with opaque, and I tried the legacy shader bumped specular.

Do you have experience with those? Which ones has better Performance and the stronger depth effect?

Or can you recomment a better shader?

Thanks a lot

Firlefanz

 

I can't really see anything in your code that would cause the errors you describe. It might be some other thing in another part of your code, or maybe coroutines cause some strange behavior in Uniblocks...

I will try doing some tests later and will let you know if I find something, but most likely the problem is in some other part of your code.

You can only edit the terrain at runtime, so it's not possible to edit it in the Unity editor. However, the terrain doesn't have to be auto-generated every time - you can edit it at runtime and save it, then have the previously edited terrain load the next time you run the game.

Well, Unity versions older than 5 are technically not supported anymore.
That said, I tried importing the current package into Unity 4.2 and while the code seems to compile with only a couple of minor syntax fixes, the scene setup and about half of the prefabs are gone. However, it should be easy enough to restore the prefabs and the scene manually (maybe 30-60 minutes of work with testing and everything - you can open Uniblocks in Unity 5 to see the correct setup), and the code should work fine (I don't see any reason why it wouldn't), but I can't guarantee 100% correct operation. Still, If there is something that doesn't work as expected it would probably be on the Unity editor side (prefabs, colliders, etc) not the code itself.

I think it's generally recommended to use the Standard shader, the legacy is the one from older versions of Unity.
I'm not too familiar with shaders generally, so it might be best to refer to the Unity documentation or other resources.

 

I think saying that Uniblocks fails is maybe a bit too harsh. It just depends on your expectations. You can see the performance in the demo, and it should be suitable for many indie projects. Please don't expect AAA quality stuff or a full working Minecraft clone for 60 dollars.

Also, a small correction - the code being easy to read was not the main intention, it's just that simpler code is easier (and faster) to write, and being easy to read is a nice side-effect. I definitely would optimize it if I could justify all the extra work. However, a perfectly optimized code would take ten times longer to write, and the price of the asset would have to be ten times higher, otherwise it's just not worth the development time (and I doubt anyone would actually buy it at that price).

You could of course say that I should've written perfect code from the start, but, well, I guess I'm just not a good enough programmer to do that... Remember that it's easy to add some small improvement on top of an already existing codebase, but not so easy when you have to write all that stuff from scratch.

 

Hey maap Welcome back , And ok cool i have tryed different Variations of my own code and no matter what i do the bugs still appears so im not exactly sure whats going wrong.. i still have not found any sort of solution but the Weirdest part about the bug is that it dosent happen instantly when the block gets placed it happens after roughly 8 - 12 blocks get placed in the same area..

 

Hi maap,

good to have you back

Could the Rendering Performance be improved if far away chunks do not get custom meshes, and are updated with custom meshes when they get near?

My main Problem is the chunk creation. This is too slow. When I walk ahead, after a Minute I can reach the "end of the Matrix". For me it would be a great win if the chunk creation would be faster or on an own thread.

I have tried to optimize my chunk creation method, but I think it is okay. Of course I have many different blocks with many materials but I Need those.

Thanks a lot and have a nice day!

Firlefanz

 

I think that wouldn't really help - custom meshes don't affect chunk loading times very much, and it's better to just build the chunk mesh once instead of having to rebuild it again when you get near the chunk (that would mean you'd need to build each mesh twice, probably almost doubling the loading times...)

Are you sure you're not using an old version of Uniblocks? In the latest version, the chunks closest to the player always load first, and the few closest chunks should load very fast, so it really shouldn't be possible to reach the end of the world.

If you are using many materials, that will slow down the loading times (and performance in general) a lot, so you really should use as few as possible. Two or three materials per chunk should be fine, but don't use a separate material for each block.

 

Hi maap,

I have more than 100 materials, 90% because of the custom meshes.

Should I remove custom meshes from the chunks and write my own class to list and render those? Then I could render those only when they get near. Do you think this would increase Performance?

Or another idea, could all custom meshes be rendered with a small dark default material or blended out when they are far away?

Thanks and have a nice weekend!

 

Every time you add a new material to the chunks, you will have measureable reduction in game fps. This is why using a texture atlas is best for multiple textures rather than adding a new material for each new custom mesh.

This requires you to modify uniblocks to build an atlas maker because most textures you have wont fit into nice 32x32 square that is in the uniblocks template and uniblocks by default doesn't allow you to take a texture from texture sheet provided and apply it to a custom mesh.

 

You don't have to write any custom classes or modify Uniblocks code. Custom meshes can use textures from a texture sheet, just put the texture in the texture sheet and modify the UVs of the mesh to be relative to the entire texture sheet (check the example tall grass or the door meshes).
Also, the textures on the texture sheet don't have to be 32x32, the manual explains how to adjust the texture size. Custom meshes can use the entire texture sheet, not just a single texture from it.

In any case, please do not use more than 100 materials. This will cause huge performance issues regardless of any optimization efforts.

 

Hey maap bit of a Nub Question but, i was wondering if you could give me a litte bit of a run down of how the saving / loading is used? i have looked at the documentation but i did not find anything on how to check if a uniblocks save Exists? also i cant seem to find anything on actually Loading the game ? :S
Also did you end up finding anything wrong with my code ? i have chenged it many times but no matter what i do the bug still happens and i cant think of anyway to do this without the use of Coroutines :l .. - Thanks!

 

The world data is saved in a Worlds/WorldName folder, which you'll find in the root directory of your build (or Unity project). You can check if a save file exists by checking if a folder with that name exists inside the World directory. (You can get the path of the Worlds folder using Application.dataPath + "/../Worlds/").

Uniblocks loads world data from the currently active world, which you can set in the Engine Settings. The World Name is the name of the folder from which data will be loaded). So basically if you want to change where the world is saved to or loaded from, change the World Name. At runtime, you should use Engine.SetWorldName(name) to change the active world.

I think it's something you'll need to figure out on your own. I can only look for potential problems in the Uniblocks code itself, but there doesn't seem to be anything that would prevent coroutines from working. In fact the falling blocks script I posted here before (http://forum.unity3d.com/threads/un...xel-terrain-engine.226014/page-8#post-2227592) uses coroutines without any problems. Your script seems to use the same pattern as mine, so that's why I suspect the problem is somewhere else in your code.

I could be missing something, but unfortunately I can't possibly debug every potential conflict with custom code written by users...

 

Ahh i see its all good Thank you for your help

 

Hi,

I changed a lot of stuff now. And made a new Scene with start menu only.
It switches to the game Scene with Application.LoadLevel now.

Since then, my Player falls into the ground before enough ground was spawn.

How was that originally prevented? Was the rigidbody of the Player disabled or something like that?

Can anybody give me a hint, what's the best way if you start from the scratch into the gamescene (which has the Player in the Scene), what's best way to have the Player inactive and spawn land around or under him until there is enough landmass?

Thanks and have a nice Weekend!

Firlefanz

 

You could use a coroutine. Figure out which chunk the player is going to spawn on (or a group of them), have a bool marking whether its terrain is built or not, and then wait for it to be built in the coroutine. If it isn't yet, wait a frame. When it is, spawn the player.

 

The solution in the demo scene is that the player's CharacterController is disabled initially, and you can only enable it (by pressing space) if 3 seconds have passed (Time.realtimeSinceStartup > 3.0f)

That's good enough for demo purposes, but @JasonBricco's solution is definitely more elegant. You can get the chunk at the player's position using Engine.PositionToVoxelInfo, and you can check if a chunk has its mesh built by checking if its mesh != null

To make sure the player never falls through the world, it might also be a good idea to wait for several chunks below the player's chunk, in case the player spawns in the air far above the surface. Or you could even do a raycast down from the player's position (long/infinite range) - if it doesn't hit the terrain, wait a frame and try again.

 

Thanks. I freeze the Player and put a Fullscreen Panel on top with a Label "Initializing landscapes".
Works perfect, thanks

 

Hey everyone,

We have just released a UI package for minecraft styled games and thought you would be interested:

Asset Store: https://www.assetstore.unity3d.com/en/#!/content/49991
Web Build: https://dl.dropboxusercontent.com/u/29289192/Laircraft UI/Web Build.html

Not intending to step on anyones toes, noticed this pacakge doesn't come with UI and thought it would be a nice add-on for anyone interested but if you are not happy with me promoting my asset here I will of course remove this post.

Cheers!
Jason

 

Hello everybody,

I followed the Suggestion from maap for my Performance Problems and I have put all textures which are for ground meshes (not custom meshes) into two big boxes (tiled Images is it called I guess). Performance got a Little bit better now.

When I remove a block (or something else) I spawn an item which is a mesh with the original material. For the voxels I added a simple cube mesh.

Before when I removed mud I got an item spawned with mud material, because mud was the material of the voxel. Now I get an item spawned that Looks like a lego-box.

Is there a way beside making a new material to have my spawned item just have the correct part of the new material (the part with the mud texture), just like the voxel does now? How do I get the mud material out of my new ground materials multitexture?

Thanks a lot!

Firlefanz

 

If you want the elegant but difficult way, you can change your cube mesh's UVs dynamically to fit the texture of the block you're spawning. For example, make a mesh with UVs on the first texture, and then move them in your code depending on the texture settings of the voxel whenever you instantiate that mesh.

It might be easier to just have a separate material for each block type, especially if you don't have too many different voxel types. Of course you would use these materials only for the spawned items, not for the chunk meshes. Depending on the block type, you would apply a different material to the spawned item.

As long as it's an asset that benefits the users but doesn't compete with Uniblocks directly (like another voxel terrain engine), I don't have a problem with posting it here, so no worries.

 

Hi maap,

is there a Chance to get some update with spawning chunks on a 2nd thread? I am sure this would help a lot for spawning

I heard that there will be a december unity update with a mono update with enhanced multi-threading Support

Have a nice week!

firlefanz

 

I thought the mutlithreading update was for graphics and basically Unity being more multithreaded rather than giving devs better multi threading :/

Where did you read this?

The only mono update I see is for MonoDevelop 5.9 which will only affect development.

 

Sorry I do not find it anymore. I guess it was or is somewhere on the unity site ...

 

The place to check is their roadmap:

https://unity3d.com/unity/roadmap

Nothing in it about multithreading as you describe for the next while I am afraid

 

There are no plans for full multithreading support for the near future - it would require rewriting a lot of the engine entirely, and I'm not really sure whether the overall performance gain would be that significant.

However, threading support at least for the terrain generator only is relatively easy and should improve performance a lot when using more complex terrain generation algorithms, so I do want to add it in in the future. Some other performance improvements such as chunk pooling are also planned.

I'm currently busy with other projects and not actively working on Uniblocks at the moment so this please don't expect an update very soon, but it will most likely happen at some point.

 

Sounds good to me. Threading Support for the Terrain Generator would be great.

 

Hello,

does anybody have an idea:

Lighting is very good, I use a Day Night Controller I found that moves a directional light with a light yellow Color and soft shadows. It has a child directional light with Rotation x 3 y 179 and blue color as a darker reflect.
I think it was nearly the same in the uniblocks sample.

When I now use a Portal, the player's Position changes from one Frame to the other Frame to a totally new Position.

That works good now (after populating 5 seconds of landscape), but after that the light or I think it is the shadows, are totally jittering /flickering...

Dows anybody have an idea what the Problem could be?

Thanks a lot!

Firlefanz

 

If shadows are flickering, it could be a floating point precision error. How far from the origin is the player?

 

Hi Jason,

The Player always starts at xyz 0, Terrain Height, 0. Nothing flickering when starts.
The Portals are everywhere, my Terrain ist x*z 5000*5000 large.
After changing psoition to a Portal, it always flickers.

 

I've noticed flickering before without having to go very far from the origin - 1000-2000 range was able to do it.

But if it even happens close to the origin, then there's something else going on. If that happens, what code is involved when using a portal?

 

It just sets the new Position, freezes the Player for 5 seconds and spawns some particles:

Code (CSharp):

1.                                 if (Globals.Portals [i].heightPoint == Globals.HeightPoint.OnGround && Globals.Portals [i].Y < FktTerrain.GetHeight (new Vector3 (Globals.Portals [i].X, Globals.Portals [i].Y, Globals.Portals [i].Z), false) + 1 + FktTerrain.HeightOffset)
2.                                     Globals.Portals [i].Y = FktTerrain.GetHeight (new Vector3 (Globals.Portals [i].X, Globals.Portals [i].Y, Globals.Portals [i].Z), false) + 2 + FktTerrain.HeightOffset;
3.                                 Vector3 newPosition = new Vector3 (Globals.Portals [i].X + 1, Globals.Portals [i].Y, Globals.Portals [i].Z + 1);
4.                                 player.transform.localPosition = newPosition;
5.                                 Globals.PlayerTransform = transform;
6.                                 Globals.Playerdata.nFrozen = 5;
7.  

You could be right, no Portal is around the start area, all are far away.

 

Because it could be the distance, in the update method of my day night Controller I changed:

Code (CSharp):

1.         sun.transform.localRotation = Quaternion.Euler ((currentTimeOfDay * 360f) - 90, 170, 0);
2.  

to now

Code (CSharp):

1.         sun.transform.localPosition = Globals.PlayerTransform.position;
2.         sun.transform.localRotation = Quaternion.Euler ((currentTimeOfDay * 360f) - 90, 170, 0);
3.  

so it is not so totally far away from the Player. But it does not seem to help.
Sun is my directional light that has soft shadows.

Any idea? Do I Need to update something Special on the light?

 

It's about distance from origin, not distance from player. Unity seems to run into floating point precision errors very quickly when it comes to shadows, for whatever reason. The only way I know of to avoid floating point errors is to keep the player at the origin at all times and shift the world around, but that comes with various complexities.

 

Thanks for the info Jason. That does not sound good
How did you solve this?

 

I don't use Unity's shadows; I use custom voxel lighting - the light is baked into the mesh rather than being dynamically calculated. If I did have to solve the problem, I would use the world shifting approach.

 

Can you add (and remove again) things like torches?
Can the Player carry a torch or throw a lightened FIREBALL with custom voxel lighting?

 

You can add and remove torches, yes. The light will propagate through the voxels and be blocked correctly by obstacles. But this light is baked into the mesh, so it doesn't work with moving.

You can still do dynamic lighting for the movement case or create a custom shader that will let you do the moving light (while still having baked voxel lighting for the typical case).

 

This sounds to me like a big Unity Bug. Is it known?
Do you think there is a Chance they fix it during the next months?

Sounds like a lot of work if I Need to recode all that lighting stuff

 

It could be a bug, I'm not sure. If it is, it hasn't been fixed for a long time now (over a year). I'm unsure of the technical reasons shadows have issues with such a small range. Far clipping plane range seems to have some effect as well.

As for the lighting, you really only want to write your own if you want to be able to place light blocks in the world or if you want proper light blocking by obstacles. Dynamic lights go through everything without expensive computations.

 

I guess I found the solution, if you want to Keep your directional light.

I have set the main camera's clipping plane value from 0.01 to 0.06. That fixed it and I still cannot Looks into voxels (I could when I set it to 0.1). Problem seems to be solved for me, I cannot reproduce it since then.

Maybe I will Change that whole lighting stuff, but much later. Thanks for your hints Jason

 

Hello, so im having a little bit of an issue..
Im trying to Delete Whole world save files from the default "worlds" folder in its default path but for some reason i cant seem to get inside the worlds folder in code to delete a world save file ? im not sure if im using the wrong path or what the issue is ...

**EDIT, All Good i managed to fix my problem. I was running "if(File.Exists)........." when i was supost to be using "Directory.Exists........."

 

how fix error here https://gyazo.com/7f29eb0349e4c7ad65f39a0bcb6a13ca

 

Sometimes the default terrain generator will generate hills that go above the chunk height limit, which will cause the tops of the hills to be cut off like this. You can just increase the height limit in the engine settings, or tweak some values in the terrain generator so the hills don't get as high.

 

Hi,

I already have set all my voxel materials into two texture atlasses. I can't do this for the custom meshes (or at least not right now and only for some I guess)...

Running the profiler I got 24 draw calls for my UMA Monsters / npc and over 2000 for the landscape...
I already reduced my camera far to 150.

Some idea: Is there a way to render all chunks, that are let's say over 80 away with one draw call by giving them a alternative temporary material (just for Rendering them if far away), where this material is just a Standard Color material with the fog's Color?
I added some fog to the camera, so the "end of the Matrix" cannot be seen too easy...

Thanks a lot,

Firlefanz

 

You're able to change the material as you wish during runtime. However, to render them all in a single call, they have to be batched together into one mesh. Unity's vertex limit of roughly 65k will interfere a bit, but that doesn't mean you can't reduce the draw calls substantially.

 

Hi Jason,

I thought each chunk is already set together as one mesh?
Is there a better way to reduce draw calls for far-away meshes?