After playing minecraft...

I finished up building some trees and other decorations.
my first try to make some caves are the result of very tiny holes^^

the next step is to find out how threading works. i am a really newbie but my changings to the script seems to be nice

 

I'm trying to wrap my head around something regarding dynamic mesh generation.

If each chunk generates some collection of meshes in a 16x16x16 block when it is modified, and the mesh is based on block type (i.e. each block type is its own mesh), and we add faces to the mesh based on whether there is a "transparent" block (water, air, or any transparent building block) immediately adjacent to it, then by my calculations it's possible that you will hit Unity's vertex limit for the mesh if a player creates a 16x16x16 block in your "mesh chunk" consisting of a stack of alternating checkerboard patterns, all of a single block type.

I tried to do just that in one of alexzzzz's earlier demos that he posted but then after about 3 layers I ran off and came back to discover that it had regenerated the terrain in that chunk, and gave up

Is this something any of you have dealt with or are people hedging their bets against a player ever doing that?

Edit: Scratch that, I think I figured it out. In this "worst case" each layer would have 64 blocks, with 16 layers. That's 1024 blocks, at 24 verts each... still well under the limit. Move along...

 

If anyone is interested

Here is my WIP : http://forum.unity3d.com/threads/158783-Civil-A-3D-Voxel-World

Also It is all written by me, no "Denis" kit of minepackage, just pure me.

 

We have implemented a brand new color system.

Now you can make red, yellow and blue dyes, and combine them with sand, snow, wood and wax to paint them.

When mixed with sand, you get colored sand:


You can combine the dyes in any one of 64 combinations. Here are some sand blocks with varying amounts of dye:


Then, you can melt colored sand, to make colored glass, here is purple glass:


You can paint wax too, then make a candle, and the candle will shine that color. Here is a candle made with blue wax

 

I finished up my CaveNoise.
Now i connect the world and cavenoise togehter and trim a random sized hole on each top point of the cave to get some doors
the caves are connected with a walking path in all directions

 

my actually state with the script from denis.
currenty i get no chunk loading lags with FPS up to 60 while loading chunks.

http://uniquboard.de/entwicklung/gridworld/

hit ESC to jump into world

 

Only problem is you fall through the floor of the water. I know that is from an earlier post where you were told to not put colliders on the water (or I think that was it?)

Also, the jump height might be too high? I can jump up two blocks on this.

and movement is too fast

Finally, the flowers shouldn't have colliders, in my opinion

 

Webplayer Update:
Currently i get the Caves. At the moment its a massive landscape destruction but that is the easyest way to fix it
http://uniquboard.de/entwicklung/gridworld/

 

Well guys its been a while since i've posted in this thread.... great work to everyone who's been part of it... my initial interest in this thread spawned from a desire to create a block shaped terrain but not volumetric like MineCraft... I haven't had a lot of time to learning procedural mesh generation and honestly it's a little more than I needed so I did some searching just a few minutes ago and came across a few tools that helped IMMENSELY in my quest and I wanted to share them with any interested people:

WORLD PAINTER: http://www.worldpainter.net/
JMC2OBJ: http://jmc2obj.net/

What I did was:
1. opened up WORLD PAINTER and created the world how I wanted.... i turned off caves and water (need to remove foliage too) and then exported it as a minecraft .world file.....

2. opened said .world file in JMC2OBJ and re-exported it as a .obj file

3. inported said .obj file in blender and zoomed WAY out to inspect it.... and finally exported as a .fbx...

4. dropped .fbx into Unity and almost pooped myself (I was very happy and am now sharing)....

So if you're interested in just a blocky world that is imported as an art asset, this group of programs will definitely speed up the process and give good results... Hope this helps someone out!:mrgreen:

 

Wow thank you very much Mike D, I created the terrain exported it, then finally got it to a 230mb fbx file (should of used smaller world). Then after importing to unity and generating colliders(took about 10mins) I have a fully walk-able terrain.

 

I cleaned the landscape destruction.
i think now i can say "ok that looks pretty nice!"




looks like good cheese

 

What is this "Denis code" people keep mentioning in this thread? Could you link to it please?

 

u only have to read 4-5 Pages before.....
http://forum.unity3d.com/threads/63149-After-playing-minecraft...?p=1080615&viewfull=1#post1080615

 

some sorts of decorations

 

New to this thread (and after reading multiple times those goddamn 71 pages!), after playing a lot with examples given in this thread and coding my own stuffs, i now want to start to code an optimized engine ... but i still have no clue on how to handle threading.
I think i understood basic concepts explained very well by Alexzzz, like how to mesh, how to transform voxel to usable unity prefab, ... but i don't understand how all those things interact together using threading (in background)
If i understand well, it should be like:
Chuck Generation (BackThreading) > Chunk2Prefab (BackThreading) > Meshing (BackThreading) > Show the stuff (Main Threading - Unity)

I have read multiple times a link someone gave in this thread, but even with this ... well, i'm a bit lost, and i know the only thing i'm missing is this threading stuff.

 

Finally, we released Block Story for pc. It is for sale in desura right now.

 

You do not do any prefab. Basically the issue is that you cannot use any class from Unity in a background thread. However, you can do most of the heavy algorithms without Unity for the voxel terrain.

So the sequence we have is more like:

Chunk Generation (back thread) -> Light propagation (back thread) -> Calculating mesh parameters (back thread) -> Creating a mesh (Main thread - Unity) -> Creating a game object for the chunk (Main thread - Unity).

When I say calculating mesh parameters, I mean to calculate the vertex array, color array, uv array, normal array. But then in the main thread you need to create the actual mesh using this data.

 

@goldbug
How do you go about getting block information when calculating the mesh? Do you stop the rest of the program from accessing the block array when calculating a mesh or do you copy the entire array so that the back-thread can do with it as it pleases?

 

I have an array of chunks, I don't put the chunk in the array until after it is generated, so there is no concurrency problem there.

Also, I only have 2 threads: the GUI thread from unity, and a background thread for all the chunk management. The GUI NEVER modifies the chunks, If I mine somehting, it queues a message for the background thread telling it to mine it. This eliminates most of the race condition problems I would have otherwise.

 

Must watch video showing how to craft colored purple snow and red candle:

Must watch about infinite depth

 

I'm curious how many draw calls you guys are getting with a relatively large view distance. I'm easily jumping up over 1000 DC's, either my chunks need to be very small for Unity to batch them (in which case there's tons of draw calls even taking the batching into consideration because the chunks are so tiny) - or Unity doesn't batch them and I'm looking at 1DC per.

http://imgur.com/d8SDF

That's a screen shot of my world thus far (yea, nothing impressive - just got started yesterday). I ended up on 16x16x16 chunks (32^ hit the vertex limit with certain really noisy meshes) - that world is 32x4x16 chunks in size which seems large, but it's entirely possible standing on the top-right corner to see to the top-left corner.

Is this a problem that anyone has solved? Or is it simply a setting you'll have to adjust based on the individual computer (in my case the draw calls don't seem to have any real impact on FPS anyway - I just don't want to go down a road that's going to bite me in the rear later if it's avoidable).

I'm not creating an infinite voxel by the way, in case that's relevant in any way.

Thanks for any input!

EDIT:
By the way, huge thanks to everyone contributing to this thread for getting me started! Incredible amount of awesome advice in these pages.

 

So i had a thought about moving the verts and drew up this picture.

Do you think it would be possible to get this effect?

so you have the outside vertex check to see if there is a vertex below it 1 square down, then move towards 2 verts on a verical axis towards each other so that they form a slope instead of a step. Then have that calculation done at a maximum of like 1 square so that a 1 step would become a slope along 2 tiles and a 2 or more step up would not do the change.

You would end up with a 1 rise in tiles be a slope along 2 cubes, and steps forming a hill would become a 45 degree angle sloped hill.
quick mockup in 3dsmax:

 

So over the break I implemented AABB collision detection and a basic physics engine. It wasn't too bad---the square nature of the world simplify things quite a bit---an octree for collision detection is straight forward and you don't need to get into more complex physics like rotating rigid bodies (at least not to start). It's also all extremely quick and efficient.

I strongly suggest 2 books:

Realtime Colllision Detection
Game Physics Engine Development

These two will pretty much cover you for anything you need. They're both pretty well written.

 

Hey Guys!

One year ago I started a game project called "Cube" Its basically a mixture of Minecraft, Zelda and Animal Crossing.

I started to make some mockups and write down some design ideas. You can find the Project site at http://pixelpizza.de/cube/ and have a look at some Screenshots like this:

I dont wont to write down the whole game concept cause i think that would be too boring for you so i will go on to the next part of the story.

After I had an Idea about what the game could look and feel i started to develop some stuff in Actionscipt and used the Stage3D extension and I came up with this http://pixelpizza.de/cube/Voxels1.html . But then I realized, that my development skills are not that good to make this game and Stage3D was way too complicated for me so i decided to quit.

But now I see what awesome stuff you guys did in Unity in some youtube videos (especially the videos made by the user soulreafer) and now I want to continue this project.

So, I just wanted to ask if someone is interested to develop this game together with me? Its just a fun project so please dont expect any money but who knows... maybe this will gonna get huge!

Or maybe you could give me a hint how I could change the camera into a third person camera. I know there are a ThirdPerson Camera Controller and Camera Components already in Unity but I am not realy sure how to use them

So, goodbye for now
Kevin

 

That looks amazing! I would love to help improve the textures with you but I'm still at school :/


P.S Are you making this in Unity or Flash?

 

Yes, it looks neat.

Oh, man, though, I've totally lost track of the stuff going on in the thread. That's what happens I guess when you have a thread with 1000+ posts...

 

The first Demo (http://pixelpizza.de/cube/Voxels1.html) was made in Flash but i want to switch to Unity now

 

That's the effect I was going for in my Free Terrain. It wasn't as smooth though but it worked.

 

What you are asking is definitely possible. There are methods of doing surface nets or dual contouring that can generate a smooth mesh. I have actually been working on a system for my game using that technique. I am hoping to have a video post soon show casing some of it and gauge user interest. I am trying to work on a voxel package that can make multiple voxel types allowing a lot of visual choices. I would talk more but I am typing from my phone which is not ideal .

-Dane

 

I have a question on AABB Sweet testing for anyone who may know.

I've been implementing AABB for my engine over the past couple of day and, as far as collision detection is concerned it's currently capable of:

1) Quick collision test
2) Slightly more expensive sweep test
3) Ray testing

The collision, as far as I can test, is working perfectly. However, I think I'm missing an obvious solution in terms of response. Currently, my response algorithm is as follows:

Step 1: Get all possible collisions given my bounds and desired movement
Step 2: Sort those collisions by time (normalized 0-1 number for how far into the movement sweep they occur) and - if they are the same time - the magnitude of the collision (so several collisions all at time 0 for example still get sorted by importance)
Step 3: Take the best collision for each facing and clamp my movement accordingly (so if I'm mostly colliding on my right with something - that collision only clamps my right movement)


This works perfectly in terms of never producing a false negative; however, it works less than ideal in terms of false positives (clipping movement that should slide instead). Today I'm going to address this by changing the algorithm to:

Step 1: Get all possible collisions
Step 2: Sort by time, then magnitude
Step 3: Take the best collision overall, resolve it, remove it from the list of collisions
Step 4: While unresolved collisions > 0
-------------- Step 1: Re-run collision check for all unresolved collisions
-------------- Step 2: Take the best collision overall, resolve it, remove it from the list of collisions
-------------- Step 3: Remove any collisions which are no longer valid
Step 5: Profit


This *should* work perfectly I'd imagine - but I can't help but think there's a significantly more efficient way to accomplish said goal (sliding with virtually no false positives).

Thanks for any input!

 

KyleStaves, your algorithm has a tiny bug: step 4.1 assumes no new collisions are generated by the movement clipping.
This may not be the case, especially if the movement is large. There may be new collisions due to the clipping since you are going through a different path when you are sliding. You will be doing this every frame, so movement will most likely never be large enough, and this bug might not matter.

A better implementation is: say you are at position p1 and going to move to position p2.

function movementClip(p1, p2)
{
get all possible collisions sweeping from p1 to p2;
if empty, move to p2, and exit
find closest collision // don't sort, sort is O(n*log(n)) finding the closest is O(n)
calculate point of stop i1. This should be the position of your object when you collide
project p2 along the axis you collided with to calculate i2, for example, if you collided in x, then i2 = (i1.x, p2.y, p2.z) // this works only because everything is axis aligned and it is very fast

move object to i1

movementClip(i1, i2);
}

notice this is a recursive process, and in each iteration, you clip a little more and you can find new collisions. Unless you are having floating point errors, there should be no more than 3 steps, since in each step you stop moving in one of the axis.

This algorithm does the sliding perfectly since when you clip the movement, you continue moving in all axis except the one where you collided.

 

Can't thank you enough goldbug! Your post really made me take a step back and realize what was wrong with my whole collision setup.

I was treating the collisions like a one-time list because, otherwise, I'd keep hitting the same block over and over and never move. I was sitting there trying to figure out how you avoided that with your approach and realized I was considering touching sides to be colliding in my base collision grab; swapping a few < > over to >= <= and now it's only considered a collision if any of the points are inside the other AABB, not just adjacent.

 

Most physics engines actually have "resting" (touching a surface without penetrating) as a special case.

Keeps you from getting weird oscillations due to floating point rounding.

 

I ended up doing exactly that; I have two different calls to check for collisions. One to check for touches, which checks penetration and adjacent surfaces - and then the sweep test which only checks for penetration.



EDIT:
Next step for me is cleaning up everything now that it mostly works and doing some quick optimizations so I can get started building the gameplay out a bit before I revisit the voxel engine. The biggest thing I needed was a priority queue system (building a huge world without a queue leads to delays when interaction with parts of the world built out already).

Anyhow, I found this which seems pretty awesome and figured someone else working on a similar setup may find it useful!
http://www.codeproject.com/Articles/126751/Priority-queue-in-C-with-the-help-of-heap-data-str

 

I have things working more or less how I want before I start in on making the actual game and figured it was time to share a quick video

The lighting is entirely Unity at the moment - but I don't really plan to writing a lighting engine as part of it ever. Anyhow, huuuuge thanks to everyone in this thread - especially goldbug!

https://www.youtube.com/watch?v=AJ290tgXFZA

 

Looks like a solid start Kyle, looking forward to seeing more.

You are probably past this point, but maybe you could find some value in my articles Block Engine demystified.

 

If by "maybe you could find some value" you mean "would have been lost without" then yup! Seriously though, thank you so much for writing those articles - they were invaluable in making this happen in such a short time span.

 

This looks really cool - the problem is that I don't think you thought how this design would work out later down the line. I had a very, very similar playable to this a while ago, but quickly changed the prototype to a 2d perspective cause of exactly that: The perspective. Once you dig deeper, the isometric perspective will totally get in the way, at which point you could resort to changing the perspective, at which point it'd turn into Minecraft.

Isometric perspective in a digging game means that you'll not be able to go deeper into caves without completely confusing visuals or not enough visual information.

 

Well you could fade out blocks that are in the way of the camera, and have the camera rotate at a 90 degree angle when the player changes direction when they begin a new path going right. But I haven't really worked with isometric cameras before but that's how I imagine the solution would be.

 

If you are looking to do an RTS style camera you should look at this project http://www.youtube.com/watch?v=GDmM-BKuuNg. It looks like a very interesting game but I have been using it as a case study for my own stuff. I really wanted to do this style of view but was trying to figure out how it could work and then I seen how he handled it. I think there are probably a combination of things that could be done to make it better but I thought I would share since you mentioned it.

-Dane

 

The farthest block, I guess, is about 400 meters away.

On the screens above the world is split into 64x128x64 chunks. Terrain and light is generated for the whole chunk at once. The chunks are split into 64x8x64 subchunks. Meshes are generated for subchunks. I use texture atlases of 4 high resolution textures per atlas. If a subchunk contains blocks from different atlases then submeshes come to play. In average I get 1 or 2 submeshes per subchunk.

A subchunk has to be very noisy to hit the vertex limit, but anyway it's possible to create two separate gameobjects for a subchunks if its geometry is two complex to fit in a single mesh.

 

I'm afraid it will slow down mesh generation pretty much. We need a straightforward and efficient algorithm but nothing comes to the mind.

PS
Here is a rough implementation:


It takes ~500ms to generate a 32x32x32 mesh, and it doesn't correctly process vertices on mesh boundaries. I'm sure, I can make it faster but not 100 times faster.

 

Just a thought about "smoothing" the terrain. First, each block type need a property that tells if it's construct or not. We wouldn't want "hand-made" walls to behave like ground, won't we?

Second, Why not just calculate mean of surronding points? Just a thought.

By the way, Castle Story did manage to smooth their terrain, so I guess it's doable.

See ya,

WeirdoBc

 

That solution could work, but the player will get annoyed seeing the blocks always there, what you would have to do is remove them completely while the player is behind them. However, if the player wanted to dig them boxes that is where your problems begins because you'd have the player digging boxes that arent there or, you would have to move the camera every time the player changes direction which could get quite annoying..

 

I have been playing with different methods outside of marching cubes and have had some success. I wanted to take it further before showing anything but this discussion interest me too much . Here is a 32x32x32 sphere created and a 32x32x32 terrain mesh created using Quads with a MeshCollider on each. The terrain mesh took ~42ms and the sphere takes ~50ms on a 4 year old 2.5ghz core 2 duo laptop. I don't know what that will be on a decent machine but right now I am happy with the speed.

The results on the land aren't what I was hoping for but this is a very simple generation of land with no special changes to the algorithm for smoothing. I think after spending some more time analyzing this and try to figure out a way to smooth the data more I should be able to get nicer looking results.

-Dane

 

@alexzzzz - Thanks for the input! I hadn't thought about splitting chunks into multiple meshes if they're over the vertex limit - it's a great idea.

Lighting is, at the moment, my big killer in the draw calls - as I'm using Unity's lighting with shadows. I'm most likely going to have to do my own lighting eventually, but I'd really much rather stick with Unity's if I can get away with it (a lot of real time / moving lights in the game - and Unity's light looks so darn good).


Update:
https://www.youtube.com/watch?v=GUcTcwhgQcI

I got a couple of guns in (a blaster and a grenade launcher) and made some massive improvements to the actual world generation itself. I also added a quick toggle to enable/disable the particle effect since it's so performance heavy (it makes throwing grenades all over the screen look like the voxel engine is stuttering when it's really just the darn particles). When I'm less lazy I'll come up with a block destruction effect that's less taxing (with enough explosions I can push it above 10k draw calls which is ridiculous).

 

incredible work! I looked at the mentioned Castle Story and the ground looks just like your example. They smooth grass and looked like they don't smooth dirt or rock. Also their land mass is much smaller, just small floating islands so they probably don't have to deal with mesh boundaries.

 

Not sure if this has been mentioned yet but Minecraft renders anything visible in a chunk that you are in, a chunk is 16x16 blocks I think. Once you're out of them 16x16 it unrenders (I'm talking Y render, not X)

 

Instead of smoothing the entire geometry, I added an extra smoothing layer on top of existing blocky landscape. Without normal smoothing the mesh generation pass takes ~5ms per 32x32x32 chunk.


Normal smoothing is very expensive, it takes extra ~20..250ms per 32x32x32 chunk. And since it is implemented as a geometry post-processing filter, it doesn't smooth normals between neighbor chunks.

 

Have to say though...the smoothing sure looks nice.