Learning excercise, concocted my own Minecraft style voxel engine

I pushed myself a bit and made a little minecraft style demo. (Just makes a single chunk so far) Had to learn procedural meshes and several other things along the way. So far the main issue is performance, with a single 32x16x32 chunk it is slow to redo the mesh, especially the collision mesh. I'm thinking of making quick one off collision meshes for every MOB in the game (precalculated and assigned based on the possible permutations of cubes around you). It only draws exposed faces, but it will still draw back faces etc. I've included my main code which you can stick on an empty gameobject, select a texture, select the camera object (observer), and it should work.

http://www.preik.net/unity3d/Mineworld/WebPlayer.html

 

Not bad, dont like the pause in between breaking bricks, but good job

I had an idea of making a 3d cube just like that, and playing bomberman on it, you go inside the block ect

Might be cool

 

The delay is what I'm trying to figure out. I think it's mainly due to the collision mesh refreshing.

 

Stutter here too.
If it uses mesh colliders then yes the halt is expected and unavoidable.

But if your world remains cubic, I would strongly recommend against mesh colliders, box colliders will be worlds faster in the end if you need to refresh the mesh collider (which in consequence means rebuilding the collision tree every time again for the mesh collider, thats whats really eating the time) and if the boxes don't have rigidbodies they also have no ongoing collision handling basically (if you want to optimize you naturally still can limit the collision boxes to the cubic areas that are the border and add / remove boxes as required when stuff is added / removed)

 

Since the world is cubic, you don't need colliders at all (assuming you're not planning on having arbitrary physics objects freely interact with the world). You can just use a 3D array to represent the world, and make movement based on that.

--Eric

 

Thanks guys I will look into using cubic colliders...maybe create an array of colliders for whatever needs to interact with the map. (I also thought of doing it manually, but I wasn't sure how to stop rigidbodies from moving with a virtual collider)

 

Okay this works beautifully (just need to update the webplayer), after using collision cube objects even my crappy work laptop can handle the scene. Here's the basics:

- Create a collision cube prefab - just a cube, with a disabled meshrenderer (and a script to transfer dig requests to the main world object)
- When the cubeField master object starts it creates a 5x5x5 grid of these game objects and disables them
- every update, it checks for collidable map pieces around the observer object (the player) and moves them appropriately (to line up with the world in that region), I use a radius of 2 for safety- so I check from x-2,y-2,z-2 to x+2,y+2,z+2
- if the spot on the map being checked is open then I simply disable to appropriate cube
- so I'm not creating or destroying any instances during update, I'm only moving around the cubes each time - though that means looping through 125 cubes
So I will ultimately need to do this for every object that is using rigidbodies to interact.

Edit: I've moved the collision update to FixedUpdate. I've also reduced the checking range to just 1, so I only check cubes from x-1,y-1,z-1 to x+1,y+1,z+1 and it still seems to be stable, obviously a major savings in processing.

 

One thing that gave me significant performance gains with Cubed (a voxel engine-y thing like you have), was to use a series of box colliders for collision. You can check out my code here for it, particularly in Cube.boo: https://github.com/LoganBarnett/cubed

You can also check out a running demo here: Make Daybreak

 

Neat,but it would be helpful to have a pointer or something to know where you are placing and/or breaking blocks.