After playing minecraft...

I just started learning how to implement pathfinding in my latest voxel-typ game. So far I have only used flat grid graphs from the Astar Pathfinding Project, but now I'm looking at NavMeshes. Can anyone share any experiences regarding this? So far, I have planned to forego automatic navmesh generation and instead just buuild my own navmesh based on my voxel terrain, and send this to the Astar Path script. Since no colliders have to be generated, I could imagine that it's easily done at runtime whenever a block is added or erased.

 

Yes, that's important to keep in mind. I just have some vague ideas about how it might be calculated from the original data (matching vertex positions in optimized mesh data vs block/voxel light data) or done on the fly during optimization. Your results look impressive

 

I've noticed this white dots problem between chunks. Is it possible to solve that? I'd imagine that i can't weld different chunk mesh together and keep under the vert limit.

[EDIT]

I solved this by using a submesh for each material. I saw Alexxx was using this method in one of the iterations of his engine. The over all render quality /mip mapping is wayyyyy better than i was getting previously using a texture atlas.

 

Hey,

@wasstraat65,

Thanks for the quick reply.

On the first issue, I do not think the problem is as you suggested. The reason being is the mesh is not individual block faces, but comprised with a greedy algorithm. While some of the dots do appear on seams on the triangles for each quad, the majority show up within the triangles themselves along the seam on the tiled image. This is what makes me think it is something to do with the math in my shader. I even vaguely recall a post with a similar problem (and a solution), but i do not remember if it was part of this thread (and is part of this thread missing?) or another and have been unable to find it.

As for the issue of the textures looking bad at a distance, you were right i was not using mip mapping. Has anyone use the nvidia tools for generating mip maps? What level of sucess have you had?

Thanks

 

I'm joining in the fun too! \/

I made my own blocky sandbox game. I just did it the brute force way though of instantiating a load of cubes (4096 to be precise!) It works OK just about.

So from my tests I have the following tips:

• Having script components on the blocks can slow things down
• Having more than one material on a block slows it down A LOT
• Try and share one material for all blocks then you can combine the meshes if you need to
• To speed things up have a not too large viewing angle and far clipping plane.
• Having the landscape in sections with empty parent gameObjects seems to speed up instantiation.
• Make your game more fun with lots of different types of blocks!
• Don't try and copy Minecraft!
• People appreciate high resolution textures and non-blocky animals. [o_o]

My algorithm for the high map of the landscape is not very good - it just subdivides a square in 4 adding a little bit of randomness each time, then repeat. If anyone can point me in the direction of some information about generating nice landscapes from seeds that would be nice!

 

Congrats on joining the fun!

I first tried the same way that you mention above. Instantiating cubes. I have to say it is well worth learning the chunk/block array methods. Reading this thread start to finish is very much worth the time. Enjoy!

 

I'm planning to read it all. But at 2457 posts it may take me some time! So I made a quick and dirty version which I could swap out for some nicer method if I get the time. Here's some screenshots. As you can see the terrain is not very smooth:


Welcome to try it HERE if you have Windows 8.

 

Man, this thread is gonna go on and on and on...

 

Nah, just until everyone on the planet has made their own version of Minecraft.

 

Even if I don't plan to do a minecraft or block game this whole thread is still interesting under a technical stand point. Found a lot of usefull info that can be applied on other type of games.

 

Yep. Also lots of other games have used the blocky style. Like Super Mario World:

marble madnes:

and Tomb Raider (early ones)

I think the only difference in Minecraft is the mining and crafting. OK a major difference!

 

Hey, I made a voxel based game I call 'Evolution', and here are some screenshots and a webplayer -

This thread's also been a pretty big help in getting to this point (A week's work is what you see above).

Webplayer-
https://33a37d0ba01dcbaba1a5fbdf543...XY5gCS-ZS0VWUTZYYkZNR28/EvolutionScratch.html

 

You know what would be good?

Voxel tesselating. So that when you look close up at something it's made of smaller cubes. That's a challenge to everyone! \/

 

Thats a shader... anyone with a good rig could do it.
btw, havent seen any voxels with marching cubes lately.

 

Hi All,

I'm the creator of an in-development plugin for block based voxel engines: Liquid Voxels. Basically it adds liquid physics to your voxel world without the need for colliders.

I find myself with some time this weekend and was wondering there were any developers interested in seeing liquid in their voxel worlds? Reply here or in the liquid voxels forum thread, and tomorrow when I get up I'll pick one or two and create interfaces to the engines and send you a copy of your engine back with water in it. Each one should only take an hour(ish) depending on how your engine works.

Before posting a response, please check these couple of small requirements:
1. I'll need a copy of your voxel engine to implement the water for you. If you reply please be willing to send me a copy of your engine and also I'd appreciate it if you would have tested the copy you send me in a new project. It'll save a lot of troubleshooting.

2. I only need two very basic methods from your voxel engine to make the water work: something to set voxels and something to get voxel details.
The get voxel just needs some way of determining if the retrieved voxel type is air or solid (please inform me how you identify air/solid).
Set voxel is to allow the engine to render the water in the terrain (both create and remove water blocks). Please include where to call these methods and if I need to provide anything tricky (world or local space grids etc).

3. I'd like permission to post & cast the results of the integration, ie. I want to throw water around and show it working in your engine on youtube and on my channels (tumbler/twitter/thread) with your permission.

[edit:] 4. another function that would be super helpful is if you had a version of a raycast that returns the first solid voxel it hits, or the last air voxel it hits before hitting the solid one. Not necessary but it's a great helper function if available.

That's about it. I'm really sure people will like the water simulator and it's only getting very limited interest so far. I'm really sure this simulator will work in a huge number of home-grown engines and I'm keen to test it out.

- Ell

 

I really like liquid voxels and would like to put it in my game, but unfortunately, the water in my game acts like a normal game, so I'm going to release my source code for my game Evolution and if you like you can use it for videos or anything without my permission.

Source Code (Anyone is free to use it!) :-
https://www.dropbox.com/s/mjcnkgyoct7yfy7/Evolution.zip

Note:-
This source code is from the older version of the game, I started making the game again from scratch a week ago.
Also, there are no UI elements or inventory system just the basic terrain system and saving and loading.

Ellander, you use the worldGen.Block(x,y,z) for getting blocks and you can use worldGen.FindChunkAt(Vector3).setBlock(block,Coords) for refreshing the mesh and setting the block

 

Heyas Babaji,

No probs. I'll have a look and see how things look, hopefully I'll have something to you in the next 30 min or so.

Ell

 

Hi Babaji,

I setup a scene and tried it out, but I'm getting some render errors that will really not look good once the water starts.
In this movie I start the scene and then click the terrain to remove a block.

I've finished the integration with the water engine, so as soon as this render error is sorted you will get to see water flowing over the terrain.

Edit: it's late here now. I'll check again tomorrow morning for fixes. Just been playing with water in your world. If you can solve that render problem, it will look nice. My liquid engine is using your water block shader and when it renders it's looking quite good.

Ell

 

Thanks for pointing it out! I realised in the playerIO script, at line 44 just add a break, it will fix it, the thing was in the for loop the mesh was updating too fast which caused the errors and by the way the raycasting isn't that accurate. This should fix it.

And also be sure to check out my thread on Evolution

 

Morning Babaji,

Adding the break only helped when manually interacting with the world. The water simulator will get and set blocks several times a second (up to hundreds or thousands if there is a lot of moving water), it seems there is a bug within the mesh generation itself there.

The simulator is all integrated, so I've attached it to this post. To use it:
Open a scene with your voxel world in it - Water only flows within regions.
GameObject -> Create Other -> Liquid Voxels -> Region
Select the region and resize it to be about 100x100x100.
GameObject -> Create Other -> Liquid Voxels -> waterspawner
drag this to where you would like water. set the spawns per second an amount. a full water voxel contains 100 water. so i suggest 10.
Last step is to select the liquid voxels game object and Add Component. add the evolutioncomms script.

you are done, press play and water will work.

ell

 

Any others interested in seeing water in their engines?
I've got free time and integrating is quite quick in most cases.

Ell

 

I just realised that I don't actually have static batching on Unity Free. Which would probably make it draw 4096 cubes slightly quicker!

 

But making water is the fun bit!

It would look better if you adjust the heights of the water cubes too... and have them transparent.

 

Hi Yoonitee,

I agree, but that is a rendering job left up to the voxel engine that the water simulator is in. Liquid Voxels uses the voxel terrain engine that it is in to render the water. Each water unit in the simulator has a volume ranging from 0 to 100, if the voxel engine that the water is implemented in is able to render partial height cubes (and add transparency) then the simulator is quite OK with that. It can provide the voxel engine with the depth of water at the location and the engine can render it how it likes.

Ell

 

Hi, Ellander the mesh generation is fine, because it is multithreaded it takes time to take the job to the other thread and time to take it back, thats why you need some time between placements, so just add a yield return 0 between block updates and it should work just fine

 

Hi Babaji,

Unfortunately in a lot of cases there's 100's of updates per second, which would lead to single digit frame rates with a single update per frame.

I figured I'd take a look and worked out an easy way to guard against mesh re-calls in your chunk code.
I replaced:

Code (CSharp):

1. public void refreshMesh()
2. {
3.         mesh = new Mesh();
4.         mesh = meshBuilder.buildMesh();
5.         meshFilter.mesh = mesh;
6. }

With:

Code (CSharp):

1.     public void refreshMesh()
2.     {
3.         dirty = true;
4.         if(meshIsBuilding) return;
5.         StartCoroutine(RefreshMeshUntilClean());
6.     }
7.  
8.     private IEnumerator RefreshMeshUntilClean()
9.     {
10.         meshIsBuilding = true;
11.         while (dirty)
12.         {
13.             sendMeshBuildRequest();
14.             yield return new WaitForSeconds(.5f);
15.         }
16.         meshIsBuilding = false;
17.     }
18.  
19.     private void sendMeshBuildRequest()
20.     {
21.         dirty = false;
22.         mesh = new Mesh();
23.         mesh = meshBuilder.buildMesh();
24.         meshFilter.mesh = mesh;
25.     }

This ensured a couple of things:

• refreshMesh could never be run twice at the same time on the chunk.
• lots of updates can be rendered at once
• it worked with no need to go changing the way refreshMesh was called.

It could be improved if there was a callback when the mesh had finished rendering; but it turned out well enough, minus a few remaining render artefacts. I also updated the liquidVoxels interface a little to be nicer to the engine.
Video below and new interface added (i'll replace the previous one in the earlier post too).

 

I rolled my own liquid voxel system. I have to say... it took A LOT of work and it's still far from perfect. While i will probably continue on with my own system I think many people would find this useful. It will certainly save a great amount of time and let people focus more on other aspects of their engine or game.

 

I had a go at adding slopes to my landscape. Not sure if I'll keep it.

 

I'm just starting a project, can anyone tell me which is faster: having prefabs ready to instantiate or create the meshes, colliders, uvs, etc... by-hand, real-time? I'm on my character controller atm, I think I can manage the noise-based procedural map generation, but when I'm there, I don't want to make one version with atlas, and one with prefabs just to be able to test those, too much hassle for a lazy programmer. If anyone has any better idea or recommendation, I'm open to learn anything new!

(to tell you the truth, I'm pretty new to this on-fly mesh creation thing)

 

Use meshes for the visual stuff, its much faster to create one mesh instead of 16x16x16 cubes.
For the collision you can also use a mesh, but it should be a greedy mesh.
http://mikolalysenko.github.io/MinecraftMeshes2/ http://0fps.net/2012/06/30/meshing-in-a-minecraft-game/
But you can also write your own collision detections script.

 

This greedy mesh is interesting, but it's going over my head at the moment. I can't seem to figure out how to implement it. Granted, I'm fairly new to game development (and programming) and a voxel game shouldn't be the very first game I'm making... but you know, my game is coming along pretty well.

... Until I get to the physics part of it. There's noticeable choppiness when chunks are created due to using mesh colliders, and so I think the solution is this greedy mesh here.

I read that post, and again it kind of went over my head. I'm wondering if anyone here can give me a few bits of advice, or some help to get me started.

Would be much appreciated.

Edit: to be more in depth with that reply...

Currently I calculate the mesh normally. Then I just use that mesh I calculated for the mesh collider. Now can I have a greedy physics mesh but have the normal visual mesh? I should be able to, right? But then I'd have to do a whole new set of calculations to calculate that greedy mesh, instead of one line of code to say meshCollider.sharedMesh = [mesh I calculated]. Is that what I'm supposed to do?

Let's start with that.

 

That greedy mash thinggy looks awesome, and the performance seems really good... thanks for the links
I was messing around with simplex noise:
https://4dc1486cefcecb24fc1888cfd7c.../0B78qGo9UKeRXek5XNmZzM0o1ODA/html_build.html
I think I can tweak it so it would generate the ground and caves in one pass... (I would use at least 100 block height chunk for that, probably I will go with the 16x128x16, _minecraft_standard_ chunks, in average the top 50-60 would be air block)

anyway, I need a good way of implementing that (looks like a whole bunch of extra book-keeping, careful mesh recalc after removing a block)

 

magic9cube already translated that greedy mesh script into c# for us
no need to reinvent it... and thank you magic9cube, i am also using it

 

Yo Dave, Do you have greedy meshing working with uv maps, ambient occlusion etc?

 

No, i only use the greedy mesh for collision, but i'll rewrite my whole mesh builder script soon.
(because i want to publsh an aplha version of my game on indiedb)

 

many thanks to both of you, I think I have to slightly modifiy it, since my chunks won't be cubes (like 32x32x32) unless I make 128x128x128 chunks, but I think that would be an overload

So generating the collision is what makes the lag? In other words, should I generate the cubes(triangles), draw the sides(those that are visible), etc... and do the collision with greedy mesh, only when the player is close?

thanks in advance

 

You can do it like that, but it would not make any sense when your chunks are gonna be 128x128x128, bacause you are always near to them.
The lag appears when you are assinging the mesh to the mesh collider, so better not use such huge chunks.

 

thanks for the infos, yeah I will go with 32x128x32 or 16x128x16 chunks

my point with 128x128x128 was that I need(?) a cubic chunk (X*X*X) for magic9cube's code

I'm almost done with the hybrid third/first person character controller (for jump I added velocity for simplicity, but I will change that, and there are a few issue that I need to address, but when it's done I will open it up, if anyone is interested)
https://83fcf0c395b6483bb4bb2d01142.../0B78qGo9UKeRXMmxRN090RXRmWEk/html_build.html

 

Does anyone know how to generate a biome map like this?

Spoiler

And how I can make a function like GetBiome(x,y) that returns me the biome id?

 

I would try it with a 2d noise field, like a height map

 

Well, thats what it would look like with frequency: 35, amplitute: 5, persistence 0.35 and 1 octave.

Spoiler

Not what I want, so I tried it with 20 octaves

Spoiler

Looks better, but thats still not what i want.

 

do this: calculate several noise values, for example:
temperature (-30 to 50)
humidity (0 to 1)
height (-100 to 100 )
roughness (0.5 to 1)

these noises can have similar frequency or not, up to you. They should be independent from each other. You can do 2 or 3 octaves or warping for each one if you fancy some randomness.

Then you define a biome as an intersection of noise ranges, for example, tundra is high humidity, low altitude, low temperature, savanna is low roughness low humidity high temperature low height, etc. You can have any amount of biomes you want by having more environment variables.

 

Thank you for the information, but i have no idea how to implement it.

 

ok, here is a simplified version of how you can do biomes:

Code (CSharp):

1. // humidity from 0 to 1
2. float humidity = noise (x * 0.001f, y * 0.001f) * 0.5f + 0.5f;
3. // temperature from -30 to 50
4. float temp = noise (x * 0.001f + 500, y * 0.001f + 500) * 40 + 10f;
5.  
6. if (temp < 0 && humidity > 0.4f) {
7.           // thundra with lots of snow
8. } else if (temp < 0 && humidity <= 0.4f) {
9.           // rocky and cold
10. } else if (temp >= 0 && humidity > 0.7) {
11.          // swamp
12. } else if (temp > 30  && humidity < 0.4) {
13.          // desert
14. } else if (humidity > 0.5) {
15.          // rainforest
16. } else {
17.          // grasslands
18. }
19.  

In this code I just use 2 noise values to determine the biome, you can use 3 or 4 if you want more complexity. It is entirely up to you to adjust the numbers to where they look good. There will be lots of trial and error when generating a procedural terrain.

 

wow, thank you for your help.
but do you know how to make this look more like a real landscape

 

You might be able to get some ideas from reading up on how Dwarf Fortress does it. There are quite a few interviews floating around and most of them have a section related to World Generation.

http://www.gamasutra.com/view/feature/3549/interview_the_making_of_dwarf_.php?print=1

 

Hey uhmmm, sorry to interrupt this biome discussion but I stumbled upon a big problem with my own project. Namely, the character will occasionally walk through walls and thus fall into the infinite void outside the world. Apparently rigidbodies (as my player object has) have problems with non-convex mesh colliders. This happens mostly when walking into a 90-degree-corner; if the player continues moving into it, he will eventually fall through.

Does anyone have a solution for this?

 

@Ryiah thank you for that link i found some really helpfull information on that website.

@Cherno can you describe your problem and tell us how you are generating the collider mesh
i think i had a similar problem a few month ago.

 

I'm using the same mesh for the collider as for the mesh renderer. No shared vertices etc., probably the most basic way of doing this.

Anyway, after some more research I managed to correct the problem by implementing every suggestion from the following thread (I don't know which specific combination actually did it though, but the "Fixed Timestep" value seems to be farily important):

http://stackoverflow.com/questions/9688237/how-to-prevent-colliders-from-passing-through-each-other

I didn't use the custom DontGoThroughThings script mentioned in the link, though.

 

Hey guys, whats the best asset store touch controls package to use for these types of games?
Got everything good and working, just need a quick mobile controls solution.