Blackbox Voxel Tool

[RAV]

could you show some screen or vid of the precision artifacts?

Sorry, I'm late.

This was how it sometimes looked before the fix for the current size settings:



However, even for larger sizes this can be avoided by painting most cubes wholesome instead of different colours by side.

When going way too large on the settings though, the geometry just goes totally haywire.

Download update version 0.1y


Fixed crash when a frame exceeds its voxel capacity.

Fixed palette management corrupting other frames.

Fixed possible issue with selection on frame switch.

Fixed palette transfers not updating other frames.

Fixed new frame palette not set to current palette.

Fixed colour manipulation while in animation mode.

Fixed boundaries in mass colour modification.


Changed number of slots in palatte from 1024 to 256.
(may increase again later if necessary, but want to see this play out first.)

Changed default frame time modifier step from 25 milliseconds to 1/60 fps.


Added File System. You can now save to file.

key F5 for saving model and palette to file save.bvt
shift + F5 for saving only model to file save.vmp.
ctrl + F5 for saving only colour palette to file save.vcp.

key F6 for loading model and palette from file save.bvt.
shift + F6 for loading only model from file save.vmp.
ctrl + F6 for loading only colour palette from file save.vcp.

The file system allows for many changes while keeping backwards compatibility.
Your old work files will always be usable in newer versions of Blackbox.

Currently the file sizes are relatively large, at about 85 MB for a full scene.
And loading a maximum scene may take several seconds, during which the program seems to freeze.
File sizes and load times will be greatly improved in later versions.

It is possible that a person saves a full scene work to file and gives it to another person.
The other person may have less video memory than the first. In that case the scene cannot be fully loaded.
Though it will try to salvage and load as much as possible from the scene as fits into the smaller memory.

Wooopsie.... let's try again.


Download hotfix v0.1z


Fixed index corruption when moving palette.

Fixed frame time precision.

[Naret]

Sorry, I'm late.

This was how it sometimes looked before the fix for the current size settings:

Seeing your former wireframes and seen this, I think the issue you have is called "T-junctions". It can be partially blamed to the limited precision of digital numbers, but even in real life you cannot represent some values simply by reals. e.g. 1.0/3.0 == 0.333333....
(I'll avoid a long/boring explanation, derailing your dev-thread, but let me know if you want to hear it )

On the positive side, that issue was well known for a long time. (e.g. BSP compiler ran into it). The solution is called "half edge" data structure (or "representation"). You simply extend the way you represent meshes a little bit. Instead of having faces (in your case probably always quads) that hold references to vertices, you introduce a step in-between by referencing to 4 edges that reference to the vertices. (quads->faces[4]->vertices[2])
For rendering, you need indices and vertices, of course. But that's very easy to generate from the half edge representation. The BIG advantage is that edges are shared between two adjacent faces (quads). if you "Split" an edge, your both neighbour will realize this and can generate an index/vertex mesh with taking this split-vertex into account.

The way I've implemented it is to have a "flag" in my "edge" struct that specifies whether the two referenced items are vertices or the two sub-edges from a previous division. This way, during "splitting" I don't even care about the neighbours, as these implicitly will know about it when you bake the half-edge-mesh into a triangle mesh.

there is a lot of further reading of about it, a more visual and practical guide: http://www.flipcode.com/archives/The_Half-Edge_Data_Structure.shtml

It might look a bit exhaustive at first, but it actually is quite simple to implement, BUT this will eliminate 100% of the issue, worth the effort IMHO

[Naret]

sorry for the double post, I think there is no "edit".

An alternative to meshing is "direct rendering" which bypasses this issue completely and opens up a path to a new world of fun

I don't have that many screenshots of it, but here is one where you see some high density recursion next to a very low density and there is no precision error. (in general you work with volumes and not with faces, hence it's hard to create a gap in-between)


it's simpler that meshing.

[RAV]

A well informed and goal oriented contribution. Thank you for your time.

As mentioned, the problem is solved for the current map size and detail level, which is much larger than what is typically done in classic bsp. Don't underestimate just how absurdly huge the scale in pure geometry really is, and all of that in one single scene on screen. Blackbox operates differently from what you assume. The explicit vertex data is in fact unambiguously and perfectly aligned in a way that floating point precision is not a factor in this at all -- not at this stage; though bit length of data is relevant for total number of sub division levels. But it's in the actual rendering calculation of the graphics chip processing each single vertex to the actual camera settings where the floating point precision comes into play and falls apart, and at some point there's no solution to this, other than upping the bits of the render processing itself. This is why mechanical CAD engineering traditionally renders in 64 bits, and there were special and very expensive lines of graphics cards made for this. That's also why some recent games that rely on extreme scale go for 64 bit despite the runtime costs on consumer cards. There's a point in scale so extreme, no data structure can compensate. And Blackbox ever so much scratches on that.

However, Blackbox remains a heavy WIP in all aspects, and the rendering is due for an upgrade sometimes next year. This will notably push its capabilities further. It will most likely stay based on meshes. Thinking the specific principles of Blackbox through, it makes the most sense so far.

[Naret]

You say Blackbox operates differently from what I assume, and your description didn't make it 100% clear to me, hence allow me to ask: Do you have t-junctions in the mesh?

[RAV]

Blackbox does not deal with arbitrary vertex coordinates like bsp does, it is not at this stage that precision is an issue and vertices would start to accidentally differentiate or conflate. But what you describe is relevant in the form of that vertex indexing could possibly still somewhat help even on level of gpu processing, by way it may perhaps cache some part of the individual render calculations. However, there's reasons why I don't do this. Since Blackbox is still wip, there is a specific goal I have with it, and in the end the vertex data will no longer describe meshes in the classic sense, but the meta data required to generate these meshes on the fly, such that neither t-junction nor explicit vertex indexing are planned to factor in.

[Naret]

ok, so you have t-junctions currently. That's why you see the typical artifacts.
t-junctions become a problem on the rasterizer stage, after view projection. it's not dependent on the mesh alignment.
There is a nice explanation for "aligned meshes" aka voxel:
https://blackflux.wordpress.com/2014/02/23/meshing-in-voxel-engines-part-1/

I'm not sure what it means, but I'm very curious to see your future on-the-fly meshes and how you'll overcome the t-junctions

Voxel <3

[RAV]

Thanks, Naret. You're a good read and the links you give valuable resources.

Since that patch I haven't encountered this problem anymore, and if it is there it might be just a single stray pixel on the HD screen, practically unnoticeable. So it has become low priority compared to other concerns, such as greater optimization of memory and performance. I think the reason for why it works out so well right now is that not only are the values for coordinates aligned on a regular grid, they are well-defined, clean, simple, short values by themselves that have a lower chance to provoke trouble in the math, and so leave a lot of headroom in precision for the renderer's own calculations.

The current scale gives me a lot of advantages in further crunching down on memory, and seems to strike a nice balance in size and the voxel count I'll aim for. So considering all that, I currently don't feel inclined to push it further. But if I do, I will have to look for strategies such as the ones you suggested, to make the most out of the significant precision range for a maximum of subdivision levels on the given type's bit size.

[RAV]

Hrrm, but I'm still not settled on the issue. It may still turn out that the things I had originally in mind prove a failure or not worth it in comparison. It's possible I will have to resort to more classic meshing strategies such as described in your latest link. It may turn out that it would simply end up the best of both worlds with the least of problems, all things considered. But we'll have to wait and see. It's a long road, a lot of work.

[RAV]

But it keeps being a tough question. It's trade offs of problems really. The reason I avoided automated mesh optimizations is because of how much it adds runtime costs on model manipulations. Even though there is a variety of methods with more or less costs, even the fastest does add a substantial amount. Blackbox tries to keep that experience more fluid, and rather relies on the artist to sufficiently optimize the grid manually by multi-resolution construction. The poly count of that is less ideal than by auto mesh methods that go beyond cube form. So it's a question of framerate costs in that versus latency on model changes. Add to that, I've grown to like the current cubic organization of the grid composition from a work perspective. The plans on how to optimize memory differently aims to keep that. And rather have artifacts compensated for at no costs by raw precision range. Balancing all these considerations is a difficult question. For the time being I will keep going with the current approach, to concentrate building the rest of the core features. At some point though, when seeing it all play out, a decision must be made which kind of costs we'd rather settle with, or which kind of costs gets along best with the specific case of application. Maybe even multiple render modes for choice. Hrrm.