After playing minecraft...

Can any one share sunset skybox?
And any one have this grass and dirt texture http://piccy.info/view3/3943145/3d015268b55b66071ffa24610f9bccd2/orig/

 

If you are asking about our project, then we worked on it for 6-7 months. But we only just started working on in order to actually create a real product, as it started out as a university project And it is really really fun!
Hopefully we can release it within the next 9 months, and have a beta in a few months time.

If you are asking someone else then i cannot answer

 

Some work on sunset and red tint




https://www.dropbox.com/s/7nhqjqvigp1h00x/sunset.JPG
https://www.dropbox.com/s/fvkeplrdbtv9gg4/sunset_2.JPG

 

Anyone ever look into this library for their collision instead of the slow mesh colliders?

http://www.tsarevitch.org/ozcollide/

 

It's an intresting idea. There are other similar libraries (SOLID, OPCODE, RAPID) though it's not clear if they are still maintained, while OZCollide may be more recent.

Despite what the Unity3D docs seem to imply it is perfectly possible to use native code from Unity Free (we're doing it with Cubiquity). However it's not trivial, and you need a C (not C++) interface to the library you are using. There's also the overhead of transferring data across the managed interface and of potentially having multiple copies of the data (in managed memory and in unmanaged memory).

Overall I'm not sure it would be worth it in this case.

 

So David are you using optimized Mesh Colliders on your chunk meshes?

 

With a little effort you can make updates of chunks pretty quick, by simplifying mesh colliders.

In our game (see video above) we use up to 32x32x32 chunks, and we can update it in real-time without problems having up to 6 players online going crazy on the environment with all sort of weapons

For safety we queue each chunk update, and only run one per frame (havent been a problem with more however). So even if it is a frame or two delayed you will never notice. A chunk hit by multiple shots will also only be one update though.

Edit: we just did a test. It took between 1-2 ms to update a chunk for us on a rather slow laptop. (32x32x8 chunk)

 

I was updating and optimizing mesh collides on my voxel project about a year ago, but stopped.

Leaving it un optimized kills the system, but that may have also been due to me no sharing chunk faces and not unloading dependant on distance.

I also started looking at only generating one per frame but never got far

 

In my project I am currently using Unity mesh colliders provided with the same data that is used for rendering. These meshes are opimised in the sense that faces have been merged where possible, but for collision meshes it is actually possible to go further and merge across material boundries (unless you want material properties to affect physics). I haven't done this extra merging yet.

I'd also like to try replacing the mesh colliders with box colliders, though I need an algorithm to pack these together in an optimal way. Apparently this can be faster and more robust.

I don't have any profiling or bottleneck information, though I can say that I use 64x64x64 chunks on my high-end desktop and 16x16x16 chunks of my laptop (I think?).

Edit: I'm also going to make collider generation optional, as for some games it might be enough to just raycast directly against the volume data.

 

This is how i do it. I look through my chunk (chunk size does not matter) and then i redraw my mesh collider based on that. Makes it SO much faster!
Image is from my university report regarding our game.

 

See I started to do that on my old project but I only got to here :



Using this (obviously not finished)

 

Good start, but you could divide it into ALOT less

Took me some time to get my own little home made algorithm right, but it really does help a lot on performance now.

However my algorithm also includes the possibility of making "ramps" between voxels now, to make movement between them easier. Such that you don't have to jump always for example.

 

Please do take into account that this was in my first 2 months of seriously using Unity and I wasn't even using C# ! I want to go back and punch that kid!

I haven't really touched that project in about 8 months, hell it is a mess. Hence why I am starting from scratch

Also note : There is NO open source in what I have created.... All my own work, I like a challenge from time to time

 

I see

We also created ours completely from scratch as it was a part of a semester project

 

Sounds and looks awesome.

PS Anyone who would like to sort of "proof" read my tutorial series when I actually get around to finishing the first few lessons? It would be much appreciated

EDIT : As to the ramp idea, recently I had a fairly simple idea I was going to put into practice for smoothing involving a Midplace Displacement Algorithm (I sorta made the name up) In which it will take halfway between 2 blocks, add a vert, and dependent on the amount of times you run it determines the smoothness.

 

Sure i can look through it.

 

Why a C interface? It says it uses C++.

What about compiling it as a CLR/C++ dll. (The source is included!)

EDIT: If only Unity would allow more than one box collider per game object.... (Having one collider per game object starts lagging around 20k objects)

 

Yes, but the Unity docs state that "The plugin should provide a simple C interface which the C# script then exposes to other user scripts". It's a complicated issue, but basically C++ compilers perform 'name mangling' which means that .dlls are not always compatible between compilers, whereas C doesn't have this problem.

Yes, this is probably a valid option though it is not something I have investigated yet. I'm fairly new to .NET/CLR stuff.

I didn't realise Unity had this limitation... it might make my box collider idea more difficult

Also, remember that Unity is internally using a native code collision detention engine anyway (right? PhysX I think?) so you may not get much benefit from another one.

 

We did play around with a box collider setup! It sucked!

 

Ah, I see... Hopefully the managed C++ dll will fix this problem (I hope)...

Yes, it's quite a troublesome limitation too! I was hoping that by using an external physics library, that you could avoid the "one box collider per gameobject" problem or maybe just have faster mesh colliders. (Assuming there are better ones out there)

EDIT: Also, anybody get any performance boosts from Mesh.MarkDynamic()?

 

Here is the "ramps" i talk about so it is easier to move around with unity's physics:



Edit: the forum does not seem happy to show pictures right now....

 

Now it works...

This is the ramps a was talking about, to make movement in some voxel games easier!

 

Awesome.

 

I should probably try something like this in our tank demo, as it's kinda strange that the tank can get stuck on a one-voxel step. I was actually planning to add the slopes to the tank's collider though, rather than the environment. I'll have to see how that works out.

 

It all depends on the voxel size and the tanks size. As you can see, then we do not do it for a single voxel height as the player got no problem moving over them with a capsule collider.

Might be easier to fix your tanks collider in your case though

 

I made improvement to my MyWorld game - I keep in the mesh renderer component only those materials that are used by chunk. eg i have chunk which consists only of grass and stone - two materials, other 6 materials i remove.

+:
decrease CPU usage by 5 - 6 pct
decrease "saved by batching" value in 3 times
increase FPS by 80-90

-:
increase memory usage from 330-350 to 410mb

 

Your numbers don't seem to make a lot of sense. Saved by batching decreased is bad, if your normal batchcount is therefore increased. those 5-6 percent of cpu usage decrease probably aren't very accurate as well, as this in influenced by everything that runs on your computer. Also, are you checking your memory usage via taskmanager? that would be very unreliable

 

1024 chunks, number of materials 8:

Check immediately after system startup

Before:
Draw calls: 1746 Saved by batching: 1151 (editor mode)
CPU Usage 22-23pct - 8 core AMD 8350 4.1 GHz (standalone mode)
RAM: 346 - via taskmanager, allocated 36mb (GC.GetTotalMemory(false)) (standalone mode)

After:
Before:
Draw calls: 1746 Saved by batching: 336 (editor mode)
CPU Usage 17-19pct - 8 core AMD 8350 4.1 GHz (standalone mode)
RAM: 409 - via taskmanager, allocated 36mb (GC.GetTotalMemory(false)) (standalone mode)

 

In that case, the somewhat lower CPU usage could be due to lower batches the CPU has to combine, reducing some overhead. Although I still dont have a clue where this extra memory usage comes from. But this is probably not in your application as the GC.GetTotalMemory returns the same memory allocation (which is, as far as I know, only from your application)

 

I figured out that i have a memory allocation (60-80 mb of RAM (330-350 to 410)) when i assign new material array to renderer.sharedMaterials

 

Assign new material list use a lot of memory.
For example: Start game - 344mb of RAM via taskmanager, move 10 chunks left - 346mb of RAM via taskmgr - +2mb - pretty good result - without assign new array
Start game - 409mb of RAM via taskmanager, move 10 chunks left - 460mb of RAM via taskmgr - +51mb - pretty BAD result - withassign new array

 

Can anyone help me with this issue? The chunk on top stops rendering before it is completely out of the camera's frustum.

 

You use Frustum culling?

 

I think unity automatically frustum culls, but I haven't had this problem before. I do think this is com frustum culling though, but I can't figure out why this started happening.

 

In my case I had to manually set the bounding box for the mesh object. Something like: renderingMesh.bounds = new Bounds(...)

Normally you shouldn't have to do this though.

 

Your GameObject's Bounds area is probably mismatching the geometry.

http://docs.unity3d.com/Documentation/ScriptReference/Renderer-bounds.html

http://docs.unity3d.com/Documentation/ScriptReference/Bounds.html

Are you assigning the mesh or bounds in any specific way, or handling frustum culling yourself?

EDIT: looks like david beat me on it

 

Are you using mesh.RecalculateBounds();
after creating the mesh?

 

Thanks everyone, recalculating the bounds worked. But could I get a slight increase in performance if I defined the bounds myself in a thread and assigned it manually? Would it be worth it?

 

I expect RecalculateBounds() works by iterating over each vertex in the mesh and accumulating them into a bounding box. This will be fairly slow. If you already happen to know the bounding box then it will be faster (at generation time) to use that. Rendering performance should be the same if your bounding box is as small as the one Unity would have generated.

 

yeah you could probably set your bounding box to the size of your chunks/meshsubchunks. Only thing is that you can possibly reduce the bounds because at groundheight, your mesh probably won't take up the whole chunk (so, you could check for the highest and lowest block in the chunk and set the bounds based on that) If you have mostly vertical chunks (16x128x16), then I wouldn't bother much about the horizontal axis

 

Hello! I spend 1 day on the reimplentation of the use of one material per shader. Look awesome. There is some stats

My CPU: AMD FX 8350 4113GHz 8 cores
32*32 chunks

Old (8 material per chunk go):
Draw calls: 1746 Saved by batching: 1151 (editor mode)
CPU Usage 22-23 % (standalone mode)
RAM: 346 - via taskmanager, allocated 35mb (GC.GetTotalMemory(false)) (standalone mode)

Old (only those materials that are needed chunk)
Draw calls: 1746 Saved by batching: 336 (editor mode)
CPU Usage 17-19 % (standalone mode)
RAM: 409 - via taskmanager, allocated 35mb (GC.GetTotalMemory(false)) (standalone mode)

Now (1 material per shader, texture atlas, 2 materials (opaque, transparent)
Draw calls: 1034 Saved by batching: 0 (editor mode)
CPU Usage 12-16 % (standalone mode)
RAM: 336- via taskmanager, allocated 35mb (GC.GetTotalMemory(false)) (standalone mode)

Let's add some block that require transparent shader (glass)

Draw calls: 1034 Saved by batching: 1023 (editor mode)
CPU Usage 14-17% (standalone mode)
RAM: 337- via taskmanager, allocated 35mb (GC.GetTotalMemory(false)) (standalone mode)

Test mode (1 material per shader, texture atlas, only those materials that are needed chunkl)
Draw calls: 1034 Saved by batching: 0 (editor mode)
CPU Usage 10-13 % (standalone mode)
RAM: 403- via taskmanager, allocated 35mb (GC.GetTotalMemory(false)) (standalone mode)

 

@ Goldbug: how did you implement sun lightning with infinite vertical, I'm struggling with that right now. I haven't found the answer in the ~20-40 pages, since most people go for unique 16x128x16 chunks.

ps: The Everquest next voxel engine presentation as ruined my day .

 

Goldbug, that Infinite Depth video is wicked great!! You should do more trailers with the same style.

 

Titan, what are you using for recording video?

 

This is the Goldbugs video posted on this thread page 71.
But as far as I am concerned, I use fraps.

 

@ZorNiFieD I have made a few, in that particular style you can see these:

To make these, I record with ScreenFlow, and maybe do a smooth fast forwarding with Elasty. Fraps would be equally good for pc. The snow and thunder at the end are just happy coincidence, they just happened at the right time by some miracle .

Just look at my channel, there are tons of videos showing lots of different features.


Also, here is another video showing the development process:

 

As you already figured out, the Minecraft algorithm for sunlight does not work at all for infinite vertical. So I do something very different: I have 2 types of air, regular air, and sunlit air. When I generate the world, any air block above the surface is a sunlit air, which emits full sun light. Any block under the surface (caves, and under trees) is a regular air block. Also light propagates vertically the same as horizontally, so if you dig straight down, it becomes darker and darker just like if you dig horizontally.

 

So I'm running into problems again regarding marching cubes. I'm currently trying to implement support for multi materials (or voxel types). So right now Im assigning the triangles in a dictionary with the blocktype as entry. When the mesh gets generated based on the triangle information, it loops through the dictionary and looks if the blocktype has any triangles assigned, if any, assign them to a submesh. Now this works all great, but I'm having difficulties defining what triangles represents exactly what blocktype. To visualize this, here is a screenshot:



Here,
green represents grass (top layer of the voxel grid),
gray/brownish represents dirt or stone
and the red represents blocktype "air".

As you can see, a lot of triangles represent the air blocktype, while in theory there should be none, as air would be outside the mesh. Now, currently I am interpreting the current blocktype to be at the current sampling position of the marching cubes algorythm (as provided by Titan). Though I'm getting the impression that this is somehow offset. So instead of getting the blocktype at the current x,y,z, I tried to increment every coordinate by 1. This gave much better results from specific angles, other sides of the mountains still didn't look right.

Any idea how to fix this?

 

Hi guys! Can you help me with texture atlas please. I have some problem https://www.dropbox.com/s/oj7dis3gt41dvf7/textureAtlasProblem.JPG
I read that i can avoid this by using padding > 0. But there no difference. I tried different values, but they are higher than the worse.

GibTreaty told me "I just used the Point filtering mode with no padding and I didn't have any problems.". 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

How you avoid this ?

My atlas https://dl.dropboxusercontent.com/u/88902511/AtlasedTexture.png

Sorry for my ugly English, i'm not English ma

 

I just tried Block story, if you build a close building at the surface it's still lit inside, but if you fill it then dig it's dark. This behaviour match your explaination but it sound like a huge drawback to me. Din't any player complain about this ?

@wasstraat65: sorry I don't know, to fix this i made my grass 2 block depth and set air to grass as well for my poc.