Blackbox Voxel Tool

[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.

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.

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.

Hrrmm. But I must say, considering all the particular circumstances of the Blackbox paradigm, the scale of selection, amount of world changes, absolute multi-rez, different segmentation strategy, multi-dimensional requirements, block morphology, etc pp, it is highly unlikely that any automated mesh optimization method can deal with appropriately and at acceptable costs, compared to what may work in other voxel applications. It is most likely I'll have to stick with the plan and accept T-junction as natural byproduct of all the other features that will make Blackbox interesting, and have the settings take sufficient care of artifacts by decently spaced precision buffer. Most likely that means keeping the current 16 subdivision levels on 32 bit rendering, and 32 levels on 64 bit that may in the future come to market. Nothing's ever set in stone, but that seems right now the best course of actions. Well, but at any case, it would really be nice if I could bring myself to get more menial tasks done first, like a proper GUI for example, it's starting to get somewhat embarrassing.

[RAV]

It's been a good talk. I understand now better what you were trying to say in your first post, by example of bsp. The lesson here is: vertex indexing is not only important to save memory, but to get more use out of the value range from the given precision in the renderer. It's not by chance that this is the usual standard in a 3d pipeline. It is unfortunate I couldn't yet find a method that satisfied me on other requirements. But maybe I will some day. Or find appropriate trade offs.

[Naret]

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.

I agree, a fluid working tool is very important; what is the fastest and most correct rendering worth, if you cannot edit it?

A lot of time there is no just 1 good solution, so I would suggest you have 2 modes, one for editing and one for correct rendering. (A lot of engines, e.g. Unreal Engine, Source Engine, etc. have two modes).
I think nobody cares during editing about the precision artifacts, because they know it's just in editing. In gameplay mode, you can run high-quality meshing and optimizations, because you need to do it just once.

[RAV]

Yes, you're right. I'll have to deal with the mesh more properly some day. Hoped I could kinda ignore that, but probably can't. The issue with artifacts is not super bad right now, but it isn't quite as negligible as I wanted to believe and made it sound. Even 64 bit rendering, though it may help, wouldn't completely eliminate it. Its main benefits would be simply a much greater total number of size levels possible, but not fully address the artifacts on its own. However, resolving this issue is not in my immediate reach right now. I'll have to wait it out for a while and take care of other things until I'm ready for that.

Thanks for your input, Naret. Took me a while to come around, but I'm a bit stretched out with stuff.

[RAV]

Download BVT_020


Fixed unnecessary loads or saves, and button mashing on Load/Save stacking up.

Fixed crash on load/save to a file that was deleted in an active session.

Fixed dangling and backup problems with open files.

Fixed current colour not reseting on palette load.

Fixed conflict of running animation on load.


Reduced remaining artifacts.

Reduced file size by 75% for same amount of voxels.

Reduced runtime memory and improved management on same amount of voxels.


Increased maximum voxels from 1.5 million to 3 million.

Increased maximum frames to 600.


Note:
Loading a full scene can take very long now.
Be patient. Expect more improvements upcoming.

When a single frame has most of the many cubes,
palette changes on it have a noticeable delay.
Though this will be fixed in a future upgrade,
working with such a large scene is strainful at any case.
The true purpose of the greater cube count is to have
more material for animations across multiple frames.

[RAV]

*sigh*

Download hotfix BVT_020b

Fixed geometric breakdown on smallest size levels.

[RAV]

*double sigh*

Download hotfix BVT_020c


Fixed smallest voxel size level not saving correctly to file.