thibauts
commented
9 years ago Ping @hughsk @mattdesl
Following yesterday's discussion about file parser on #stackgl, i'd like to have input from contributors.
I started building a 3DS file parser (https://github.com/thibauts/node-parse-3ds and https://gist.github.com/thibauts/b18eaeea43ba66143c12) and wonder what would be a common scheme to build such parsers, regarding module organisation and interfaces.
As @mikolalysenko pointed out it's probably a good idea to build parsers that stay true to the data they parse, ie that provide a strict JSON representation of the data.
@mattdesl suggested having a 2 layers model and provide modules that take the raw JSON data and extract relevant data in a common format that will make things easier and interoperable.
Now what would the module interfaces look like ? Could we agree on a module naming sheme to make things discoverable and clear ?
As an aside I'm not a big fan of parsers that take a stream as an input as they put a hard dependency on browserify for client side usage and are not really streaming parser in the sense that you have to wait for the stream end before getting the parsed data back anyway.
Maybe we could have Buffer / ArrayBuffer => JSON tree for raw parsers and Buffer / ArrayBuffer => vertices, faces, normals, uvs, etc for common usage parsers.
In case we need to build real streaming parsers, adding "stream" in the module name could to the trick like in parse-ply parse-ply-stream.
Having a naming scheme that can include serializers would be nice too.
What do you think ?
We need more parsers for various 3D geometry formats. Eventually, it would also be nice to build some generic module that takes a simplicial complex and serializes it to various standard formats.