Uniblocks: cube-based infinite voxel terrain engine

Well, this seemed like a fun little thing to try, so I just went ahead and did this. I haven't really tested it properly, but it seems to work fine.

Add this at the beginning of the UpdateMesh function of the ChunkMeshCreator script. You can change the value of the multiplier to adjust the intensity of the wobble. I'd recommend keeping it well below 1.0 or else you get funny results...

Code (CSharp):

1.   // ==== wobbly effect ====
2.   float multiplier = 0.25f;
3.   List<Vector3> WobblyVertices = new List<Vector3> ();
4.   foreach (Vector3 vertex in Vertices) {
5.     Vector3 absolutePos = transform.TransformPoint (vertex);
6.     float noise = ( Mathf.PerlinNoise (absolutePos.x, absolutePos.z) - 0.5f ) * multiplier;
7.     WobblyVertices.Add ( new Vector3 (vertex.x + noise, vertex.y + noise, vertex.z + noise) );
8.   }
9.   Vertices = WobblyVertices;

 

Hey, maap Hopefully this will be the last time i beg for your help on stupid questions that i manage to overlook everytime ^.^ but ive been playing around with the generation ive managed to do most of the things ive wanted except theirs 2 problems i was hopeing you would have some idea on , i was wondering if you have any idea where to start if i was to do random bieomes ive tryed this my self but i cant seem to figure out a way to do this unless i used the "currentHeight" but it didnt seem to be very efficient that way ... and also would you know of any way i could go about spawning random caves ? - thanks for your help in advance

 

Well thanks alot i will check it out later

 

Both biomes and caves are pretty advanced topics that I won't be able to explain in depth here. You'll need to write a custom terrain generator script or modify one of the example ones, but you'll need to figure out the specific algorithms yourself.
I'd recommend looking for some resources on procedural terrain generation. Perlin noise is a good topic to start with, it's what the example terrain generator uses, and you can use it for biomes as well. For caves you might want to research cellular automata, perlin worms, and other related topics.

 

Thanks for Pointing me in the right Direction i went serching around for perlin worms and i couldent find a whole lot of good tutorials or anything on perlin worms in unity .. but i did however find a heap of good tutorials on cellular automata, but as always i have ran into a problem the scripts i managed to get from a tutorial they all work but ive spent about a day or two trying to implement it into the engine and i canot seem to do it i have no idea how .... if your able to come to the rescue once again maap that would be great :') ....
https://github.com/SebLague/Procedural-Cave-Generation/tree/master/Episode 04
Thats the link to the Cellular Automata scripts im trying to implement into the engine if you have spare time and would like to help me out once again all im trying to do is integrate it into the engine so it will generate randomly along with some chunks..
- Thanks , & also if you dont want to help thats completely fine just thought i would ask you first since you kow your engine better then anyone else i could possibly ask..

 

Hello,

did already somebody add 2D gui like the inventory Slots and render a block into that gui Slot?

I added a script for 2d gui and draw an empty Slot (texture with a number) like this:

for (int i=0; i<10; i++)
{
GUI.DrawTexture(new Rect(Screen.width * 0.35f + i * 164 * Globals.gxScale, 0, 160 * Globals.gxScale, 160 * Globals.gxScale), texSlotEmpty);
GUI.Label(new Rect(Screen.width * 0.35f + i * 164 * Globals.gxScale+8*Globals.gxScale, 150 * Globals.gxScale, 160 * Globals.gxScale, 160 * Globals.gxScale), "F" + (int)i+1);
}

Now I have Slot [ i ] .ntyp which is storing my blocks number. Can anybody tell me how to render that block on my slot texture? I use both 6sided primitives like the original uniblocks plus custom meshes...

Thanks a lot and have a nice day!

Firlefanz

 

Hello,

I found the "wobbly effect" a few answers before.

It Looks very good, I like it. But my custom meshes are also transformed that way, I do not want for them.

And I want to try it with water blocks with other values.

How do I get the block type of that mesh UpdateMesh function of the ChunkMeshCreator script so I can use it for certain blocks only?

Thanks a lot!

Firlefanz

 

I'm really sorry but I won't be able to help you any further, it's not really something I can just do in half an hour of my spare time. I recommend studying the example terrain generator scripts and the documentation, you can find some information on how to integrate a custom terrain generator there.

If you already have a working generator, you should be able to apply it's results just by iterating through all the voxels it generated and applying them to the Uniblocks chunks through Chunk.SetVoxel, though the one you linked seems to be a 2d generator, so you'd probably need to do some more stuff with it before you can use it.

If I understood correctly, you want to draw the texture of a block in the GUI? I'm not too familiar with GUI stuff so I can't really give you any specific directions, but I think you'll need to draw the texture sheet image and crop it so that only that one block's texture is visible. You can use the code from ChunkMeshCreator's CreateFace function, the section labelled ==== UVs =====, this code basically gives you the 4 vectors which are the corners of the block's texture on the texture sheet.

If you actually want to draw a 3d cube in your GUI though, I have absolutely no idea how to do that, sorry! Perhaps you could use some code from the ChunkMeshCreator to build a cube with the correct textures and everything, if that's what you're looking for (a CreateFace six times, once for each direction, should make a cube mesh with textures)

I'm not entirely sure if this would work, but you could try applying the wobble in the CreateFace function instead of UpdateMesh. You'd have to modify it so it only affects the last four vertices. This way it will skip custom meshes (they're created in a different function). For water, you could check whether the current face belongs to a water block, and change the intensity for that face if needed. The CreateFace function has a "voxel" parameter which stores the current voxel id.

 

I have a few questions. I am not using uniblocks to generate terrain but instead just using it as a building tool. I have built a bunch of islands surrounded by ocean with unity terrains and i want players to be able to build on the islands with the voxel blocks.

so the first question is can i just generate chunks at the islands positions? all the chunks in the unbuildable ocean is just wasted memory. eliminating all those would allow me to just have a few larger chunks where i need them and all i would have to do is have one null chunk check. right now i have coded in a bunch of boundary checks to prevent voxels from being placed outside of the islands but i fear all those checks will become resource intensive in a multiplayer environment. Is there a way i can just place and manipulate chunks/voxels in the editor instead of having them generated at runtime since i don't need the unlimited procedural generation?

the second question is probably from me not playing around with the raycasting code enough. Since i am not having any voxels generated at the start i want players to be able to use the unity terrain as a starting point to build on. I was able to place voxels onmouseclick based on player position as a cheat but i really only want them to be placed if they click on unity terrain so they aren't just building in the air. Right now im cheating a little bit less by spawning 1 voxel at the middle of each island to build off of.

 

Hello,

in Addition to my last question, how to manipulate the cube sides / faces but only of non custom meshes:

Like suggested I tried to Change that CreateFaces Method.

First of all I made a function for own perlin noise or water:

float GetVertexNoise(ushort voxel, Vector3 vertex, int faceIndex)
{
Vector3 absolutePos = transform.TransformPoint (vertex);
// ==== wobbly effect ====
float noise = 0f;
if (faceIndex == 2 && voxel == 22)
{
// Water top side
noise = (Mathf.Sin(absolutePos.x+(float)Globals.time_startelapsed)+Mathf.Cos(absolutePos.z+(float)Globals.time_startelapsed));
}
else //if (voxel < 20)
{
noise = (Mathf.PerlinNoise (absolutePos.x+faceIndex, absolutePos.z) -0.5f); //(Random.Range (0, 1f));
}
return noise;
}

I am not sure if I Need only x, y, z or the transformed coordinates here?

Then I just added this noise to all faces coordinates.
Looks much code, but it is only the original code + GetVertexNoise.

When I use that (commented) random value for testing, everything looks very random every face anywhere,
but when I use that noise like it is supposed mnothing happens at all!

Can you give me an idea what I am doing wrong with that noise? Thanks a lot!

// ==== mesh generation =======================================================================================
private void CreateFace (ushort voxel, Facing facing, ColliderType colliderType, int x, int y, int z, int faceIndex)
{
Voxel voxelComponent = Engine.GetVoxelType (voxel);
List<int> FacesList = Faces [voxelComponent.VSubmeshIndex];
Vector3 vertex = new Vector3 (x, y, z);
// ==== Vertices ====
// add the positions of the vertices depending on the facing of the face
if (facing == Facing.forward)
{
Vertices.Add (new Vector3 (x + 0.5001f + GetVertexNoise(voxel, vertex,faceIndex), y + 0.5001f + GetVertexNoise(voxel, vertex,faceIndex), z + 0.5f + GetVertexNoise(voxel, vertex,faceIndex)));
Vertices.Add (new Vector3 (x - 0.5001f + GetVertexNoise(voxel, vertex,faceIndex), y + 0.5001f + GetVertexNoise(voxel, vertex,faceIndex), z + 0.5f + GetVertexNoise(voxel, vertex,faceIndex)));
Vertices.Add (new Vector3 (x - 0.5001f + GetVertexNoise(voxel, vertex,faceIndex), y - 0.5001f + GetVertexNoise(voxel, vertex,faceIndex), z + 0.5f + GetVertexNoise(voxel, vertex,faceIndex)));
Vertices.Add (new Vector3 (x + 0.5001f + GetVertexNoise(voxel, vertex,faceIndex), y - 0.5001f + GetVertexNoise(voxel, vertex,faceIndex), z + 0.5f + GetVertexNoise(voxel, vertex,faceIndex)));
if (colliderType == ColliderType.cube && Engine.GenerateColliders)
{
SolidColliderVertices.Add (new Vector3 (x + 0.5f + GetVertexNoise(voxel, vertex,faceIndex), y + 0.5f + GetVertexNoise(voxel, vertex,faceIndex), z + 0.5f + GetVertexNoise(voxel, vertex,faceIndex)));
SolidColliderVertices.Add (new Vector3 (x - 0.5f + GetVertexNoise(voxel, vertex,faceIndex), y + 0.5f + GetVertexNoise(voxel, vertex,faceIndex), z + 0.5f + GetVertexNoise(voxel, vertex,faceIndex)));
SolidColliderVertices.Add (new Vector3 (x - 0.5f + GetVertexNoise(voxel, vertex,faceIndex), y - 0.5f + GetVertexNoise(voxel, vertex,faceIndex), z + 0.5f + GetVertexNoise(voxel, vertex,faceIndex)));
SolidColliderVertices.Add (new Vector3 (x + 0.5f + GetVertexNoise(voxel, vertex,faceIndex), y - 0.5f + GetVertexNoise(voxel, vertex,faceIndex), z + 0.5f + GetVertexNoise(voxel, vertex,faceIndex)));
}
} else if (facing == Facing.up)
{
Vertices.Add (new Vector3 (x - 0.5001f + GetVertexNoise(voxel, vertex,faceIndex), y + 0.5f + GetVertexNoise(voxel, vertex,faceIndex), z + 0.5001f + GetVertexNoise(voxel, vertex,faceIndex)));
Vertices.Add (new Vector3 (x + 0.5001f + GetVertexNoise(voxel, vertex,faceIndex), y + 0.5f + GetVertexNoise(voxel, vertex,faceIndex), z + 0.5001f + GetVertexNoise(voxel, vertex,faceIndex)));
Vertices.Add (new Vector3 (x + 0.5001f + GetVertexNoise(voxel, vertex,faceIndex), y + 0.5f + GetVertexNoise(voxel, vertex,faceIndex), z - 0.5001f + GetVertexNoise(voxel, vertex,faceIndex)));
Vertices.Add (new Vector3 (x - 0.5001f + GetVertexNoise(voxel, vertex,faceIndex), y + 0.5f + GetVertexNoise(voxel, vertex,faceIndex), z - 0.5001f + GetVertexNoise(voxel, vertex,faceIndex)));
if (colliderType == ColliderType.cube && Engine.GenerateColliders)
{
SolidColliderVertices.Add (new Vector3 (x - 0.5f + GetVertexNoise(voxel, vertex,faceIndex), y + 0.5f + GetVertexNoise(voxel, vertex,faceIndex), z + 0.5f + GetVertexNoise(voxel, vertex,faceIndex)));
SolidColliderVertices.Add (new Vector3 (x + 0.5f + GetVertexNoise(voxel, vertex,faceIndex), y + 0.5f + GetVertexNoise(voxel, vertex,faceIndex), z + 0.5f + GetVertexNoise(voxel, vertex,faceIndex)));
SolidColliderVertices.Add (new Vector3 (x + 0.5f + GetVertexNoise(voxel, vertex,faceIndex), y + 0.5f + GetVertexNoise(voxel, vertex,faceIndex), z - 0.5f + GetVertexNoise(voxel, vertex,faceIndex)));
SolidColliderVertices.Add (new Vector3 (x - 0.5f + GetVertexNoise(voxel, vertex,faceIndex), y + 0.5f + GetVertexNoise(voxel, vertex,faceIndex), z - 0.5f + GetVertexNoise(voxel, vertex,faceIndex)));
}
} else if (facing == Facing.right)

.... and so on

 

You can actually just place the chunks in the editor, and never spawn any other chunks at runtime (remove the ChunkSpawner from the player, don't call SpawnChunks anywhere else, etc). One small issue with this is that you'll need to place the chunks at the correct world coordinates - they have to correspond directly to the index of the chunk, so basically you'll need to take their "correct" world position and divide it by the length of the chunk (that is, if you want the chunk to be at 64,64,64, you'll need to place it at 4,4,4, assuming the chunk side length is 16). They'll then move themselves into the correct positions when you start the game. Sorry if it's a bit annyoing, but I haven't really planned for chunks being placed in the editor.
Also make sure the chunks have "FlaggedForUpdate" set to true if you want them to generate their meshes at the start of the game.

This should be simple, just use Engine.PositionToVoxelInfo to access the voxel at the position of the raycast hit.

 

What exactly is faceIndex? I can't find where you assign anything to it in your code, and it seems it's the only thing that's different from my code in the noise generation line. If it works fine with the random value, then it would seem there's something wrong with that faceIndex int.

Another thing, it seems that you're using the x,y,z values of the voxel rather than each vertex, that means the noise for each vertex in a block would be the same because they're all using the same absolute position (the center of the block) to generate it. You should probably be using the vertex position instead (that's the x,y,z plus the 0.5f offset in different directions).

I'm sorry if this isn't very helpful, but those are just the things I could tell from the code snippet you posted. Unfortunately I just won't be able to help you very much with debugging your code. And besides, that code for the wobble effect I wrote isn't a supported feature anyway, it's just something extra I did in my spare time.

 

Hello maap,

thanks a lot for your help! That helps me a lot

I now changed my code, that 0.5f Offset hint was very good.

I made a new function in ChunkMeshCreator:

private Vector3 VectorVertex(float x, float y, float z)
{
Vector3 absolutePos = transform.TransformPoint (new Vector3(x,y,z));
float noise = ( Mathf.PerlinNoise (x, z) - 0.5f ) * 0.25f;
//return new Vector3 (x + (Mathf.PerlinNoise (x, z)-0.5f) / 4, y +(Mathf.PerlinNoise (x,z)-0.5f) / 4, z +(Mathf.PerlinNoise (x,z)-0.5f) / 4);
return new Vector3 (x + noise , y +noise , z +noise);
}

It is like your code for this Topic. Then I changed your CreateFace function and for new faces I just use my new function like this:

if (facing == Facing.forward)
{
Vertices.Add (VectorVertex (x + 0.5001f, y + 0.5001f, z + 0.5f));
Vertices.Add (VectorVertex (x - 0.5001f, y + 0.5001f, z + 0.5f));
Vertices.Add (VectorVertex (x - 0.5001f, y - 0.5001f, z + 0.5f));
Vertices.Add (VectorVertex (x + 0.5001f, y - 0.5001f, z + 0.5f));
if (colliderType == ColliderType.cube && Engine.GenerateColliders)
{
SolidColliderVertices.Add (VectorVertex (x + 0.5f, y + 0.5f, z + 0.5f));
SolidColliderVertices.Add (VectorVertex (x - 0.5f, y + 0.5f, z + 0.5f));
SolidColliderVertices.Add (VectorVertex (x - 0.5f, y - 0.5f, z + 0.5f));
SolidColliderVertices.Add (VectorVertex (x + 0.5f, y - 0.5f, z + 0.5f));
}
} else if (facing == Facing.up)

... and so on for all faces. It is looking very good and it is not slowing down.

But now sometimes I got empty holes in my landscape between two blocks.
Do you have an idea how to fix that?

In my eyes this would be a good Feature with a factor to set manually in your engine

Thanks a lot and have a nice day!

Firlefanz

 

Hey maap, just thought ide ask you a quick question im trying to make a light source a child of a Voxel useing,

LightSource.transform.parent = Cube.transform;
//Cube being the object i want my LightSource to be a child of
But im having a problem ive read through the scripting refrence and i understand that it uses VoxelInfo to store the blocks information ect but how would i go about getting the block since its not an object in the hierarchy ?
I have tryed ,
Var Cube = VoxelInfo.GetVoxel() == 12;
LightSource.transform.parent = Cube.transform;
But this didnt seem to do the trick..
just wondering if you could give me a short example if possible - Thnx

** EDIT : i managed to figure it out turns out the code above was correct all along i just had a bunch of other issues stopping it from working correctly "Facepalm -.- "..

Now since i have fixed the last issue their seems to be another :\ ... for some reason once its instantiated as a child the Light dosent seem to be anywhere im sertin that it has instantiated as a child in the block but for some reason it dosent seem to show its asif it hasent instantiated at all or asif the blocks somehow blocking it in a sence not sure if im making any sence hopefully ive explained it well enough ..... Any ideas on why this may not be showing the LightSource after it has been instantiated as a child object of a block ? - Thanks in advance

Also while i have your attention just a simple question i was wondering if you could give me a quick rundown of how to create custom plants eg like your grass? i have a rough idea and tryed to do it on my own but it didnt seem to work out ...

 

I solved my question myself, got it working. Thanks a lot!

 

It's hard to answer the question since I don't have your code, but it seems to me that you're trying to do something that's just not possible. Blocks do not exist in the world as objects, so it's not possible to instantiate anything as their children, regardless of how you try to do it.

If you'd like to instantiate a light on top of a block, try just spawning it in normally at the world position of the block. Use Engine.VoxelInfoToPosition to get the world position for that block.

The easiest way to do this is to copy the existing tall grass block - go the Block Editor, select the tall grass block, change it's ID and click Apply. You'll get a copy of the tall grass block with the new ID. You'll need to modify it's custom mesh in order to change the texture. The default tall grass mesh has the UVs set to match the tall grass texture in the texture sheet, so you'll need to duplicate the mesh, and set different UVs for it.

If you want these to be generated in the world, you could reuse the code for placing trees from ExampleTerrainGeneratorWithThrees, except instead of having to build the tree with the AddTree function, you could just set the voxel to your custom plant directly (or randomize between different plants).

 

Hey, i actually think i managed to get it to work i used a debug to tell me what the light's parent was and although you cant see either of them in the hierarchy its telling me that its parent is the right thing im instantiating it to so i dont know whats going on hear but seems like it might be easyer if i find another way around this ..

& Thanks for giving me some more info on the custom plant meshes i was stuck on this for a while wasent sure what to do - Thanks again

 

Hello maap,

I am also working on my grass but I have Chosen a different apporach.

I turned off the custom mesh for the grass, and in the "RebuildMesh" method I use "CreateGrass" instead of "CreateFace" now, but without up and down faces.

I copied the "CreateFace" and renamed it to "CreateGrass". I removed the colliders stuff there and just altered the psoitions to be more in the middle.

Works great. Just one Thing: How do I render each face from both sides (Culling or two-sided Rendering)?

Is there a way to render both sides of each face? Could you give me a clue?

Thanks a lot and have a nice sunday,

Firlefanz

 

I don't know if it's a good idea to modify the mesh creator when you can accomplish the same result without even touching any code. It's a lot of extra work and it adds unnecessary complexity. I mean, if it works for you, then that's great, I just wouldn't do it that way myself.

I think in order to render two sides of a face, you just have to draw two separate faces on top of each other. You can change the facing of a face by inverting the order of vertices (for example, instead of 1,2,3 you set it to 3,2,1). Make sure that the two faces don't share the same vertices - you should create duplicate vertices for the second face.
It has been a while since I've touched any mesh creation code and I'm not sure if I'm remembering this correctly, so let me know if this doesn't work for you.

 

Hello maap,

you were right I didn't get it working like I wanted it to.

I also have a custom gras mesh. It is like your but has few more Vertices.
How do I render this custom mesh with backfaces/two sided rendering?
Or would it be better to tell my GFX Artist he should creatre it with faces to all sides per vertice?

Thanks a lot!

Firlefanz

 

Are there any "finished loading" events?

I want to show a loading screen until the first few chunks around the player is loaded, but I can't figure out a good trigger for hiding the loading screen. As it is, my player keeps falling through the world until the chunks load in.

The best I've found is to get the chunk the player is in, and check for the "VoxelsDone" property. However, it still seems like that is set to true several frames before the actual mesh and colliders appear in game.

*Edit* Checking for chunk.GetComponent<MeshCollider>().sharedMesh != null before I unpause the game prevents the player from falling through, but it feels rather hacky. Would much rather be able to say "disable loader when all chunks within x have loaded".

 

It says infinite terrain.

I know truly infinite is impossible. But I'm wondering if it's only "infinite" horizontally? or is it vertically as well.

If it is both, does it use a cubic chunk generation system or how would it deal with a massive amount of cubes stacked thousands of blocks vertically?

If it's only horizontally or doesn't use a cubic chunk system. How difficult would it be to implement?

 

Yeah, I think you just have to make the mesh with two duplicate faces facing the opposite directions. That's how the example grass mesh works.

There's the ChunkManager.SpawningChunks static bool. It's true while the chunks are being spawned, and is set to false when the Chunk Manager finishes and all chunks are fully loaded.

If you want to check whether an individual chunk has finished building it's mesh, there isn't really any variable which tracks that, but you could just add a local bool in the Chunk script. It will start as false when the chunk is spawned, and you can set it to true in the Chunk's LateUpdate function after the RebuildMesh(); line.

It's "infinite" both horizontally and vertically. Chunks are cubic, and they're stacked vertically the same way as horizontally. They're only loaded within a certain distance of the origin point, both horizontally and vertically. You can set a hard limit for vertical chunks range, but if you don't, they just use the same visibility range as horizontal chunks.

 

Note that you can also set Cull off in the shader if you want to turn off back face culling. I hear there are negatives associated with this method, but I think they only relate to behavior regarding dynamic lighting. With your typical voxel lighting, grass doesn't usually interact with lighting anyway. Of course, you might want it to

 

Thanks maap!

One more question.

I see your system uses a tilesheet :'(. Would it be difficult to convert this to a single texture system. E.g. grassSide.png, grassTop.png etc. etc. Instead of having a tilesheet? I've tried myself with another chunk system. But I can't make it work. Cause there's no individual game objects for blocks, and it just applies the texture to all blocks in the chunk...

Also to elaborate on my last question.

You said it loads chunks in the same range vertically and horizontally. Does that mean it loads it in a sphere?, or at least hopefully not in a cubic shape?

Does it prioritise chunk loading? (e.g. First chunk to load is the one you stand in. Next up it loads the 2 closest chunks to you in the orientation you are looking. Then the ones you can't see?) Or does it just load chunks around you to a certain "view distance".

Also could you elaborate a bit more on performance?

Does it show faces of blocks you can't see? - All other voxel engines seem to. But that just seems like a massive waste of resources.
Does it load chunks you can't see (e.g. underground chunks).
Does it load chunks made up fully of air blocks?
Does it make use of octrees? - When several cubes are together is it able to combine them into a bigger mesh to improve performance? And of course break them down into smaller meshes afterwards?

Sorry for all the questions. But performance is a huge deal when dealing with these voxel engines.

 

A material can only have a single texture (not counting normal maps and the like). If you're using separate textures in that way, you need separate materials. Separate materials mean more draw calls. If each block had its own material, you're talking huge amounts of draw calls. However, there may be techniques to get around this using mesh combining. I'm not terribly familiar, as I use tile sheets as well.

Because a chunk is a mesh and all blocks in it belong to that mesh, you would need to use submeshes to have separate materials per block. Each block type gets a submesh within the chunk mesh.

Also, you should never draw faces that are adjacent to other opaque faces - those faces cannot be seen. Generally show faces adjacent to air or to non-opaque blocks. Unfortunately, this will also expose faces down in caves that the player can't actually see. Getting around that is a bit trickier, and not even Minecraft has managed to solve that yet.

 

Good point about the draw calls. Havn't thought about that yet.

But I need to make the game highly moddable. That means adding the ability to create your own blocks with custom scripts, textures, physics etc. etc.

In order to do that. A stylesheet is not the right way to go. First off, it's very limited in size, unless I make it a huge huge image. But it's also limited in resolution. I need to have built in support for resolutions varying from 16x16 to 1024x1024

and I know it's possible. While Minecraft doesn't support larger textures than 16x16 by default. A mod easily changes that. And they have 1 image for e.g. grassSide and grass top etc. So it's possible without huge performance issues. (Minecraft didn't go noticeably slower after they updated from using a tile sheet).

I have already implemented optimisation for not loading faces that aren't exposed to transparent materials. Havn't looked into attempting something to check the only 3 faces of blocks that should render. (A player can never see more than 3 faces of a block. Perhaps ray-casting? anyhow. That's way beyond the scope of my last post. I just need the single image textures for my project. Somehow... I'm probably going to have to handle materials on a block level. Rather than at the chunk level.

As for further optimisation there's a lot more than can be done. With 16x16x16 cubic chunks for example. There's no need to render chunks that can't be seen or gotten to.

So lets say a player is on level 60. The chunk they are in starts at y58. It only needs to render the chunk they are in, the chunk beneath them. It doesn't need to load all the chunks down to the bottom of the world. And now suddenly we have a nice side-effect where the cave-faces that are exposed to air, isn't being rendered either. - That was of course a simplified version of the logic required. But you get the point.

 

Minecraft doesn't use Unity... but I do think you're right. I think dyox has managed to do something similar in his Terrain Engine, where each block has its own material and performs well. I'm assuming it relates to combining meshes, getting as many into the same batch as possible.

I haven't done anything like this in my own engine, yet. Actually, I've not even divided the chunks up along the horizontal yet although it's something I've been considering. Although, what if the entire chunk the player is in is composed of non-opaque blocks or air (player might be falling, etc)? Then the below chunks would have to be visible unless you masked them somehow... with some kind of fog, perhaps. But I haven't thought very hard about this yet, still on my TODO list.

 

I know Minecraft isn't done in Unity. But it should still be possible. I'll see if I can't figure out where dyox terrain engine is.
In regards to combining meshes (Octotree) that's a huge performance boost in these games. But it looks like we'll have to code that ourselves. As no voxel engine base that I can see, has this ability. Despite seeing several projects utilising it.

As for the second part. How can the player be in a chunk that doesn't have any non-solid blocks? The collision should stop that. - as for falling into the chunk that's not rendered yet if that's what you're talking about. I was going to make it so you can't enter chunks that aren't rendered. Similar to how Minecraft does it, but hopefully a lot less glitchy. So you would just be standing on the air, until the chunk is rendered. Although that hopefully won't need to happen if it's optimised well enough. (Currently when doing tests on my crappy laptop, I'm getting over 60 fps in my engine in Unity vs 14 in Minecraft. With the same view distance) - although that is still an extremely unfair comparison, as I don't have a ton of features, mobs and such that Minecraft does. (yet) - But I also have only done 1 small thing to optimise it so far.

EDIT:

Looked up Dyox engine. $3,000 is a tad too much to spew out on getting a per block texture

Besides, I don't think that's exactly what he's doing. Rather than loading small 16x16 chunks. I'm going out on a limb and say he's larger areas. But heavily utilising LOD instead. (havn't looked into it so can't be sure). - But I doubt it would help me much getting a per block texture. I'll keep trying on my own.

 

Well, say the player is up on a glass platform in a chunk that's in the air, and the ground is on a chunk below that chunk. Would that ground not be rendered?

 

glass is an opaque block. I didn't elaborate this when I made the original reply. Sorry

It would be a rather complex chunk system. With priorities.

E.g. Most important chunks to load.
1 - the chunk the player is in.
2 - the chunk below them (in case they are falling)
3 - the first couple of visible chunks. (perhaps the 5 closest chunks in the direction the camera is looking)
4 - the chunks immediately close to the player. (Probably 3 chunks in a sphere (excluding air chunks) - mainly for mob spawning reasons)

After that it would change a bit and try to cut chunks loading where they aren't needed. Most underground chunks would fail the first pass: Check if all sides of the chunk are solid (if it's not next to any transparent blocks) - This doesn't catch caves yet though).

Next it would probably check if it's visible. If there's already a loaded chunk blocking the view of whatever chunk might be behind it. Don't render it.)

It's probably easier to illustrate it:



This is a side view of a cross-section of the world. The black dot is the player, the black wavy line the terrain.

At the top there's the "Minecraft way", or the 2-D chunk array. Every rectangle is actually a column of 16 x 16 blocks at the base, 128 blocks high. With the new occlusion mechanism in 1.5, invisible chunks (shown in gray) aren't loaded/drawn. The leftmost and the rightmost chunk can't be seen by the player; the blue dotted lines show they're hidden behind the nearby hills.

At the bottom: a 3-D chunk array. We've now sliced up the terrain horizontally as well, into cubes. Again, the gray chunks are invisible to the player. The pale blue chunks consist only of air blocks; they don't have to be loaded either. (This can be checked very quickly using the height map.) As you can see, there's only a little bit of terrain left that has to be processed.

For an infinite vertical range, just keep adding cube chunks at the top and at the bottom. They will be either grey or blue anyway, so there's little overhead.

As for caves it would be caught by the same thing. There'll be terrain blocking it, and it won't be visible anyway.

Probably not that easy to program. But it theoretically it should result in a massive performance boost.
In the top illustration, there's 96 chunks being loaded (393.216 blocks)
In the bottom Illustration there's only 14 or 15 chunks being loaded (57.344 blocks)*

*Assuming each chunk is a 16x16x16 chunk containing a total of 4096 blocks.

That's over 85% decrease in draw calls and chunks being rendered. - That of course won't translate to an 85% FPS increase directly. But in theory it should help performance quite a bit? Even if you do draw the full terrain line. And not just whats visible. - This method would of course be paired with other optimisations. (not rendering faces you can't see or faces that aren't exposed to opaque blocks, combining meshes with Octrees etc.).

Actually as I'm writing this. I can completely discard the need to check if a chunk's faces are touching opaque blocks. The occlusion will make sure they don't get rendered anyway.

Back on topic. I thought of a way the block texture could perhaps be integrated. By taking all the textures and combining them into an atlas before the world is loaded? It doesn't seem like the ideal solution. But that's one thing that might work I guess. And you could dynamically increase the size of the Atlas depending on the amount of textures in the folder.

I just stumbled on a few screenshots of a unity voxel game, not using texture atlases. But still no examples.

 

First of all, Uniblocks does allow having different materials for each block. You just can't have more than one material per block, which means you can't have the sides of the block using different textures, and you'll need a mini texture sheet with all the sides for that block if you want different textures for each side.

Regarding the performance improvements ideas you suggested, they look good in theory, but in practice most of them wouldn't work for many different reasons. Most of them would really only work in a few extremely specific situations, and only in a "best case" scenario.
For example, you're assuming that the terrain is a heightmap, and all chunks above and below are essentially empty. What about overhangs? Floating islands? Caves, holes?

Things such as hills obscuring view are also unrealistic. You'd need to somehow check for line of sight for every exposed block in every chunk, and you'd need to do it every frame, because the line of sight changes constantly and quickly. Not to mention you'd need to somehow instantly load all the previously hidden chunks when they come into view suddenly (say, the player breaks a wall that previously obscured a lot of chunks).

Also, what about NPCs in chunks that you can't see? You still need to load the chunks in order to handle their pathfinding, collisions, etc.

You probably won't find most of these features in any generic voxel engine, because they're just far too specific and make too many assumptions.

As for Uniblocks's performance, there are definitely many improvements that could be done, but even in it's current state it should perform well enough in most cases, as long as you're not expecting a crazy high view distance. The performance bottleneck is the time it takes to load new chunks. You can adjust the performance settings and force chunks to load faster at the cost of FPS, but if you want to maintain 60 FPS at all times, you'll have to limit the chunk loading speed. Of course having less chunks to load helps, so view distance is naturally limited by the loading speed.

To get an estimate of the performance, try the demo (the standalone version is much faster than the webplayer). The demo actually has the settings turned down a little to make sure it runs smooth on a wide range of machines, so in practice you should be able to get an even longer view distance while still maintaining 60 FPS. You will only run into performance problems if you try to load chunks too fast, for example if the player is moving very fast in one direction, they can "outrun" the loading speed of chunks.

 

Thanks for the reply!

- Material related. I can do that fine. That's not the issue. The game I'm working on requires high modability. So I'll be loading a lot of stuff from a texturepack. Which needs to have it's own individual images. I plan on implementing CTM and other things, including allowing the users to add their own blocks, textures, models etc. So making this easily expandable is key. In short. Using texture atlases is not quite what I was hoping for. But I might have to stitch all the images together into a texture atlas, although I'm not sure how to deal with CTM at that point.

- Performance related
I did some further research since last night. And it doesn't look at all impossible.

Here's an engine running with the exact same system as proposed above. FPS looks great, infinite terrain and the chunks load incredibly fast with an amazing view distance.

And that's running on a system with 4GB ram and an old NVIDIA GTX 260. Now that isn't done with Unity. But it's a proof of concept that it can work and work great.

Your first point. The heightmap. That's more specific to my project. I have a heightmap. Where I can easily get the highest non-air block in a chunk collum. And I can use that information to not draw any chunks above that point. So if there's an overhang. The top of the overhang would be the highest point. Not what's under the overhang. I'm sure there's other ways to do this as well. E.g. have a bool in chunks "isAir = true" When it loads the blocks in the 3d array, if they are all air. Set this to true, and don't load chunks where isAir = true.

Second point. Hills obscuring. It's true that this part might be too much. But I don't have to check for every block in every chunk, just if a chunk is visible. I havn't implemented this i my own yet. So I don't know the exact performance differences. But I think it's definitely worth a try to implement. And you only have to do the check, when it tries to load the chunk. Not all chunks within the view distance every single frame. As for "instantly" loading the chunks as you move over a hill or breaking a block that reveals a lot of obscured chunks. If you can match the speed the above example is drawing chunks. I doubt that would be much of an issue. And I'm sure you can also take measures to start loading chunks that will most likely be visible soon. But lets say this hill obscuring thing is unrealistic. Even just loading the terrain line. Will still be a massive decrease in draw calls.

Looking at the above illustration that's still only 29 chunks to load. Compared to 96. It's not as good as 14. But still a huge improvement.

As for NPC's and other entities. I'd have 2 sets of chunk loading. You have 1 that's rendered on the client and drawn. And one that's simply kept in memory while near it. (There's still no need to draw it) And on a server, these "memory" chunks are loaded serverside and won't effect the client at all. (The number one bottleneck for FPS in these voxelgames are draw calls. Having this system should be faster than drawing all the chunks. And it doesn't need to load these with the same viewDistance. Minecraft for example online spawn mobs in a 30 or so block radius. That means you only need to load chunks into memory, that isn't already loaded. Isn't an air chunk. And is within a sphere radius of 2. And I'm sure after optimisation this can be increased with no problems.

As for the demo. I'm currently on my mac. I think your demo only works on PC? So I've only had a chance to try the web version, which as you mentioned isn't incredibly fast.

Lastly. I didn't expect to see any of these things implemented in a voxel engine. They are very specific and won't be for everyone. I simply replied to a comment by Jason about drawing blocks next to opaque blocks. And that turned into a conversation about optimisation. I simply wanted to know what was currently done in your voxel engine and if it'd have any use for me. Mainly if you had a way to deal with single image textures. Which for me would make it worth the purchase on that alone.

 

Does Uniblocks have ways to reduce draw calls when using unique materials for each block? i imagine it being a bit rough on performance if you're using a separate material for each block. As I said, though, I'm not terribly experienced with that.

 

Well, it still seems to me that your suggestions are mostly unrealistic, but I guess this isn't really the place to discuss that.

Again regarding Uniblocks's performance, since you can't access the demo, I can give you some rough numbers: the demo runs at a view distnace with a 7 chunk (16x16x16) radius, so that's 120 blocks in each direction, though it has a limit of 3 chunks radius vertically. It should run at a steady 60 FPS on pretty much any gaming desktop machine, and loading is reasonably fast, fast enough that you can't outrun it with a reasonable running speed. And that's with pretty conservative settings. You could definitely push the view distance further.

Also to answer your original questions:
Chunks are loaded around the player first, then continue loading outwards.
Block faces are only rendered if they're next to a transparent block.
Chunks that you can't see are still loaded. Chunks that have empty blocks only don't need to build the mesh, so they load much faster.
Octrees are not used.
Several cubes are not combined into larger meshes.

And as for the single image textures, it can be done (maximum of one texture per block), but draw calls could be a problem if you want every block type to have a separate material. See below.

No, there isn't anything special being done about draw calls. In terms of performance, it's basically one additional draw call per material for each chunk in the scene, and yes, this can get pretty rough if you have a few dozen materials.

 

Hello maap,

did you ever use the voxel engine with your oculus? I have a dk2 and want to add it later for the game or are there any plans you add it later to the demo?

Still my main Problem is custom meshes cannot be rotated by 90° steps or random for trees.
But fixed my grass Problem now, using a custom mesh with backsides it really Looks good, thank you

 

Hello maap,
Can you tell me how i can attach an light/partikelsystems to an block, like fire?

 

There shouldn't be any problems with using the Oculus Rift with Uniblocks. I won't be adding it in, but it should be pretty easy to set it up using the Oculus Unity integration package.

You can't really attach anything to blocks, since they don't exist in the scene as GameObjects. You'll need to spawn in lights or particles manually. Check this post for more details.

 

Hello maap,

I have a Problem with my menu sometimes. I copied the Gamescene (which was the demo Scene before) and renamed it to gamemenu. Then I added a canvas and Buttons, added the camera to the highest Level and removed the Player.

the menu scene does not render landscape anymore like it should, and sometimes when clicking the start button and switching to the game Scene it hangs up.

Could you please give me your opinion: If I have many Scenes like Menu, PauseMenu, Inventory etc and I'd like to render landscape in Background, it is better to have one unity Scene and just have a "renderscene" for me and just Switch that renderscene for the menus, or should I have a unity Scene for each?

I also have Problems keeping things "alive" when I Switch unity Scenes...

Thanks a lot,

Firlefanz

 

I used my own enumeration for Scenes now and only have one unity Scene for all.
seems to work much better.

I have the cunk spawn distance right now on 6, and it does not Crash or hang anymore.
When I set it to 8 it hangs around every 2nd start or when populating the landscape,
if I use 9 it always hangs.

Any idea what could cause this?

Thanks a lot and have a nice sunday

Firlefanz

 

Sorry for the late reply, I thought I posted a reply earlier, turns out I haven't...
But yeah, using one scene is generally the better option in this case. Changing scenes would remove all instantiated GameObjects, including Uniblocks chunks.

Sounds like your computer just can't handle so many chunks. Reducing the chunk loading speeds might help here. In the engine settings, lower the values of "chunk spawns limit" and "mesh updates limit".
However, 9 chunks is quite a lot, it's possible that you just won't be able to support that kind of view distance regardless of performance settings.

 

Hello maap,

are there any plans when the next Version of uniblocks will be published? And the new Features it might include?

I finished some Basic works now and I am thinking about the "bigger" Problems.
I want to solve those, which you will not solve, and not the same ones, so a hint would be great!

- Most important: be able to rotate a block on the ground by 90,180,270 or random seed (trees plants etc) degrees
- Water and Lava and falling blocks (when nothing under it would be also a simple solution for that)
- Reduce daylight Underground and have local light by Special blocks like torches

Can you tell me which of those you are working on?

And one question:

I made a new script, called "Chunkupdater". I attached it to the engine.The chunk object is "Chunk" like in the Chunk Manager.

I added an Iteration in the update method like you suggested, but it did not work. I wanted to make certain blocks falling with nothing under them, use it later for lights and particles on some blocks. What is wrong with it?

public GameObject ChunkObject; // Chunk prefab


void Update ()
{
try
{
//Particel
Chunk chunk = ChunkObject.GetComponent<Chunk> ();
// for each voxel in Voxels, check
if (chunk != null)
{
for (int x=0; x<chunk.SideLength; x++)
{
for (int y=0; y<chunk.SideLength; y++)
{
for (int z=0; z<chunk.SideLength; z++)
{
//ushort voxel = chunk.GetVoxel (x, y, z); // the current voxel data
// if (voxel == 22) && chunk.GetVoxel (x, y - 1, z) == 0)
// {
// //chunk.SetVoxel (x, y - 1, z, 22, true);
// chunk.SetVoxel (x, y, z, 0, true);
//
// }
// if (voxel == 200 || voxel == 201 || voxel == 202)
// {
// Instantiate (particlesPrefab, new Vector3 (transform.position.x + x, transform.position.y + y, transform.position.z + z), transform.rotation);
// }
}}}}
} catch
{
Debug.LogWarning ("Chunk Updater Error");
}}

Thanks a lot! Have a nice weekend!
Eric

 

The problem here is that your chunk variable refers to the Chunk prefab, which doesn't really do anything. If you want to update every chunk in the scene, you need to access the chunks that are actually instantiated in the scene.
It's easy to fix, you can just replace the line where you assign chunk with a foreach loop like this:

foreach (Chunk chunk in ChunkManager.Chunks.Values) {
}

You could also update each chunk locally instead, by attaching the script to the Chunk prefab instead of the Engine, so that each chunk runs the script for itself only.

With that, your code should work (I tested it and blocks will actually fall down correctly), but you'll run into performance problems, since you'll be updating hundreds of chunks every single frame. I'd recommend spreading the update process across multiple frames (for example by adding a time delay after each iteration of the loop), or even better, only update a chunk if it has been modified in the last frame (you probably don't need to recheck the same chunk over and over again if it's voxels stay the same).

I will not be adding any specific block logic, so no water, lava, or falling blocks, and also no blocks with light.
I also won't be adding rotating blocks, but I do want to add a rotation setting to custom meshes. That means that you'd still need to create 4 different blocks for different rotations, but you wouldn't need to create 4 duplicate meshes, you'd just set the appropriate rotation for each block in the block editor.

 

Hello maap,

thanks a lot that was a great help. With that, got my water Problem fixed and got troch light now which Looks totally good.

Some minor things:

- if you publish a new Version with Rotation for custom meshes I would first merge that with my changes in my cs code, no problem. Would I have to delete all blocks in block Editor and make new ones? I already have around 100...and would wait with creating more maybe

- we good grass now like your but with only some more Vertices. Would you recomment and is it possible to rotate it on the ground a bit or better make a minor Animation in the mesh itself to create animated grass? Which is more performant?

- I have Portals now. They simply bring you to another Position in the game. I then freeze the Player for around 12 seconds to have enogh time to generate landscape below / around him. Can I force somehow landscape to be created on a certain Point with higher priority? Here some code how I tried to. Perhaps you have better idea.

var player = GameObject.Find ("Player");
if (player != null)
{
Vector3 newPosition = new Vector3 (Globals.Portals.X, 80, Globals.Portals.Y); // todo höhe noch und z nach hinten
//ChunkManager.SpawnChunks(newPosition);
player.transform.localPosition = newPosition;
// for (int j = 0; i<5; i++)
// {
// newPosition = new Vector3 (Globals.Portals.X, 100-j*16, Globals.Portals.Y); // todo höhe noch und z nach hinten
// //ChunkManager.SpawnChunks(newPosition);
// ChunkManager.SpawnChunk(Globals.Portals.X, 100-j*16, Globals.Portals.Y);
// }
Globals.Playerdata.nFrozen = 15;
break;
}

Your hints are very welcome and very helpful! Thanks a lot and have a nice sunday

Firlefanz

 

I don't think you will need to delete any custom blocks. The new rotation setting would just automatically be set to the default one for all previously created blocks.

As far as I can tell it would be very difficult / practically impossible to add any kind of animations to the block meshes, or change them in any way at runtime. If you want to rotate the mesh slightly, you can do it in your 3d modelling program, but you won't be able to rotate it dynamically at runtime.

Loading priority of chunks is already set up in such a way that they will load around the player first, but currently a new loading sequence won't start until the previous one is finished, so you might be seeing some significant delay before the chunks start spawning at the new location.
This will be fixed in the update, so you probably don't need to worry about it. With the new system the chunks should basically always generate almost immediately wherever the player is.

 

I recommend doing animated grass in the shader. Any kind of model animations you'll want to do in the shader, on the GPU.

 

Ah, of course, doing animations in the shader would work. I haven't worked with shaders at all so I completely forgot you can do that. Thank you for the tip!

 

Thanks map, hope to get the new version with Rotation for custom meshes and enhanced mesh spawning soon, that's good News.

Thanks Jason that was a very good hint, I found a perfect shader for grass

 

This might be useful to anyone using Uniblocks. It allows you to set voxels using a string instead of using its ID. I kept forgetting the ids of my blocks, this makes it easier to remember. Hope someone finds it useful.

It looks like this in the example terrain generator script.

Code (CSharp):

1. if (perlin1 > currentHeight)
2. {
3.     if (perlin1 > perlin2 + currentHeight)
4.     {
5.         chunk.SetVoxelSimple(x, y, z, "Stone");
6.     }
7. }

Just add this to the Engine.cs file.

Code (CSharp):

1. public static Dictionary<string, ushort> VoxelType = new Dictionary<string, ushort>();
2.  
3. public void Start()
4. {
5.     for (int x = 0; x < Blocks.Length; x++)
6.     {
7.         Voxel voxel = Blocks[x].gameObject.GetComponent<Voxel>();
8.  
9.         if (voxel != null)
10.         {
11.             AddBlockToDictionary(voxel.VName, voxel.GetID());
12.         }
13.     }
14. }
15.  
16. public void AddBlockToDictionary(string voxelName, ushort voxelIndex)
17. {
18.     VoxelType.Add(voxelName, voxelIndex);
19. }

And this to the Chunk.cs file.

Code (CSharp):

1. public void SetVoxelSimple(int x, int y, int z, string name)
2. {
3.     ushort data;
4.  
5.     Engine.VoxelType.TryGetValue(name, out data);
6.  
7.     VoxelData[(z * SquaredSideLength) + (y * SideLength) + x] = data;
8. }

 

Hi Maap,

I was wondering if it would be possible to only calculate Mesh Colliders for nearby chunks, and have further chunks render without colliders. So ChunkSpawnDistance = 9; ChunkColliderDistance = 4; for example.

Often times we want a nice, long view distance, but don't need colliders at such a long range. Seeing as how generating mesh colliders is a (the?) bottleneck, this could help.

If that doesn't make sense, or wouldn't improve performance much, then I wonder if a separate Engine with a ChunkStartSpawnDistance variable could do the same thing. Then you could potentially use two Engines, one with collisions, one without.