4 ms·

But a .json file surely will be 2x or even 3x as big as the .obj file, because of all the extra fluff the format adds. What is wrong with parsing an obj file, a

But a .json file surely will be 2x or even 3x as big as the .obj file, because of all the extra fluff the format adds. What is wrong with parsing an obj file, and building up your vertex and index buffer straight away? Parsing a .json file would also be like twice as slow. I'm not versed in WebGL but if you have to have .json in the middle of everything that seems like a really dumb decision by the designers, especially for the web.

santaclaus 10y ago
This is especially true for .obj -- that format is dead easy to parse.
zeta0134 10y ago
Ordinarily I would agree with you except for what .json is: a JavaScript Object. Or, more correctly, its serialized-to-text form. Parsing it is a matter of invoking an extremely common function built into every JavaScript implementation in every browser, and likely optimized to death. This is one of those weird cases where, despite obj being a simpler format on paper, it would likely be slower to parse due to having to hand-roll the parser in JavaScript and not use the browser's native built-in parser instead.
- Wilya 10y ago
  Yeah, but you still have to parse the .obj. What the article is doing is .obj -> .json -> WebGL arrays. There isn't really any reason to put the .json intermediary in the middle. Especially since you will only treat it as a blackbox to pass around. JSON is nice as a hand-editable text format. It isn't designed to be fast to parse, or to produce small files.
- microcolonel 10y ago
  Given that .OBJ is largely a text file which contains a vertex list and an element list. It seems like it would make more sense to store it as a binary in the format which is sent to the GL driver, especially given that WebGL requires typed array buffers anyhow. Just need the offset, extent, type, and number of axes of each buffer.
  - hccampos 10y ago
    Enter gltf https://github.com/KhronosGroup/glTF https://github.com/KhronosGroup/glTF
    - microcolonel 10y ago
      Sadly glTF is JSON, and not typed array buffers (as far as I can tell). I was going to mention it, but it seems like in terms of performance almost anything can be as good or better than glTF.

santaclaus 10y ago

This is especially true for .obj -- that format is dead easy to parse.

zeta0134 10y ago

Ordinarily I would agree with you except for what .json is: a JavaScript Object. Or, more correctly, its serialized-to-text form. Parsing it is a matter of invoking an extremely common function built into every JavaScript implementation in every browser, and likely optimized to death. This is one of those weird cases where, despite obj being a simpler format on paper, it would likely be slower to parse due to having to hand-roll the parser in JavaScript and not use the browser's native built-in parser instead.

Wilya 10y ago
Yeah, but you still have to parse the .obj. What the article is doing is .obj -> .json -> WebGL arrays. There isn't really any reason to put the .json intermediary in the middle. Especially since you will only treat it as a blackbox to pass around. JSON is nice as a hand-editable text format. It isn't designed to be fast to parse, or to produce small files.
microcolonel 10y ago
Given that .OBJ is largely a text file which contains a vertex list and an element list. It seems like it would make more sense to store it as a binary in the format which is sent to the GL driver, especially given that WebGL requires typed array buffers anyhow. Just need the offset, extent, type, and number of axes of each buffer.
- hccampos 10y ago
  Enter gltf https://github.com/KhronosGroup/glTF https://github.com/KhronosGroup/glTF
  - microcolonel 10y ago
    Sadly glTF is JSON, and not typed array buffers (as far as I can tell). I was going to mention it, but it seems like in terms of performance almost anything can be as good or better than glTF.