So, I’ve been busy the last month learning about other methods for rendering the voxels, specially on the GPU, I came across a method called raymarching which use signed distance functions (SDF) to create scenes, it is really powerfull and easy to write, you can create shadows, reflections and other effects with a few lines of code:

In raymarching you use a traditional ray casting method only that instead of advancing at a constant step you advance by searching the minimum distance to a solid in the whole scene:


Image by celarek.at

The main problem with this is that you need to check the distance to all the objects in the scene to determinate how much you need to move, this is ok for 2 or 3 objects in the scene but not for a real (game) scene, you need a way to obtain just the object that falls in the ray direction, you can achieve this by many ways, the simplest one being using a raycast algorithm (Like this fast voxel traversal by Amanatides and Woo) in a grid to obtain the objects and then perform raymarching to get the pixel and other properties of the object. This improves the rendering time and let you have more complex scenes.

This works pretty well but since I need only small voxels (cubes) and no the others SDF so I wrote a small program in C++ to do raycasting on a voxels grid, this image contains a 64x64x64 grid but it supports bigger scenes at +60fps:


So I’m not going to continue what I had in JS using the greedy merging geometry (ala minecraft) but I will continue in C++, I have some issues right now, the main being sending all the voxels data to the GPU is rather slow, I tried writting a software renderer solution but with no luck so far due to speed issues, I’m also reading about OpenCL and CUDA but I’m not sure yet if I should use those. One thing that I’m sure is that I need to migrate the data from a raw array of voxels to a sparse voxels octree.

Anyways, this is still the beginning of this project (and this is by far the hardest thing I’ve ever tried), so I’m feeling a little patient and happy for now 🙂

Greetings.

Progress is going to be a little slower for the next month because I’m taking a break, I’m still working on this whenever I have free time but for the next month or two I’m going to be on other subjects.

This week I implemented the frustum culling to avoid rendering of parts of the world that are not visible, it test against an octree so it is really easy to determinate that large areas are not going to be render.

I also been working a little bit more on optimizing the rendering algorithm, it is better now but there is still work to do on that field.

I did a little research on how to generate a terrain using the perlin noise algorithm, this article on devmag.org was really usefull on this subject, I already did a basic implementation but I have to work more on it to achieve a good result:

I’m going to start working a little on the collision part, mostly allowing to create and remove voxels with the mouse and after that I will work on the lighting system.

Greetings.

So this last week was a little slow for me, I couldn’t work on all the features that I wanted but I did manage to improve the greedy meshing algorithm that I was using.

It works pretty fast now even when removing multiple blocks on several chunks, one of the things I did was to change the way I was doing the merge, in the previous version I had to render both faces of each triangle because of situations like this:

When two voxels shared the same face but the face needed to look in both directions at the same time, the solution was simply to split the face in to two faces:

With this done now I can activate the culling and render each triangle only once.

I also Implemented the octrees to distribute the chunks and be able to do culling (still pending):

I hope to finish the frustum culling this week and maybe do some implementation for occlusion culling.

Greetings.

I’ve been busy last week trying to implement a greedy meshing algorithm based on the article by Mikola Lysenko on the 0FPS blog, It was a bit more tricky than I expected (I still have to optimize it more) but the basic theory for this is pretty straight forward:

This allows me to merge multiple blocks and hide the triangles that are not visible

So far I think it is working fine, it takes quite some time right now (about 50ms) to regenerate the chunk of 16x16x16, which would be about 4 frames in a 60fps application, I will try to reduce this number as much as I can.

Next thing on the list is trying to implement octrees to later perform culling of the chunks.

Greetings.

I’ve been busy the last couple of months: learning a bit of pixelart and story writting and most recently I started to research about voxels and decided to give it a try by myself:

I’m coding it in JavaScript using WebGL, it is more limited that if I just do it on a native environment but I want to see how far can I take this on the web, I’ve seen projects like voxel js that have done a pretty good job usign threeJS.

For now there is no much to see, I’ve been working on this for a couple of weeks now laying down all the basic structures, chunk management an geometry reconstruction:

I’m not targeting to do a game with this but I do want to publish it later as a library along with several examples that I will be developing during the development time; I’ve already have an example of several voxels (around 2M) and it worked fine but it still needs optimization in order to run properly:

That would be all for now at least on this topic of voxels.