add EXT_primitive_voxels

[krupkad]

This extension allows primitives to use their attribute data to represent voxel data directly, with a specified grid geometry.

Direct link to spec

[IanLilleyT]

The blender UI and wireframe is distracting. I'm starting to think these diagrams should be rendered as voxels with the native coordinate systems labelled in addition to the cartesian coordinate system.

The images take up too much space and are not aligned. Try using a markdown table with equally sized images.

[IanLilleyT]

There should be a short explanation of how these coordinates map to the memory layout

[ptrgags]

Totally agree, you've described this to me as a "reinterpret cast", but it would be good to describe this in more detail in the spec.

[IanLilleyT]

Diagrams and pictures could be helpful here, like showing how the same voxel grid maps to these different shapes.

[IanLilleyT]

This equation should be reworked now that neighborEdgeCount doesn't exist

[IanLilleyT]

• Inconsistent spacing between [d1,d2,d3], [a1, a2, a3], and [b1, b2, b3]
• It's confusing that the a variables are for beforeCount and b variables are for afterCount

[IanLilleyT]

I think there's a better word than clipped here since the data is being scrunched into a smaller space, not discarded.

[IanLilleyT]

I wonder if boxes should omit this property. If we want to keep it around for consistency, there could be a note saying that it's basically pointless and can be handled with node transforms instead.

[IanLilleyT]

Starting to change my mind on this. I think bounds can be useful for the box shape when the voxel glTFs are coming from a tileset. The base transformation can come from the tileset and the node transforms can be set to identity. This will be more consistent with how ellipsoid and cylinder tilesets are set up, where there's no other way to define the shape of individual tiles besides using bounds.

[IanLilleyT]

It's possible we could remove bounds and store the shape-space min/max in the position accessor's min/max. The position accessor would not have a buffer view defined because the "positions" are defined implicitly by the shape type, min/max in shape-space, and any additional node or tileset transforms.

I think this would be fine in glTF:

When neither sparse nor bufferView is defined, min and max properties MAY have any values. This is intended for use cases when binary data is supplied by external means (e.g., via extensions)

[IanLilleyT]

I wonder if the cylinder and ellipsoid shapes should be optional and the box shape should be required. The average voxel renderer probably doesn't care about shapes besides box. Would that mean a new extension for each non-box shape type?

[javagl]

Nitpick level:

• The inlined example uses before/after, and the last paragraph uses beforeCount/afterCount

Medium level:

• The schema also uses neighboringEdges (instead of padding), beforeCount/afterCount, and minimum/maximum (instead of min/max)

• Is it right that "first-axis-contiguous" means (more generally) that the elements are in lexicographic order?

Veeery high-level (not sure whether I misunderstood something here):

There is before, dimensions and after. Not listing all possible alternatives here, but that information could also be represented with something like globalSize, localOffset and localSize, or globalSize, gridMin and gridMax. They are largely equivalent and can trivially be converted into each other, but ... are there any pros/cons for these different representations?
This may also refer to implementations, which I don't have the slightest clue of. But there's some vague pseudocode in my head:

Grid grid = read("input.bin");
cout << grid.size() << endl; // Prints (10,10,10)
cout << grid.get(5,5,5) << endl; // Prints global element (5,5,5)

Grid subGrid = grid.subGrid(offset(2,3,4), size(4,3,2)); // Creates a local VIEW on the global data
cout << subGrid.get(3,2,1) << endl; // Prints local element (3,2,1), which is ALSO global element (5,5,5)
...

[ptrgags]

@IanLilleyT I had some comments about the spec

[ptrgags]

For the sentence about POSITION, which of these two cases is true:

• A voxel primitive with a POSITION attribute is valid, but the attribute will be ignored
• the POSITION attribute is forbidden.

The current wording sounds like the former (which I think makes sense), just wanted to check.

[IanLilleyT]

Yep, it's the former

[ptrgags]

Suggested change

	- lon/lat/height for ellipsoids
	- longitude/latitude/height for ellipsoids

[IanLilleyT]

Fixed

[ptrgags]

Totally agree, you've described this to me as a "reinterpret cast", but it would be good to describe this in more detail in the spec.

[ptrgags]

In glTF, y is up -- is the cylinder z coordinate pointing in the y direction or the z direction? this should be made clear (perhaps with a diagram)

[IanLilleyT]

I changed the cylinder coordinate names from r/z/theta to radius/height/angle so I hope it's more clear now. The flat top of the cylinder (bounds.max.y) corresponds to height and is positive Y axis.

👍 to a diagram.

[ptrgags]

"first-axis-contiguous" is a term I've never heard before. I find this confusing.

I think you mean column major? (albeit that is a confusing term in 3D. here's an example of row major in 3D) basically "x-major" means it's the first index if you access it array[a][b][c] and therefore the index that changes the slowest. At least I think?

Also see how NumPy describes its arrays as either row- or column- major (the order parameter) for an example with n-dimensional arrays.

[IanLilleyT]

Perhaps that sentence can be reworded. It's row-major access where x changes the fastest. If this were a C array (row major) it would be accessed like array[z][y][x]. I wonder if array[x][y][z] is more typical...

[ptrgags]

If it's not going to be used, should it be forbidden for boxes?

[IanLilleyT]

See #48 (comment)

[ptrgags]

To a glTF user (and not a 3D Tiles user), this is going to sound confusing. what is a "tile"? do you have a concrete example to illustrate this?

[IanLilleyT]

Yeah, I'll need a diagram for this. You're right that calling it a tile is confusing since the padding can be used for other purposes. I'll have to rework this paragraph a bit.

[ptrgags]

I think I see what you're getting at, but a more concrete example, perhaps with a diagram would be helpful

[ptrgags]

The spec doesn't say much about the attributes used here. Some questions:

• Do any of the built-in attributes (POSITION, NORMAL, TEXCOORD_n, etc.) have well-defined behavior in a voxel context? or are they treated the same as custom attributes like _TEMPERATURE here?
• Just to check, are there any restrictions on types? e.g. if I made a matrix attribute, that would work fine? if so, how does it interact with the matrix padding requirements

[ptrgags]

wait is it padding or neighboringEdges? the spec and schema seem inconsistent.

[IanLilleyT]

Fixed to padding

[IanLilleyT]

@javagl

The inlined example uses before/after, and the last paragraph uses beforeCount/afterCount
The schema also uses neighboringEdges (instead of padding), beforeCount/afterCount, and minimum/maximum (instead of min/max)

Fixed to padding before / after and bounds min / max.

Is it right that "first-axis-contiguous" means (more generally) that the elements are in lexicographic order?

Not sure. It matches the order that the coordinates are listed per shape.

There is before, dimensions and after. Not listing all possible alternatives here, but that information could also be represented with something like globalSize, localOffset and localSize, or globalSize, gridMin and gridMax. They are largely equivalent and can trivially be converted into each other, but ... are there any pros/cons for these different representations?

Interesting idea - that sounds more straightforward than the before / after padding fields. A 6x6x6 grid with 1 padding in all directions could look like:

"dimensions": {
    "total": [8, 8, 8],
    "min": [1, 1, 1],
    "max": [6, 6, 6] 
}

And if there's no padding it would just be

"dimensions": {
    "total": [6, 6, 6],
}