On Fri, Nov 2, 2012 at 10:06 PM, Fabrice Robinet <fabricerobinet@me.com> wrote:

Right. And I think of compressed textures as well…

On Nov 2, 2012, at 2:05 PM, Florian Bösch <pyalot@gmail.com> wrote:

Sure. But you could pack images into the blob as well :)

On Fri, Nov 2, 2012 at 10:03 PM, Fabrice Robinet <fabricerobinet@me.com> wrote:

Hi Florian,

In the current proposal, only vertices and indices are in a blob, images continue to stands as external assets.

Fabrice.

On Nov 2, 2012, at 2:02 PM, Florian Bösch <pyalot@gmail.com> wrote:

There's an issue with packing images in blobs. The issue is that in order to decode the image you have to:

1) get an array buffer view
2) get a blob
3) make a blob URL from that

4) pass that to an image.src
5) wait for the image.onload
6) in the image.onload call the texImage2D on the image
7) delete the blob url

There are two things that would *really* help with that kind of blob monkeying if they where implemented.

- string <-> arraybuffer
- decodeImageBytes(arraybuffer, callback) where callback is called with the raw image bytes ready to pass to texImage2D

On Fri, Nov 2, 2012 at 9:57 PM, Fabrice Robinet <fabricerobinet@me.com> wrote:

Well, that's indeed an interesting digression, but for those catching the thread now: the format described relies on a separate binary blob that can be loaded as a single or multiple ranged xhr, or web socket...

Anyhow, I'll take that input and consider the possibility of merging the two but dealing with a raw binary (compressed or not…) without any conversion to a string is something I believe (speculatively?:) most people will prefer.

Fabrice.

On Nov 2, 2012, at 1:45 PM, Florian Bösch <pyalot@gmail.com> wrote:

As a sidenote to browser vendors, string <-> arraybuffer is kind of really needed. Oh, and while you're at it, please also add a JS hash class, a set class and a decodeImageToArrayBuffer function.

On Fri, Nov 2, 2012 at 9:41 PM, Florian Bösch <pyalot@gmail.com> wrote:
That too.

On Fri, Nov 2, 2012 at 9:40 PM, Brandon Jones <bajones@google.com> wrote:

Eek! Nevermind! The performance on that is apparently horrible...

http://jsperf.com/decoding-ascii-string-from-binary-blob

On Fri, Nov 2, 2012 at 1:34 PM, Brandon Jones <bajones@google.com> wrote:

Florian: An interesting shortcut to your for loop could be

var charArray = new Uint8Array([65, 66, 67, 68, 69, 70, 71, 72]);

var result = String.fromCharCode.apply(String, charArray);

Works on Chrome, Firefox, and Safari that I've tested, maybe more. Not sure what the performance difference is but the code is a bit nicer.

On Fri, Nov 2, 2012 at 12:58 PM, Florian Bösch <pyalot@gmail.com> wrote:
I'm doing it like this

length = new Uint32Array(data, 4, 1)[0]
metadata = new Uint8Array(data, 8, length)
result = ''
for i in [0...length]
result += String.fromCharCode(metadata[i])

result = JSON.parse(result)

On Fri, Nov 2, 2012 at 8:56 PM, Rico P. <mailtorico@gmail.com> wrote:

Interesting... How can I convert a binary blob back into a string?

- Rico

2012/11/2 Florian Bösch <pyalot@gmail.com>:

> Note that you can pack both the JSON and the binary blobs into one array
> buffer. A format I'm using is built like this: <uint: length of json string>
> <json> <buffers>
>
> Where the json part contains offsets/lengths of the buffers relative to the
> start of the binary part.
>
>
> On Fri, Nov 2, 2012 at 7:33 PM, Fabrice Robinet <fabricerobinet@me.com>
> wrote:
>>
>> Dear WebGL group,
>>
>> I'd like to share with you a work in progress to define a JSON format for
>> WebGL.
>> This initiative was initially started from the COLLADA working group.
>> It aims to be a response to developers expectations to get 3D assets
>> seamlessly on the web.
>> This is an entirely new format that stands at the end of the asset
>> pipeline, it can be generated from COLLADA, but it is not tied to it.
>>
>> This format reuses as much as possible existing concepts (like using typed
>> arrays for binary blobs ) and it is _javascript_ friendly with JSON. It also
>> takes advantage of a few concepts inherited from COLLADA that proved to be
>> successful.
>>
>> There are already many JSON formats out there, so why another one ?
>> One implicit goal of this project is to gather all the great ideas from
>> the community and focus on the particular purpose of getting a JSON format
>> usable for many developers. But obviously, a single format cannot be
>> convenient for everyone, for those (many) who want a delivery format ready
>> for rendering, this effort is the way to go, for those who want to
>> edit/remodel 3d assets and keep most informations then COLLADA would be
>> better suited.
>>
>> General presentation of the top level project:
>> https://github.com/fabrobinet/collada2json/
>>
>> More insights about the format (work in progress):
>> https://github.com/fabrobinet/collada2json/wiki/WebGLTF
>>
>> Last but not least, I'll be presenting the format at this meet-up:
>> https://github.com/fabrobinet/collada2json/
>> I'll show there some demos that will be online shortly.
>>
>> All feedback is very welcome,
>>
>> Thank you,
>> Fabrice.
>
>

Re: [Public WebGL] WebGLTF: Proposal for a WebGL transmission format