After playing minecraft...

Wasn't aware it was there, my bad.

Did you ever conclude if the direction finding algorithm was worth the time cut? I know how to do bit wise coding, but that's still some ugly syntax to have to deal with from time to time. Then again, I could probably clean it up with some helper functions.

 

I'm not sure if my direction algorithms are any faster than my previous attempt at a voxel generator. I just wanted them to be a bit easier to use (and look better) this time around.

 

I doubt it's faster to be honest. It means editing any block requires you to edit 27 blocks (likely not cached locations either) to keep the neighbour data up to date. Though the edit time is probably no issue. The problem is more with the complexity of reading the data I guess. Also, 4 bytes per block extra in a badly compressible way is a lot. (500 MB for a 512*512*512 loaded area)

Currently I'm using RLE'd data with ushort block types, and it's fast enough for everything I do with it, special algorithms to deal with the RLE nature help tons (you can check the entire block at once if it's just 1 type). For more random lookup things (like calculating my AI navmesh) I decompress it to a flat array buffer first.

 

I haven't focused so much on speed. I was mostly focusing on getting something that works. Threading is one area that I've been having troubles with because I'm still not entirely sure what the thread should have access to. Like when you tell the thread to do a job, how much information is being given to that thread that was generated by the main thread already. Do you give it a copy of all the block/voxel data beforehand or does it have access to the same voxel data like everything else. Letting it have access to the same voxel data as the main thread makes me run into issues where, if I'm trying to create blocks/voxels constantly every frame as the player then the other thread never gets a chance to access the voxel data. A C# 'lock' has to be used so that the other thread isn't trying to access the data at the same time which can hold up the generation process. But if you let the other thread have a copy of the voxel data, then that means you're doubling the amount of RAM used for voxel data. Not sure how best to do it.

Then there's the issue of offloading the generated mesh data once the thread is finished with it. In that voxel project I linked to, I had a way working with coroutines for it to have a flag/boolean that becomes true once it finishes generating the mesh data. Then another coroutine elsewhere is running to check when it becomes true so that it can hand it off to the chunk that needs the data. The mesh data is just a single instance of a class so that, hopefully, it uses less memory by reusing the same vertex/uv/color/etc arrays. I feel like that's a decent way of doing it but I'd like to move that to process to a thread instead of a coroutine. I use coroutines first just to make sure it works properly. Using the C# 'lock' should be fine here when it comes to offloading the mesh data from the other thread.

 

Currently I have things set up to be staged a bit, with every stage having its own thread. As in, 'generating' a chunk is done on 1 thread, where it has full ownership of the data (this can be chained to have seperate threads for adding structures etc). Then it reaches the main thread, which has ownership for the rest.

My AI-mesh-precalculation reads a chunk into a buffer (basically copying it) and keeps the calculated AI data as ownership. If the base chunk is changed in the mean time, it just precalculates the data again (this does mean data can be outdated for a few seconds though (in practice only up to 50 ms).

Same goes for the mesh-creation thread. It copies a chunk into a buffer, does its things, then passes a System.Action to the main thread that'll write to a mesh for real (no thread safety needed to manage the mesh data, since it's written to from the main thread. Helps with pooling etc)

Using read-write locks for the data tends to help, since atleast in my case the majority of things are reads for physics / reading into those buffers / etc.

Performance/speed hasn't proven to be an issue yet after optimizing the tight loops in the threads, so I haven't looked into using many threads per task type yet.

 

@Zuntatos How do you deal with mesh generation rules for voxels on the edge of the chunk that need to know what the neighboring chunk's voxel is? Do you store the neighboring chunks in a buffer as well?

 

The voxelmetric posted here way back here project got picked up at https://github.com/richardbiely/Voxelmetric ...new dev for it merged in his own voxe project with it... heading in a good direction with a lot of fast optimizations, albeit progressing slowly on features.

I started using it a while back for a project where I made some worldedit/gui tools for it, however the project lacks of lot of what I'd call core engine features that I just don't see myself adding as its not in my skills for it. Still for anyone else looking to get involved in helping an open voxelproject the main dev looks like he could do with some help on it.

 

Yeah I store the nearby slices as well (with 16^3 chunks, that's only 16*16*6 blocks). I don't have ambient occlusion in the meshes so I don't need the diagonals which makes things a lot easier (atleast, I think you need those for vertex AO?)

 

@Zuntatos Well one other reason that you'd need the neighboring chunks besides AO is lighting and transparent blocks (like glass). You wouldn't want to generate (unless you do) faces of the blocks that are between multiple transparent blocks that are the same. I haven't dealt with lighting the blocks or using AO on the mesh. I simply just use realtime lighting with the standard shader/material and an SSAO image effect (I'm lazy).

 

@GibTreaty my lighting currently works via a custom deferred system (precalculated shadows into a 32x32x32 texture3D of type R8, rendered with instancing for distant lights + a screenspace pass rendering up to 32 lights per draw for close lights). It's needed to make normal/specularity/smoothness maps work better.

Currently I don't support partially transparent blocks. Only 'full' cubes that occlude other blocks, and 'meshed' blocks that don't occlude other blocks, can be any shape (a .ply or .obj file in the game folder) and are rendered through instancing.

So I only have to check if the 6 adjacent blocks are a "solid normal block" and use those 6 bools + the type to decide what vertices/uv to render.

It'll be a minor problem when I implement stairs/slabs/glass/transparent water though

 

Hello!
I made a 360 panorama to assess the style of the HardWorld blocks of the world.
Over time, the textures will be redrawn, the effects of the shader, shadows and "play with light" will be added.
Panorama: https://kuula.co/post/7lM4j
This scene in the editor: https://yadi.sk/i/gmu2ncw03RFoQm

As soon as we rewrite the console, it will be possible to compile the public native assemblies (il2cpp) with the demo engine.

 

Hello.
The other day improved multithreading in the engine and it became possible to use more interesting test generators
Straight stuck in them
I recorded a demo in the editor: https://cloud.mail.ru/public/4Jvk/vCoM74rSJ

 

Hello!
I managed to collect the first stable build engine using il2cpp technology
The console was almost completely rewritten, since the initial implementation used AOT-compilation and code execution, which is not allowed with il2cpp.
I also temporarily moved the work with the voxel-model to the main thread.

Control:
ESC - exit
Tab - opening / closing the console
AWSDQE - camera movement
LShift - acceleration
Space - slowdown
LMB - set the block (by default - id = 1, you can change it with the setAddBlock id command)
RMB - remove the block
MMB - launching the sphere of death;D

Commands gen */start*, are able to accept several parameters (id, position, etc.).
Most parameters have default values.
ID can be set from 1 to 6 (6 blocks in total).
If you set ID == 0, a random block structure will be generated.
We recommend that you select NoShadowSync in the Graphics quality.
There's an option with the Unity shadows, but it's just for a look.

Download here (Windows x64): https://yadi.sk/d/6g8VNfOl3Ro3FP

 

The dl fire an alert virus

 

Is for sale? I want this assets.

Thank you.

 

Hello,

I want buy Blockcraft.. Can you send me more info? or price..?

Thank you.

 

"Oct 8, 2010"

I can't believe this thread is still alive...

 

Well I can't believe there are still no fully featured voxel frame works on the store...or built in.. actually I can believe that one.

 

Hi there,

Well there's one indeed!
Voxel Play beta 2 is available on the Asset Store - it aims to provide a full framework for creating voxel/cube based worlds. The asset store page points to a playable demo - I hope you enjoy it - there's a nice list of planned features though like caves, rivers, spawners and world modelling tools.

Cheers

 

I can't believe you don't use the search feature on the asset store, or google. What about voxeland. Works pretty darn well.

 

Yeah that was one I had noticed recently.. glad you put the demo up..from testing the speed and light spread system are good starts.. I'll post in the asset thread with some questions about it and future roadmap before buying though.

You assume I hadn't.. most either don't really go far before being abandoned or never support the features or performance desired... take your example of voxeland its smooth terrain only support, so no cube, building blocks with smooth terrain like 7dtd.. which puts it in a rather limited category for most sorts of games you can make with it, if not for performance reasons smooth terrain, or needing to implement another solution ontop for other key aspects like building. Not forgetting decent worldedit like tools built in with it.. or should I say not in most cases. Put simply most the voxel frameworks on the asset store are not super great, not saying bad.. just not great ..more like ok.. good luck, too much back to the wheel reinventions going on for anything to really progress. I wish unity would step in and do something but we probably still be waiting until 2020 for them to improve height map terrain and associated tooling, shaders etc.

 

I don't recommend one I don't use myself. Voxeland works great. Doing everything in voxels is a performance dumbn move just the terrain is enoujgh if you want to keep performance its better to stick another type of system on top (which I am not recommending one at this time because I am still debating on them or making my own).

Honestly it really sounds like you want someone to sell you a fully made game you can say you made yourself for a hundo...not happening.

 

Video where I create 120km2 of land, I can't link the video, so I share the tweet:
https://twitter.com/i/status/1191847895970000896

 

I have continued to make progress on the terrain generator and now it has slopes and I'm also at an early stage of generating procedural forests. In this video I generate 16km² of forest:
https://twitter.com/MistRealms/status/1269035316289167365

 

I uploaded a video summarizing all the progress I shared on Twitter this year about my project:

 

cool!!

 

Thank you! I'm glad you liked it.

 

@Duende what on earth makes you think posting this stuff here is a good idea?

there's a forum dedicated to showing off your stuff (https://forum.unity.com/forums/works-in-progress.34/), why why why would you post it on page 58 on a minecraft discussion from a literal decade ago.

 

I somewhat agree - the progress you've made with your previous posts are great but they're better suited in that subforum than bumping this ancient thread.