Replies: 13 comments 41 replies
-
|
My thoughts on requirements (not set in stone):
|
Beta Was this translation helpful? Give feedback.
-
|
As a game dev (not someone making editors or sims), I agree with these requirements. I'd like to expand on some of these points to add what I'd like to see specifically:
I'll add that it'd be nice to make as many aspects of this format ignorable as possible, to simplify the process of writing an importer or exporter for an application that only cares about a subset of the features. For example, my game uses .vox files to represent block materials. In this application, I only care about a single volume, its size, and the material palette, but not the transform hierarchy. |
Beta Was this translation helpful? Give feedback.
-
|
5. How should voxels map to materials? As the conversation with @mgerhardy below I think my stretch goal 7 is probably a requirement, i.e. we may need a set of extendable attributes and types similar to how glTF manages mesh data. For your block materials .vox might be the simplest option, but just loading the first models of this format without their scene (as you likely do with .vox) should be made pretty simple by design. |
Beta Was this translation helpful? Give feedback.
-
|
My thoughts on potential implementations based on other file formats (an edit of what I posted on r/VoxelGameDev) The format is intended for complete scenes as well as models. There are two main transfer formats in the gamedev space, glTF and Universal Scene Description (USD), and for Voxel formats the MagicaVoxel .vox format. MagicaVoxel .voxThis is a relatively simple format which is extensible, however in my view it does not meet the requirements I have:
glTFglTF is fairly simple. It has some issues dealing with very large scenes (the binary .glb format is limited to 32bit size), but it is extensible so this could be worked around or external assets used. There's a fair amount of tooling around glTF, and hierarchies plus animations should work with this tooling even if they can't load the voxel data extension components. glTF does not have any volume description, however it has extensions for volumetric parameters which are applied to the interior of meshes such as index of refraction and transmission/attenuation. We can reuse these, and add extensions for other parameters (scattering etc.). USDUSD is more complicated, but more powerful. USD has volumes usdVol which are usually represented by an OpenVDB asset. Technically with USD one could likely throw a load of open source code at the problem and with a 40MB library (compiled) solve the problem without any further work than specifying how to handle indexed OpenVDB materials (OpenVDB can handle integer voxels). ConclusionI personally favour lightweight code, and thus glTF. There are simple C and C++ libraries for using it, and the base information is very simple JSON. On the other hand USD is far more powerful and already has volumes. Your thoughts are welcome below |
Beta Was this translation helpful? Give feedback.
-
|
it would be nice to also support RGBA as voxel data and omit the palette. There are formats out there that are storing RGBA values already. Everything in Qubicle for example (https://gist.github.com/tostc/7f049207a2e5a7ccb714499702b5e2fd). So I would say, 32bits and 24bits are also a must have if you don't want to lose data when converting from one format into another. |
Beta Was this translation helpful? Give feedback.
-
|
Agreed, that would come under Stretch goal: other per voxel properties so I would guess we might need to move that to an actual goal? I was considering using something similar to glTF's attributes (which are like OpenGL/Vulkan ones), though I'm unsure if we want the full We certainly want the ability to have a use and a type, i.e.: |
Beta Was this translation helpful? Give feedback.
-
|
So, material/property/attribute... channels? I prefer 'channel', so I'll use that here. A given channels concrete data can be stored either separated or interleaved; so the glTF concept of accessor/view/buffer can be (re)used here... though that doesn't seem to allow tightly packing bits? EDIT: A given set of channels could be defined either globally or locally (per volume). For channel base types, there's quite a few of possibilities:
Then we have channel usage types:
These ^ can probably be simplified/seaprated a bunch. And regarding palettes:
(I definitively forgot some stuff) |
Beta Was this translation helpful? Give feedback.
-
|
Yep these all sound good. We'll likely start with a subset and build from there. |
Beta Was this translation helpful? Give feedback.
-
|
Neat! Let me just quickly dump a few (very shortened) points from my previous notes on this idea... EDIT: Copying without consistency/duplicate checking t'was a bad idea; see replies.
|
Beta Was this translation helpful? Give feedback.
-
|
I think some of this is out of scope of a file format, and some of this is out of scope due to complexity. This isn't an attempt to create a universal file format for all voxel games, it's a file format for transferring voxel content between tools. In detail:
|
Beta Was this translation helpful? Give feedback.
-
|
Woops, sorry! Copying old notes over without checking them was a bad idea. :'D
To summarize:
EDIT: (animation) ...Apparently I can't read today. EDIT 2: (indexing) ...nor write without mixing up more things. Sorry. |
Beta Was this translation helpful? Give feedback.
-
|
What's the goal of this new format ? Is it:
|
Beta Was this translation helpful? Give feedback.
-
|
As per the first sentence I'm hoping to create an open Voxel interchange/transfer format the goal is an open format for transferring models and scenes between voxel editors and engines. It's not a goal to have a really compact voxel representation on disk, nor to have a human-readable format for the metadata. |
Beta Was this translation helpful? Give feedback.
-
That seems backwards? Part of what makes glTF (which is mostly metadata) being JSON so useful, is that it's trivial to parse by humans and machines. And if not JSON (or similar), what else? Is defining an entire tagged-binary-tree (or similar) format, just to store metadata with it, a good use of time/effort? |
Beta Was this translation helpful? Give feedback.
-
|
So it's not a goal to be human readable, nor is it a goal to be not human readable. If we use glTF the metadata would be human readable (though just barely as indices are used rather than names so it's somewhat awkward to parse by human). |
Beta Was this translation helpful? Give feedback.
-
|
First of all, thank you for initiating this discussion and i'm all for it! I already agree with many of the points made.
Those are just some quick things immediately coming to my mind. |
Beta Was this translation helpful? Give feedback.
-
|
An extra note here on things I've read here/elsewhere:
|
Beta Was this translation helpful? Give feedback.
-
|
Possibly relevant to (1): KhronosGroup/glTF#2496 (should this be a separate topic/comment?) |
Beta Was this translation helpful? Give feedback.
-
|
No, that's a good thing to add here if we end up using glTF. |
Beta Was this translation helpful? Give feedback.
-
|
Just also dumping this here: https://pro.arcgis.com/en/pro-app/latest/help/mapping/layer-properties/supported-voxel-formats.htm The time components on voxel layers is also kind of interesting. Also this documentation might give some general ideas: https://eisenwave.github.io/voxel-compression-docs/ And also the way to store the palette must be defined - colors could have names, materials and so on. |
Beta Was this translation helpful? Give feedback.
-
|
For materials if we use the glTF approach then this is an array of named materials, so we can either use array index or a separate palette of names per model, perhaps using different attribute names to clarify the difference. |
Beta Was this translation helpful? Give feedback.
-
|
Do note that, while the Eisenwave Voxel Compression page states that:
The input format it uses to evaluate said compression methods is... unfortunate, to say the least:
Pretty much the same concept that MagicaVoxel uses; effectively point clouds. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Doug, thanks for starting this conversation. From your list of initial bullet points, the first two really stand out to me.
I propose that these two requirements could form the basis of a successful format. We've seen open formats dominate in the past; glTF, OpenGL and Vulkan being good examples. Another comment in the thread that jumped out me was:
I think this is a useful idea, and makes for an attractive method of piece-wise writing reference implementations, and the specification. My preferred method of development looks something like the following:
I've used this method for writing compilers (with formal specifications) in the past, with good success. In terms of the actual format discussion, there does exist a fourth option, which is to define our own custom format. My read on the options presented so far is as follows:
Of the above options, (2) glTF seems like the best candidate to me. This comes with two large caveats; first, glTF appears to broadly operate under the assumption that it is a wire-transfer format, and will be gzip/deflate'd. It does not appear to have any native notion of compression, which we need. Secondly, after briefly reading the specification, I propose that we would not actually re-use much of the existing glTF spec, and instead we would end up stuffing our own specification format to fit inside glTF-shaped containers. While this is not a deal-breaker, it does sound to me like we may be introducing significant friction into our lives, for yet-unknown benefit. I could be wrong about this; I only read the spec for 30 minutes, but that's my initial read. Briefly, it appears we may be able to reuse the following features to store arbitrary voxel data & scene descriptions.
I also read through the EXT_primitive_voxels proposed spec linked above and .. it looks pretty watery to me. It does appear to specify something along the lines of what we're discussing in this thread, but so far looks pretty half-baked, with some academic-looking frills that make me a bit nervous (the implicit volume stuff). The real boon that I see glTF providing is that if we adopt that format, the barrier for applications to bake the voxel representation of the world into traditional triangulated 3D meshes, textures, etc is much lower. The resulting exports could be loaded into traditional 3D editors (Maya, Blender, etc). That said, then we're more talking about an export target for applications, and not necessarily a voxel data interchange format. That observation makes the value proposition of using something like glTF basically boils down to potentially sharing a parser with another export path, which isn't nothing, but isn't much either. -- So.. that all said, I would propose adding a "novel voxel format", option to the list of candidates, with the following qualities: Pros
Cons
Thoughts? I'm between jobs right now and could spend a day to write a simple |
Beta Was this translation helpful? Give feedback.
-
|
I was referencing to points 2 and 3 of his post: I believe that voxel models can be fully animated with those techiniques like a mesh can do. We just lack the format and the tools. |
Beta Was this translation helpful? Give feedback.
-
|
Point 1 is useful for rendering but it's not useful for gameplay since there's no voxel tracking between frames thus if model is altered, temporal consistency is lost. On the other hand, with bone base voxel animation, that doesn't happen and you can achieve what mesh models can't, model alteration and animations at the same time. |
Beta Was this translation helpful? Give feedback.
-
|
I think those interested in frame-based animations are probably after non-destructible models. |
Beta Was this translation helpful? Give feedback.
-
|
For me, bones allow several features to be realised:
At least for the last two points, as was already mentioned, we would need some kind of weight assignment. |
Beta Was this translation helpful? Give feedback.
-
|
I'm pro the idea of using bone animations, but I won't be able to do anything with voxel weights for some time. However as above this should be able to be added. |
Beta Was this translation helpful? Give feedback.
-
|
This is most certainly pointless bikeshedding for now, but: Since the format is mainly intended for the 'transfer' of voxel(scene)s, similar to glTF, would it make sense to call the format vxTF? |
Beta Was this translation helpful? Give feedback.
-
|
Technically I think it would still be a glTF file with extensions, but we could use a name like vxTF to differentiate it from ones without. |
Beta Was this translation helpful? Give feedback.
-
|
I have modified the Readme.md to add Requirements. For changes to these add an issue or PR as this discussion is a bit complex. I've opened an issue for finalizing the Implementation decision: modify existing format or custom. I will then open an issue to discuss the binary voxel data format once I have time to put down some ideas. |
Beta Was this translation helpful? Give feedback.
-
|
There's now a Poll on the implementation decision to modify existing format or custom and I've added an issue to discuss the Voxel Data Format |
Beta Was this translation helpful? Give feedback.
-
|
I'd like to add a suggestion of 2 options: ParquetThe Parquet file format already has internal compression, is extensible in terms of columns that can be added, and is easily converted to the Arrow format for processing, either in memory, streaming from disk or from a memory mapped file. In any case a format that is organized as Structure of Arrays (SOA) ie each type of data is consecutive in memory/on disk is usually allows better compression and also is faster to process using SIMD/GPU than an Array of Structures. If the parquet file cannot be adapted for this use case at least there are many interesting features of the format that could be used. TiffMulti-image TIFFs, with either subfiles and image file directories, also allow unlimited extra channels, the advantage here is that it is already an image format and is designed to be extensible, https://libtiff.gitlab.io/libtiff/multi_page.html It should be possible to design a file format that is can be opened by existing software, and has extra metadata for 3d interchange and visualization. Tiff can also be memory mapped to enable random access reading without consuming GB of RAM. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for these ideas. Note that the file format we're talking about here is the scene description format, and I don't think either Parquet nor Tiff are suitable for that. For the voxel data, both formats are also fairly complex, so I don't think they meet our first requirement: 1. As simple as possible - implementations should be able to be lightweight. |
Beta Was this translation helpful? Give feedback.
-
This is a horrible idea.I appreciate the effort in proposing an open standard for voxel formats, as interoperability is a worthy goal. However, I believe this initiative is premature and, in its current form, risks becoming "yet another standard that no one will use." The fundamental issue is that the solution space for efficient, versatile voxel storage is currently too large and too fragmented. We simply have not converged on a set of dominant patterns that effectively balance all competing requirements. A standard defined now, without the backing of a mature, iterated, and proven implementation, will inevitably fail to support critical use cases. Scene DescriptionThe problem of scene description is already solved by multiple robust, engine-agnostic standards. For engine-agnostic asset and scene loading, why not utilize an existing, widely adopted standard? A glTF extension or an OpenUSD plugin would be vastly superior and immediately integrate with existing mesh-based tooling pipelines, allowing someone to mix mesh and voxel models. Emerging solutions like Bevy's BSN also exist. The requirements listed for scene description are well-covered by the industry; adding a voxel extension for one of those scene description formats would be trivial. And then there's an entirely different camp of people who believe that there's no need for a scene description format whatsoever, because they're building a minecraft game and there isn't a concept of a scene because everything is just chunks. Voxel Data: The Core Problem Lacks ConvergenceThis is the "meat" of the problem, but there are fundamental, unsolved trade-offs that require extensive real-world iteration before a standard can be defined. Geometry & Storage Trade-offsThe geometric representation alone has a vast landscape of options, each with profound implications for performance, memory, and disk usage: Geometry Options: Implicit grids, 3D mipmapped textures, explicit coordinate lists, Octrees, OpenVDB, SVDAGs, Symmetry-aware SVDAGs, etc. Should the format optimize for supercompression and small disk utilization, or should the on-disk and in-memory formats be identical for optimal loading speeds, which is critical for open-world games? With current VRAM caps (e.g., 16GB / 32GB), the in-memory format is often the main bottleneck, which makes a trade-off heavily favoring fast loading more appealing than absolute disk size for open world games, which is much cheaper and easier to add. A standard created today will inherently make an arbitrary choice that will immediately make it unusable for anyone prioritizing the opposite requirement. Material Options: Minecraft-style texture mapping, MagicaVoxel-style palette indexing, block-compressed voxel attributes, some attribute mapping scheme that implicitly derive attributes from geometry, or a mix of the above where you store attribute coordinates somewhere in the geometry then derive some other parts of the attribute coordinates. Should geometry and material be tightly coupled (e.g., deriving attributes from the voxel's geometric structure) for storage efficiency, even though it makes iteration and modification much harder? No one knows the best compromise yet. The person or team who will define the authoritative voxel data format standard will be the one who demonstrates a good balance between these competing priorities through extensive, successful iteration and a performant, shipped implementation. If that implementation sees widespread adoption, its standard will be consumed by multiple clients. It would then be trivial to integrate that into something like glTF. If multiple implementations converge to the same solution, that's when we can start talking about actually standardizing the underlying voxel data storage format. This may never happen if the solution space never converges and that's also fine - see all the GPU texture formats out there: Once a dominant, proven format emerges, integrating it into existing standards like glTF or OpenVDB will be a trivial, downstream task. Defining the standard before that implementation exists is putting the cart before the horse. |
Beta Was this translation helpful? Give feedback.
-
|
If that is all you want, you would just implement it based on whatever your priorities are, then publish the specifications. There's no need to ask for community input. And if it was shown that the format strikes a good balance between competing factors, people will adopt it automatically. MagicaVoxel is an open file format under your definition and checks most of the boxes that you have specified. The only thing that's missing is a standard committee and a way to propose changes / extensions. But that's also what's gonna be missing from your proposed "open format".
Without a standard committee you can also change the format in a way that breaks other peoples extensions.
This was indeed underspecified but not a dealbreaker; it'll be far easier to write this into the MagicaVoxel specification.
I can extend that size by having multiple 256x256x256 models in a scene graph. It's far easier to extract sparsity that way because my voxel coordinates are smaller. If I really want 16bit positions and 16bit material id, that's an easy enough extension to add.
Easy enough extension to add.
The MATL chunk is just a dictionary. Maybe define a your own MATL_ Avoyd chunk.
Easy enough to make it longer.
glTF already define animation of node properties. |
Beta Was this translation helpful? Give feedback.
-
|
So yeah, my point here is that, if you want a better MagicaVoxel format, we can come up with a way to standardize extensions to MagicaVoxel. If you want MagicaVoxel but in glTF, I'm also down for that. But to make this work you really need to:
|
Beta Was this translation helpful? Give feedback.
-
|
I'm unsure what your experience with open source software is since your profile is private, however my experience with open source software development has been that is possible to collaborate on the development of specifications and software with developers without forming standards bodies. Your points about extending .vox are reasonable, but if you read through this discussion, the issues and readme you'll understand some of our reservations about extending it. |
Beta Was this translation helpful? Give feedback.
-
|
There are good reasons for me to keep my profile private, but to the extent that makes this conversation relevant, I'm the maintainer of the dot_vox crate and I have extensive experience working on voxel renderers in the bevy community. And again, I appreciate the fact that you have started this conversation. But when you work with a diverse group of developers, people will have competing priorities, and it will be impossible to get everyone to work together without some kind of standard body and a set of procedures to propose and ratify changes. It doesn't have to be a formal one with full time staff like Khronos; but people need to be assured that breaking changes wouldn't be made to the standard without approval from most stakeholders, and that they can propose changes without being ignored. Without that, this wouldn't be an open file format; this would just be yet another format. People will have the same reservations as you do for the MagicaVoxel format today. Which goes back to my initial point which is that any open standard needs to have a lowest common denominator and a mechanism for extensions. The "lowest common denominator" in our case is the existing MagicaVoxel format. You have to specify that as a baseline, the new format aims to support the capabilities that MagicaVoxel supports today, and nothing else - it's out-of-scope to support datasets with sizes significantly above that, and not required for implementations to support anything beyond 256x256x256 palette indexed models in a scene graph. Then you need to establish a set of procedures for extensions. It doesn't need to be like Khronos; it could just be an RFC procedure with a centralized repository for proprietary extensions. Once enough implementations agree to support a certain extension, that extension can be promoted. Then you iterate on that extension until stakeholders are convinced that this is the right extension to be ratified - only then will it be merged into the core specification as an optional feature. Then maybe after many years, there isn't a relevant implementation on the market that doesn't support the feature - that's when you make it a mandatory feature. See https://github.com/KhronosGroup/glTF/blob/main/extensions/README.md for an example of how this works for Khronos. If it isn't a goal to do both of these two things, please rename this project into something else because it would be as much of an open file format as MagicaVoxel is. |
Beta Was this translation helpful? Give feedback.
-
This is not my experience.
The MagicaVoxel format is in no way open. Ephtracy has never asked anyone if they would like to contribute or discuss changes or features, and as far as I can tell they do not contribute to any open source software.
This is what we are doing, though our lowest common denominator here is wider than that which you assume.
We intend to support datasets with sizes beyond what the MagicaVoxel format supports, and ones which include more than palette indexed models.
I feel the project title is reasonable given our aims, and I don't think arguing about the name is helpful at this stage. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
A short discussion in the Vengi discord led to me mentioning on the VoxelGameDev subreddit that:
I'm hoping to create an open Voxel interchange/transfer format. My thoughts are that I would make this based on gltf's json format for everything but the raw voxel data, which would likely be in RLE encoded binary arrays. It would be great if it could support different bits per voxel (at least 8 and 16) and perhaps other data than just material indices (Avoyd has 8bit density), but that would be a stretch goal.
If anyone's interested in following along with this let me know. I'm thinking of starting by making a spec sheet on Github, and will notify any folk who reply when I get around to putting the first draft up.
Essentially a number of tools such as Vengi and my own Avoyd have outgrown the MagicaVoxel .vox format, and we need something else. This is the place for this discussion and perhaps an initial implementation.
Beta Was this translation helpful? Give feedback.
All reactions