After playing minecraft...

How to make a play on multiplayer and save as a web version?

 

Indeed, that is the expected behavior. And no, users are pretty happy with it. In all this time (first released over 1 year ago), there was a total of 1 user that asked about this, and he was satisfied after I explained, so I would not call it a huge drawback or something that has hurt adoption at all. The reward of having infinite depth is well worth it for me.

If I didn't tell you how it works, you probably would not have noticed.

If you come up with a different algorithm, do let me know,

 

Is the problem the grey lines on the edge of each block? If so, you might be able to fix this by setting filter mode to point, having no padding and editing the textures so that there is no gap between them.

 

To answer that in a manner about as ambiguous as the question:

You use code.

 

I tried different padding values, but they are higher than the worse. I tried different values: 0, 1, 2, 4, 8, 16. And every version I've done it:
"I switch filter mode from billinear\trillinera to point but getting worse. I play with settings (wrap mode, filter settings, format, size, mipmap and others but nothing"

 

I combated the line problem by turning Mip-Maps off

 

I'm thinking about using this same idea, but updating the blocks under a changed block, I change light-air to dark-air if a block is added, or dark-air to light-air if removed.
This would work most of the time, but there is still some bad scenario (If there is a big hole, the whole column wouldn't be loaded). but at the generation/reload, It would just have to iterate top-down the new chunk to change values if an air light value above the top of the chunk is different.
This would work until a player dig a huge column, get out, fill the top, run away to unload, dig another column and come back to the first one by the bottom, and as soon as he go up, this would be fixed.
Also values under around -20 could be kept dark anyway, so the problem above would then only be for a really big tower.
I'm don't know if the overhead would be noticeable on android, but for PC, few mesh rebuild (without colliders) wouldn't be noticed.
Thanks for this idea I'll see what I can come up with.

 

Sweetness. I will be at PAX presenting Block Story in the PowerA booth.

 

Keep in mind perfect is the enemy of good . Also, be careful with generated overhangs, floating islands and trees.

 

I believe the basic problem you are having is that the Marching cubes algorithm generates vertices between voxels. MC processes sets of eight voxels at a time (I call this set of eight a cell, but I'm not sure if that's a common term). If two adjacent voxels have different materials and a vertex is placed between them then you cannot simply interpolate., i.e. you can't say what is halfway between grass and air, as your material identifier has to be either grass or air. If 0 = air and 17 = grass then you can't assign material (17/2)=8.5 as this is a different (invalid) material.

I forget what I said in the article, but basically at some point I was just taking the max of the material identifier in the surrounding voxels and that basically works.

However, this approach (and/or what I described in the article) does have limitations. I have a new system working which addresses these, but I can't discuss it at the moment as I'm hoping to publish it in the coming months. The max approach will at least get you a bit further I think.

 

thanks! I already got the impression there was some offset between the marching cubes algorithm, the vertices position and block position etc. I guess I'll just have to figure out what is exactly where and what represents what.

 

What would be the best way to handle background threads? I currently have it set up so that a new thread is created every frame that the blocks have been changed. Could I have it so that I have one thread that just checks every frame and does changes that way? What would be a good way to limit the background thread to checking only once per frame?

 

I have very fast updating speed on chunks when changing blocks. This is achieved by setting a simple isDirty flag for each chunk. On every frame, it checks for that flag, if it is dirty, the chunk itself is already setup to use a thread where it's needed, a new thread is not created each time, there would be too much overhead. So it uses a thread which is waiting in the background to be used. In some of my videos, you can see the blocks being destroyed and falling with gravity, often so many blocks it is hard to count. Just watch the videos.

 

How would you limit the thread to run only once per frame?

 

if (isDirty) { if (!isFixingDirty){ isFixingDirty = true; FixDirty(); isFixingDirty = false; }}

actually, this: isFixingDirty = false;
would be called once the thread is done processing.

 

I don't think that would help. If the thread is a while loop, it could check millions of times per frame, instead of just once. Is there anyway to limit this other than Thread.Sleep?

 

the thread doesn't loop. The thread just rebuilds the mesh. The update is acting as the loop.

 

look at the 2 minute marker of my video on here:

trust me on this, I know what I'm talking about:

http://www.youtube.com/watch?v=elk5MidISv8

 

hopefully someone grabs the source code to here also if its shown there..

"Voxel-based landscape generation, simplification and management on mobile

Aug 30. 13:30 - 14:30, Ballroom B

The generation of large voxel-based landscapes is difficult when you're dealing with small voxels and thus more vertices and memory. This becomes a significant challenge on mobile devices. This talk builds on real-life Unity indie game dev experience, and you'll learn about multi-threading, octree structures and mesh simplification. We'll create a simple voxel-based landscape and introduce the code behind an open mesh simplifier used in a recently published game. At the end a real voxel-based mobile game will be shown, as a proof of concept."

http://unity3d.com/unite/unite2013/schedule

 

Sounds interesting - I think it's based on this game: http://lostutopia.com/

Unless anyone has different information?

 

I've got a question for alexzzzz:

How did you display the 3d numbers representing the water values as shown in this video?

http://vimeo.com/34789201#

I've tried seperate text meshes, crashed unity instantly as expected when trying to instantiate one for every block

Also tried something with particles, not much luck yet..

I assume you use some replacement shader or similar? how does it work?

 

I was implemented AABB collision into my game and i wanna ask you: how to make raycast without mesh\box collider?

add:
AABB collision works nice and use much less RAM than mesh collider
E.g
Mesh collider: 410mb
AABB: 335mb

Attach geometry to filter and collider (1024 chunks):
Old: 4200ms total, 3600 - collider;
New: 550ms total

 

Here you go. An extremely efficient and simple algorithm for that:
http://www.xnawiki.com/index.php?title=Voxel_traversal

And if you want to understand how it works here is the paper:
http://www.cse.yorku.ca/~amana/research/grid.pdf

It is also very simple to change to figure out which face you are hitting

 

Look at http://0fps.wordpress.com/2012/06/30/meshing-in-a-minecraft-game/

It works pretty well.

 

MyWorld game web player 16x16 and 32x32 chunks version with some bugs and not updater yet digging\placer

https://dl.dropboxusercontent.com/u/88902511/MyGameWebPlayer_16x16/MyGameWebPlayer_16x16.html
https://dl.dropboxusercontent.com/u/88902511/MyGameWebPlayer_32x32/MyGameWebPlayer_32x32.html

I - debug info like in Alezzzzz game)

 

In what sense? Can you help me?

 

I tested an idea I had one day for rendering cube voxels. It's kind of difficult to explain how it works in detail without writing an article but it basically moves most of the load to pixel shaders. It means that you're not so much bound by geometry like you usually do when rendering Minecraft-style voxels. You end up being bound by GPU fillrate instead.

Here are couple of webplayer demos (Shaders are still buggy and don't work on mac):

https://dl.dropboxusercontent.com/u/4320246/Voxels_small/Voxels_small.html
10*10*2 * (64*64*64 chunk) = ~ 52 million voxels drawn

WARNING BEFORE YOU CLICK - web player can hang for quite some time during data generation step in the beginning!
https://dl.dropboxusercontent.com/u/4320246/Voxels_large/Voxels_large.html
25*10*25 * (64*64*64 chunk) * 80% =~ 1 300 000 000 voxels drawn


I managed to run a 4096 000 000 000 voxels scene that was still "interactive" on my Geforce GTX 560. Draw calls get over the roof due to too many chunks. It would probably perform better if I could cull some of those unseen chunks.
Each voxel can choose its texture from a 16* 256^2 atlas. There are some seams since I use filtering and there is no padding between atlas textures.

It ended up performing much better than I expected. There are quite a few drawbacks though
- This is very fillrate demanding!
- Empty or "air" is very expensive to draw
- Floating point error becomes visible pretty soon
- Moire effects become visible for long distance pixels. (Fog tends to hide most of this though)
- Shadows are super expensive
- Seams and no proper AA

Plus sides are that when you have a good fillrate GPU or low resolution then you can draw loads of voxels. You also don't have to have specific geometry handling code other than couple of vertex shaders.

So lots of downsides but I think it could be optimized quite a bit and some of the visual errors might be fixable.

 

Wow that was an insane demo... I ran it on my Geforce Titan and it ran like a dream.

 

Does anyone know how to have a texture with custom mipmaps and still allow me to change the filtermode to point?

 

Amazing! Even drawing 1,300,000,000 voxels with one byte each, you would be using 1.3 gigs of ram. I am boggled at how your memory usages is so low.

 

This is EPIC pixelmind. The concept is great. Would love to see an article on this.

 

Oh no, no. In those demos the data is not unique for each voxel! Like you said, it would take tons of memory and minutes to generate.
This is simply meant to be a demonstration of a somewhat unusual rendering technique. Therefore it's just reusing data for many chunks of blocks. IIRC I used 40 or so different chunks that are then reused. The data is stored as a texture so I can just reference multiple blocks to the same texture data.

I actually don't think this is going to be suitable for FPS style game. It's simply too fillrate demanding to render empty air. However I believe it might work quite nicely if it was used for a bit more distant voxels. Closeup voxels could still be rendered as normal meshes generated on cpu and they would probably cover most of the screen's pixels.

Thanks
I'll look into it once I have refined it a bit. Its not very complicated system. I just need quite a few pictures to explain it since it is quite unusual way to render solid objects.

 

Very impressive PixelMind, I look forward to reading your article.

 

+1, i want do debug my lightning system

 

yeah me too, and I would like to evaluate my density field (and water too later on)

 

Basic question, but for those of you storing your chunks in a Chunk[, ,] array. How do you account for indexoutofrangeexceptions when you encounter minus figures.

For instance, if my guy is at chunk 0,0,0 and he moves west to the next chunk, he'll be at -1,0,0.

 

http://forum.unity3d.com/threads/63...craft/page85?p=1301428&viewfull=1#post1301428

 

I implement water pro to my game and realized that it is very heavy.

Look at the pictures

Simple: https://dl.dropboxusercontent.com/u/88902511/Water_3.JPG

FPS drop down from 470 to 70

Refractive

https://dl.dropboxusercontent.com/u/88902511/water_4.JPG

As you can see fps drop down from 470 to 8)

 

Which noise method do you guys prefer for your terrain? Currently using PerlinNoise but finding it can be kinda slow with larger chunk sizes. Beezir's method is quite good, too (Simplex, I think?)

 

Yeah, simplex is much faster that perlin noise

 

Any news?

 

nope not really, but I'm currently trying to make some kind of sprite manager to debug on a per-chunk basis. When I've come up with something I'll let you know

 

Are there any tutorials or articles available on how to do 'vertex displacement' on blocks? I can't find anything via google. I presume some sort of noise is applied to each vertex?

 

I think the common approach is to offset the vertices by the blocks it is surrounded with. Every non-air block will push the vertex a little bit towards itself.

 

Anyone try implement this? http://forum.unity3d.com/threads/63...craft/page73?p=1135210&viewfull=1#post1135210

 

Also, https://www.assetstore.unity3d.com/#/content/6391

 

Do you have any images of how you want the result to look? If it's just random displacement you can probably just read from a noise texture in the vertex shader, or calculate a hash of the vertex position if you want to avoid a texture lookup.

In my experience your better off smoothing the underlying volume data before you perform the marching cubes surface extraction. Marching cubes works best on a continouous density field (e.g. ranging between -1 and +1). The 'stepped' images you show are typical of running it on a binary field instead, i.e. where ever voxel is either the maximum or minimum value but not in between.

 

Preferably something like this



Where some blocks can have their vertexes displaced and others are traditional "minecraft" looking blocks.

 

Look nice, what the size of your block?

Also, my old vertex displacement

 

The screenshot is from '7 Days To Die' which I have a feeling may have been written in Unity. Currently I'm simply using int arrays* to store block types, then looking up their UVs etc with a switch function, I want to get vertex displacement working for all blocks first before I apply it to just a few blocks. I haven't figured out how to do it without messing the mesh up, programatically generated meshes still kinda confuse me

* Also, are you guys storing your block type as ints or Bytes? I read on StackOverflow that ints may be better because the CPU can access them easier.