Updated....

Dug a little and found TI-99/4a Font; nice 8x8 bitmap font from my first computer

Have meshing working; no culling; and can output strings in voxel clusters

http://keeperrl.com/

Also on Steam, also GPL.... (well v2; did v3 add something about not charging money? )

Hi d3x0r,

That's a great job you are doing here. And we are really proud to see you are using Blackvoxel as a base for your game.

Maybe the start of a great adventure for you.

The choice of C# is slightly surprising to me  . But why not if you like it... so I'm just curious to know why you choose this language.

Why not a C# robot. I'm not a C# expert at all, but that could be interesting to add one in Blackvoxel. Our long term goal is to add many languages. (The problem will be how to make it in a "clean" way).

The choice was primarily that C# comes with the compiler itself so it can build itself.  If you install C# you install the compiler.  It's certainly not without penalties though... like without resorting to 'unsafe' code you can't use pointers to walk arrays, and every access to an array is bounds checked against the instanced array boundaries.  In C# 'struct' is actually a different behavior from 'class' in that struct is a value type like int or float, where classes are always reference types.  So primitives like vectors are good as struct types, but you can't keep a reference to a struct; you can pass a reference to a struct to a function, but can't say 'use that struct over there for this'.  *shrug*

Adding an interop module could have been done; but not without huge expense.  It's not so easy for MS C# and would have to be done with Mono, which is quite a download; but seems to work pretty well for Unity.

I see you have mentionned that your work is derived from blackvoxel, that is right.
I know your code is at a preliminary state, but there is something very important you must add in your code . As a derived work of a GNU GPL v3 software, you must mention the GPLv3 licence AND original copyrights, both on a Copyright/License files and in the headers of the source code. (GPL V3 Licence).
That's not only for legal reason about the Blackvoxel license, but also for the guys crawling on your github : Even if your game is only in source form at this time, someone could go into your github and take code or assets without knowing licencing conditions. Imagine someone make proprietary software with it or simply use this code without mentionning copyright, they can and end up with troubles with us (Blackvoxel code was legaly registered in order to protect the licence).
Third party libraries should also be listed with their copyrights, authors and licencing conditions. Cross compatibility legal issues should be avoided.
Above legal reason, that's important for authors and contributors to be listed : that could help some to find a job.
I understand (as I remember that by the past, you said) you are not aware of all theses picky legal stuff . But we have worked a lot (and unfortunately spent a lot of time) about these legal details in order to avoid problems.
But, don't worry, we can help you and explain what must be done and even help you to write some of these "legal stuff" files for you.

That could also be interesting for you to know why we made the choice of free software. And why we choose the particular GPL V3+ licence that is a free licence, but somewhat restrictive in some way compared to MIT or BSD like licences : In few words, a software derived from a GPL v3+ free software must be a GPL v3+ free software without exception. That's a way to protect the work for free software programmers : Everybody can use the code freely and make their stuff with it, but in return, they must do the same. Of course, licencing terms have heavy consequences depending on your goals.

I'll spend some time today updating sources; in the process of the porting I created original files and copied header/source file contents as appropriate.  (Actually make that past-tense.)  I have no issue propagating GNU GPLv3 to this

About the font class, that's an interesting developpment. As you know, in Blackvoxel, we made a particular design choice with "8 bit computer style fixed font" kind of text. But as you know the font rendering system is made only for this particular case. The static rendering way of vector font is a good choice. No need for dynamic one that would be... slower. 

Yes I know all about the 'style choices'   I just figured I'd mention it as it was a small source addition (some 3000 lines) and not a lot of work to implement; though does remove stylized look; and ends up making rather fuzzy characters when blown up large.  Looks nice in small cases.... will have to provide a couple different renderings in the future for things like the large text on the main menu.... a slowdown of only a tiny fraction of a percent in the grand scheme; except the one-time hit to render to the texture when a character doesn't exist.  *shrug*  It still fits within the idle time of a frame at 60fps... 

Even if ores aren't un-minable by hand in Blackvoxel, the required quantities to make an airplane are very important for simple hand mining. But I'm not completely sure that every players understand that. In the future, there will be more in-game tutorial and missions to help player to understand what are the best ways. Blackvoxel is a long term project and there is a lot of things remaining to do.

Actually; ores don't last 'forever' but instead are consumed over time, apparently removing the furthest block of ore attached to a seam until it's all gone.  I hadn't played long enough to exhaust an ore until yesterday... then I had to move my coal and tin drills to another vein.

Yea; I didn't actually make it to genuinely making a plane, and instead ended up enabling creative mode and just created one

About physics engines, I can't say what is the best depending on what you want to do. Including vector entities or making multi-grids interactions might mean different approachs. In Blackvoxel, the choice of an unique grid and "pure voxel" interactions is a strong choice. But we understand that someone wanting to make a different game could want some different choices. The two library you mentioned are free and have compatible licence.

The ability to well sandbox code in C# is interesting. C# is a fast and efficient language compared to little scripting ones. Of course, not as fast as C/C++, but C/C++ is unsuitable for doing sandboxed parts(unless wanting to play with heavy hardware processor sandboxing stuff...).

The Blackvoxel Team

Actually javascript is all the craze now; the Chome V8 javascript engine actually emits native instructions and is very fast; amazingly so given the generic-ness of javascript.

Medieval/Space Engineers is C# entirely; they use Havok as a physics engine.  https://github.com/KeenSoftwareHouse/SpaceEngineers

I've seen quite a few C# games coming out so I guess it is a viable platform for rather large spaces.  I'm still iffy on this whole garbage collection thing and would much rather release/delete things in a controlled manner.
I'm using OpenTK as the graphics interface layer (which provides OpenGL and sound in theory)  But I have yet to have any sounds ported.

BEPU has a voxel physics demo - it is the engine for Lemma http://lemmagame.com/ https://github.com/etodd/Lemma  which is another voxel based game.  The demo source includes creating a custom voxel collision shape handler; basically it's a large array of bools instead of building actual box shapes and stuffing them into a compound object.  Will be interesting  

ZWorld.cpp
void ZVoxelWorld::SectorUpdateFaceCulling(Long x, Long y, Long z, bool Isolated)

  UByte * BlocMatrix[3];

This is only a byte, but it's using Sector::Data which is UShort now.

This is OK because there's only 238 types right now.... but will be a problem with voxel type 256 ... or type&0xFF == 0

Was going to mention this....
http://www.volumesoffun.com/implementing-morton-ordering-for-chunked-voxel-data/#more-1755
(references https://en.wikipedia.org/wiki/Z-order_curve http://www.forceflow.be/2013/10/07/morton-encodingdecoding-through-bit-interleaving-implementations/ )

Basically I was playing with unity, and found there's a free voxel engine plugin.  Developed by the same people that did Polyvox.  And saw that article, and after reading the articles thought 'wow maybe that would be nice'

My first test case it turned out the the max distance from (-1,-1,-1) to (1,1,1) was 53.  (even smaller than the 256 that is the distance from (0,-1,0) to (0,0,0) in black voxel)  Which would mean that it would be even better for locality of voxels in cache.

However; that was just 1 case, and the real worst case is a distance of 3080(!). 
7,7,7 center
min 504   00000000000000000000000111111000
max 3584 00000000000000000000111000000000

.....No
The worse case gets worse and worse.... iterating over 0-100,0-100,0-100 the average max distance is 41296(!)

Each point at 7, 15, 31, 63, is increasingly large offset...

-----------------
So ya; ignore this.

this is more of a what-not-to-do.... it looks clever to start... but having reasonably sized sectors is more advantageous... and does nothing but complicate the offsets to wrap between sectors.

Re Deprecated register keyword...

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4340.html
http://stackoverflow.com/questions/10675072/is-the-register-keyword-still-used

I personally disagree that this should be deprecated... but apparently has, and will be removed in C++17.
There are certainly more ideally things the compiler can't figure out, and doesn't. I've seen worse and worse code generation by more modern compilers than things in the mid 90's. 

The argument goes like 'it was only a hint, and the compiler has register coloring anyway so it's meaningless.' but I've seen little effort by the compiler to preserve values in registers, mostly because by nature it assumes things are 'volatile' so it reloads them (I guess, can't otherwise figure why just bad code would be generated).

I certainly don't want people to go to inline assembly for something so simple since that's far from portable between compilers... this really all makes me sad.

I don't remember if I mentioned Alice...
http://www.alice.org/index.php?page=what_is_alice/what_is_alice

And microsoft has another model...
http://msdn.microsoft.com/en-us/library/bb483088.aspx  but that's dead long time... but it's .NET and sorta works... so it's got some longevity maybe

Did some research on implementing glCallLists in my stuff; and learned they have been depricated... in favor of vertex buffer objects... which kind of makes sense, since you can create vertex buffers in threads asynchronous to the display... where glCallLists have to be built on the GL thread context...

so shaders and display buffer building as another pluggable renderer

I find that the resonable relation would be building buffers per shader per image source... or per block type; with shaders would think the 'default' blocks could be computation shaders based on a distance from poly edge and a color scalar...

and those built per voxel sector ....

there's also no multi-indexed buffers... like normals in this world I'd only need a buffer of 6 points, if I could have a index buffer for texture, index vertex and index normal independantly... but indirect uses the same index map for vertex/texture and normal so they all have to be the same length...

http://stackoverflow.com/questions/11148567/rendering-meshes-with-multiple-indices for instance indicates it can be done, but it's more work than benefit.