Implementation decision: modify existing format or custom

[dougbinks]

As per our earlier discussion and my notes in the Readme.md I prefer extending glTF than extending another format or making a custom one.

All options will have custom binary voxel data as per the questions in issue #4. This poll is about mainly about how we encode the scene description.

This issue is raised to make that decision.

Please add your preference below with details if not extending a known format.

e.g:

1. I am in favour of extending glTF
2. I am in favour of extending .vox
3. I am in favour of extending USD
4. I am in favour of creating a custom format

Note that this if a majority of folk decide to do one thing which I'm not in favour of then it may be best to fork the project. That's a perfectly acceptable result as it would be based on not having the same needs, plus we may be able to cooperate on some aspects (such as the binary voxel data).

[dougbinks]

I have created a poll to help us decide: #5

[Longor1996]

Option 5: I'd prefer to have a custom format... but would like to allow embedding into glTF, via extension.

Embedding into a glTF file could be done via an extension property on any given node, linking to a standalone file via URI (or a buffer, if GLB is used as container), with some index/selector to pick a specific scene/node/volume out of it.

i.e.:

{
  ...
  "extensionsUsed": ["EXT_voxels???"],
  ...
  "nodes": [
    {
      ...,
      "extensions": {"EXT_voxels???": {
        "uri": "???.vxtf",
        "node": "???" // or "volume"
      }}
    }
  ]
}

[scallyw4g]

I'm about 60/40 in the "Extend glTF" and "Custom Format" camps. I voted for "Extend glTF" but could easily be swayed.

I believe @Longor1996 what you're describing as (Option 5) is basically what we'd end up doing if we choose the "Extend glTF" route. The only other option I can think of is to do what the EXT_primitive_voxel proposal suggested, which is to stuff the voxel data into a mesh container. But maybe there's another way to store the voxel data I'm not thinking of ..?

[dougbinks]

@Longor1996 as per @scallyw4g says the Extend glTF option (indeed all options) will have custom binary voxel data as per the questions in issue #4. This poll is about mainly about how we encode the scene description.

I'll update the poll text to clarify that.

[Longor1996]

I believe @Longor1996 what you're describing as (Option 5) is basically what we'd end up doing if we choose the "Extend glTF" route.

No.

I very specifically mean creating a custom format first, but define it such that an extension for glTF that could link into it, may be created in the future.

Picking option 4 would've caused less confusion, I guess...

[scallyw4g]

creating a custom format first, but define it such that an extension for glTF that could link into it [...] in the future

Maybe I'm misunderstanding you, but I'm pretty sure that's the plan, with "first" and "in the future" being immediately consecutive.

ie.

1. Choose container/scene description format (glTF or custom)
2. Define binary voxel storage (custom format)
3. Link 1 & 2 together

I suppose you're suggesting doing 1 & 2 the other way around?

[Longor1996]

creating a custom format first, but define it such that an extension for glTF that could link into it [...] in the future

Maybe I'm misunderstanding you, but I'm pretty sure that's the plan, with "first" and "in the future" being immediately consecutive.

ie.

1. Choose container/scene description format (glTF or custom)

2. Define binary voxel storage (custom format)

3. Link 1 & 2 together

I suppose you're suggesting doing 1 & 2 the other way around?

Again, no.

I mean:

1. Create a container format.
2. Create a scene format that lives inside (1), pointing at (3).
3. Create a voxel format that lives inside (1).
4. Create a glTF extension that links into (1), pointing at (2) or (3) as needed.

[scallyw4g]

@Longor1996 Okay, so the semantic difference between the "Extend glTF" option and what you're suggesting is that in "Extend glTF", we're doing Step 4 from your list above first, whereas you're suggesting we would do it last as a separate step. Correct?

---

Unrelated to the above; do you have specific preferences for encoding for Step 1? ie. YAML, json, bson, protobuf, custom binary .. etc

And could you elaborate on the pros/cons you see for taking the approach you suggest as opposed to "Extend glTF" ?

[Longor1996]

@Longor1996 Okay, so the semantic difference between the "Extend glTF" option and what you're suggesting is that in "Extend glTF", we're doing Step 4 from your list above first, whereas you're suggesting we would do it last as a separate step. Correct?

More or less, yes. I'd rather not have the format directly based on glTF, regardless of it being via the container- or scene-format, as that locks both the evolution and limits of the format directly to glTF.

---

Unrelated to the above; do you have specific preferences for encoding for Step 1? ie. YAML, json, bson, protobuf, custom binary .. etc

Honestly just go for JSON, with some things (like grid indices/hashmaps) optionally having a basic(?) binary encoding.

---

And could you elaborate on the pros/cons you see for taking the approach you suggest as opposed to "Extend glTF" ?

Don't have any specific pro/cons written out (am quite terrible at doing that), aside from this creating a bit more specification work, buuuuuuut... we can copy quite a lot of what glTF does in regards to scenes/nodes/etc. (would have to do so anyway!), so it's not that much.

[dougbinks]

At the moment we have 2 votes for extend glTF, 2 for custom and 1 for other which is a custom format we can embed from glTF, which I see as being custom.

Given that, I think the best approach is that we concentrate on the Voxel Data Format spec and see if we can find common ground there.

Once we have that we can collaborate on a binary voxel data format implementation and see where that leads us. This can be referenced from any other format, with an initial reference implementation using glTF. Any thoughts on that direction?

[Longor1996]

At the moment we have 2 votes for extend glTF, 2 for custom and 1 for other which is a custom format we can embed from glTF, which I see as being custom.

Yep, as I said, I intended to pick option 4, but had a smol brain failure, so it's 2:glTF to 3:Custom.

Given that, I think the best approach is that we concentrate on the Voxel Data Format spec and see if we can find common ground there.

Yep.

Once we have that we can collaborate on a binary voxel data format implementation and see where that leads us. This can be referenced from any other format, with an initial reference implementation using glTF. Any thoughts on that direction?

Yeah, that should work.

---

After a bit of thinking, a fully custom container format may not be necessary, after all; using either ZIP or SQLite (both of which are available everywhere) as a basis would remove a lot of work, leaving us with more time on # 4.