Proposal: unification of bufferViews and the parameters that goes along with them

[fabrobinet]

Currently we have these different stages to describe buffers:

• buffers , it is a blob of data. Can be text or arraybuffer.
• bufferViews, refer to views of buffers and as a glTF addition have a gl target (array or element) property, so that clients can potentially create a single or minimal number of VBOs for each target ahead of rendering time.

Now we have many places where we refer to bufferViews and the parameters that go along with them are always the same, so I propose to find a name for this concept. The underlying goal beyond being nice for specification purpose is to be able to:

• allow more sharing of data
• preventing a proliferation of root properties each time we need to share data.

IMO one obvious naming is accessor. In COLLADA they are local, but here I propose to have them global, and their definition is a bit different too.

It is what we already have for indices and attributes.
In this case, instead of having:

A mesh like:

    "geom-build04-01": {
        "name": "build04-01",
        "primitives": [
            {
                "indices": "indices_997",
                "material": "VMtl02",
                "primitive": "TRIANGLES",
                "semantics": {
                    "NORMAL": "attribute_1001",
                    "POSITION": "attribute_999",
                    "TEXCOORD_0": "attribute_1003"
                }
            }
        ]
    }

Pointing to attributes:

    "attributes": {
        "attribute_1001": {
            "bufferView": "bufferView_4522",
            "byteOffset": 329448,
            "byteStride": 12,
            "count": 102,
            "type": 35665
        }

And indices:

        "indices_997": {
            "bufferView": "bufferView_4523",
            "byteOffset": 24888,
            "count": 102,
            "type": 5123
        }

Here is the proposal:
We would get exactly the same mesh with one difference: attributes and indices would be under the same root property accessors i.e:

    "accessors": {
        "attribute_1001": {
            "bufferView": "bufferView_4522",
            "byteOffset": 329448,
            "byteStride": 12,
            "count": 102,
            "type": 35665
        },
        "indices_997": {
            "bufferView": "bufferView_4523",
            "byteOffset": 24888,
            "count": 102,
            "type": 5123
        }

This becomes more interesting when it comes to animations and especially for the TIME parameter:

Currently we have:

 "animations" {
    "animation_0""
   {
    "parameters": {
        "TIME": {
            "bufferView": "bufferView_4524",
            "byteOffset": 0,
            "count": 901,
            "type": 5126
        },
        "rotation": {
            "bufferView": "bufferView_4524",
            "byteOffset": 219844,
            "count": 901,
            "type": 35666
        },
        "scale": {
            "bufferView": "bufferView_4524",
            "byteOffset": 198220,
            "count": 901,
            "type": 35665
        },
        "translation": {
            "bufferView": "bufferView_4524",
            "byteOffset": 209032,
            "count": 901,
            "type": 35665
        }
    }
}

I propose doing this:
Note: below the parameters are under animations and accessors would be a root property

 "animations" {
    "animation_0""
   {
    "parameters": {
        "TIME": "accessor_0",
        "rotation": "accessor_1",
        "scale":  "accessor_2",
        "translation":  "accessor_3",
    }
   ....
   }
}

    "accessors": {
        "accessor_0": {
            "bufferView": "bufferView_4524",
            "byteOffset": 0,
            "count": 901,
            "type": 5126
        },
        "accessor_1": {
            "bufferView": "bufferView_4524",
            "byteOffset": 219844,
            "count": 901,
            "type": 35666
        },
        "accessor_2": {
            "bufferView": "bufferView_4524",
            "byteOffset": 198220,
            "count": 901,
            "type": 35665
        },
        "accessor_3": {
            "bufferView": "bufferView_4524",
            "byteOffset": 209032,
            "count": 901,
            "type": 35665
        }
    }

This would allow to share TIME in two ways:

• explicitly share the accessors when the same TIME parameter is used multiple times in the same animation
• be able to make aggressive size optimization, when for different animations the same TIMES values are used. (and this would also work for other parameters too..)

Finally, some techniques and shaders will probably require some buffers as input. Having accessors will allow to bring also generic data that are not related to meshes or animations...

[fabrobinet]

Just summarize pros and cons:

Pros:

• no change for meshes.
• allows to share parameters in animations
• should be able to handle any kind of shared buffer without having to add new root properties.

Cons:

• one indirection for animations

[tparisi]

how big of a win is this:

allows to share parameters in animations

Because the other two "pros" aren't "pros" they're just non-cons

On Mon, Oct 21, 2013 at 1:41 PM, Fabrice Robinet
notifications@github.comwrote:

Just summarize pros and cons:

Pros:

• no change for meshes.
• allows to share parameters in animations
• should be able to handle any kind of shared buffer without having to
  add new root properties.

Cons:

• one indirection for animations

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/161#issuecomment-26754227
.

Tony Parisi tparisi@gmail.com
CTO at Large 415.902.8002
Skype auradeluxe
Follow me on Twitter! http://twitter.com/auradeluxe
Read my blog at http://www.tonyparisi.com/
Learn WebGL http://learningwebgl.com/

Read my book! WebGL, Up and Running
http://shop.oreilly.com/product/0636920024729.do
http://www.amazon.com/dp/144932357X

[fabrobinet]

@tparisi I think I explained it above :) (sorry for the long read) - where I take TIME as an example, i.e Memory/file size optimization.

[pjcozzi]

@tparisi some of the motivation is in #157 where I noticed that the converter duplicates sections for TIME in the buffer, where the converter could notice this and just give each TIME parameter the same byteOffset into the same bufferView. Here, @fabrobinet is taking it to the next level by basically reusing the entire TIME parameter.

Given the glTF vision of easy-to-implement, I am very cautious of adding a new level of indirection. Can we merge bufferView and this new accessor concept into one property? I believe @fabrobinet and I discussed this at length, but I don't recall why it was shot down.

[fabrobinet]

if you merge them, then you lose this:

bufferViews, refer to views of buffers and as a glTF addition have a gl target (array or element) property, so that clients can potentially create a single or minimal number of VBOs for each target ahead of rendering time.

[fabrobinet]

Also:

• the indirection would be only for animations. This change doesn't really impact meshes.
• even we if were changing buffer design, the indirection would still be there. This indirection is for referring to object, it is the price to be able to share data which should take priority (IMO).

[pjcozzi]

bufferViews, refer to views of buffers and as a glTF addition have a gl target (array or element) property, so that clients can potentially create a single or minimal number of VBOs for each target ahead of rendering time.

Ah yes, we can't loose that.

Taking a closer look at this, I should be OK with it. I also considered combining buffer and bufferView (really just move path and type into bufferView), but then an implementation would need to be careful not to request the same file more than once. So the structure glTF imposes is useful here. Hopefully I think the same after I implement it.

[fabrobinet]

Ok, this has been around for a while, flagging as resolved, I plan to implement over the WE.

[fabrobinet]

moving as resolved.

[pjcozzi]

@fabrobinet will this be in dev-3?

[fabrobinet]

Yes for dev-3, it is a format change and I wished I could make it for dev-2.

I plan dev-3 release in about a week.

[fabrobinet]

ouch - got swamped at work - working on this one now.

[fabrobinet]

done - keeping for spec update.

[pjcozzi]

@fabrobinet schema is updated, let's close.