Improving art pipeline through assimp2json

[trevex]

I just stumbled upon assimp2json that dumps Assimp's datastructure of a 3d asset to a JSON-file. Considering how complicated it was for me for a university project to get animations properly exported and how often questions related to the blender exporter pop up, I thought it would be worth suggesting a (assimp)json2json converter to ease up the export pipeline.

[mrdoob]

Sounds good to me! Anyone up for writing a loader?

[acgessler]

Hi, I'm one of the assimp developers and I'm also the guy who wrote assimp2json. I'd love to help out on this if people would find that useful. Assimp can handle virtually all import cases (except maybe FBX for which going through the FBX SDK is safer) so it would probably be a good addition to Three's toolchain.

Assimp outputs a whole scene (with hierarchy, transformations, animations etc). From what I've seen, the Three.js mesh format only supports meshes? Is there any official way of storing scenes or is that only possible at runtime?

If such a format exists, I could, instead of going json2json (or writing a runtime loader for assimp2json's format), simply write a dedicated assimp2whatever tool that does it directly.

I've been doing some experimenting with efficiently storing mesh data for use with WebGl lately (for my own 3D framework https://github.com/acgessler/medea.js), and I think moving away from pure JSON and using a mixed, streamable representation (JSON to put parts together, binary files to efficiently store 3D data chunks) could also be an option - is there any interest in pursuing that with Three.js and assimp as converter?

[mrdoob]

Assimp outputs a whole scene (with hierarchy, transformations, animations etc). From what I've seen, the Three.js mesh format only supports meshes? Is there any official way of storing scenes or is that only possible at runtime?

If such a format exists, I could, instead of going json2json (or writing a runtime loader for assimp2json's format), simply write a dedicated assimp2whatever tool that does it directly.

I've been working on such format (easiest way to see the output is to File/Export Scene in the editor), but I've yet to figure out animation, bones and so on... I think writing a runtime loader for assimp2json's format is the best bet right now.

I've been doing some experimenting with efficiently storing mesh data for use with WebGl lately (for my own 3D framework https://github.com/acgessler/medea.js), and I think moving away from pure JSON and using a mixed, streamable representation (JSON to put parts together, binary files to efficiently store 3D data chunks) could also be an option - is there any interest in pursuing that with Three.js and assimp as converter?

I think that's what also the way glTF is going.

[acgessler]

Ok, then I'll put together a runtime loader.

I didn't know about glTF - it seems very interesting and very related, I am just a bit worried that it will become as over-specified as Collada has become.

[acgessler]

Added PR for this.

[Digitoxin]

So we'll have a universal asset import system soon? Sounds awesome.

How many formats does this cover?

[acgessler]

The ones listed here:

https://github.com/assimp/assimp

Assimp2json is not quite "there" yet though - in a long term run, I'm thinking about adding some content processing system that also collects textures, sanitizes texture paths and file names, re-scales them to be square, generates LOD versions of them ... but this is a first step, doing only the raw whatever-to-json conversion.

Assimp itself was always built to fit the needs of game engines and game editors: importing 3D data, cleaning it up, generating utility data ... preprocessing models for use on the web is a topic we haven't been exposed to yet, so I guess there's lots of things we can improve on :-)

[antont]

should this be closed as http://threejs.org/examples/#webgl_loader_assimp2json is there?

the gltf-like binary optimized things are different but i suppose good to discuss separately exactly for that reason, or? can be continued here of course too, just figured to note in case this had just been forgotten open after the loader was made etc.

[mrdoob]

Ah yeah, I think it can be closed :)

[mrdoob]

Actually, now that I look at it. It could be nice to add some metadata to the json so we can figure out it's a assimp2json file at load time.

[antont]

yes metadata is good.

also, i've found file extensions useful. .. am currently calling my assimp2json file .. tada, myfile.assimp2json :)

also the gltf folks accepted my proposal to change the file extension from .json to .gltf (I had trouble separating three json and gltf json in our loader system otherwise, was easy like that), KhronosGroup/glTF#260

[mrdoob]

also the gltf folks accepted my proposal to change the file extension from .json to .gltf (I had trouble separating three json and gltf json in our loader system otherwise, was easy like that), KhronosGroup/glTF#260

nice! I also like that it's now in one file.

[acgessler]

Yes, I think it'll be good to have a dedicated extension for assimp2json also. .assimp2json is not bad after all :-)

I can update assimp2json itself as well as the three.js sample.

[repsac]

On a somewhat related note: @mrdoob is there an official extension being considered for three? For threeio I have been using .json as I had issues with the .js format (sorry but when I see *.js I expect that to be Javascript) that the original Blender exporter was putting out. Would something like .3js be more intuitive?

[mrdoob]

Yes, I think it'll be good to have a dedicated extension for assimp2json also. .assimp2json is not bad after all :-)

I think having metadata in the json is more important though (reasoning below)...

On a somewhat related note: @mrdoob is there an official extension being considered for three? For threeio I have been using .json as I had issues with the .js format (sorry but when I see *.js I expect that to be Javascript) that the original Blender exporter was putting out. Would something like .3js be more intuitive?

The reason behind using .js was because most servers gzip that extension by default. Not as many gzip .json. Eventually I went for .json for clarity. So a extension like .assimp2json won't get gzipped by default.

I've been using this kind of extensions for another project: test.geometry.json, test.material.json, test.object.json, test.scene.json, ...

[repsac]

OK, thanks for the clarity on that one. Everyone I turned on to three would always ask me that question and I never had an answer but now it makes sense.

[antont]

@acgessler :) i'm not sure yet, .assimp2json is long, compared to something like .a2j

mrdoob's points are good too, was thinking of those back then also when discussed with the gltf folks. however the parallel to collada-xml being .dae (and not .xml) seemed to kind of make it clear but dunno.

.scene.json and such sure are kind of tempting too. but perhaps not assimp2json.json :p

[mrdoob]

I would suggest test.assimp.json ;)

[antont]

afaik the additional complexity here is that assimp has some other json format (assimp json or so), and this format is just assimp2json project's own json format for assimp's internal structure - right?

[mrdoob]

Oh! Why not just load that other assimp json format instead?

[acgessler]

No worries - there is only one assimp JSON format as far as I know.

I wrote assimp2json before we added an export API to assimp itself. It is on the mid-term plan to make the JSON exporter a part of the core library, though.

assimp.json makes sense too - just worried about importers that branch based on the last extension. Maybe just assimpjson to avoid that?

[mrdoob]

assimp.json makes sense too - just worried about importers that branch based on the last extension. Maybe just assimpjson to avoid that?

That's why I was suggesting the metadata bit. Something like this...?

{
    "metadata": {
        "format": "assimp"
    },

[antont]

oh ok good, i was misinformed earlier about there being another assimp json besides this.

as said i'm all for the metadata but suspect that unique file extensions are still useful too. at least our current loading code (in WebTundra) depends on the extensions to pass to different loaders. don't know if we could sensibly refactor that to peek in the file instead. seems nicer to be able to choose the loader before opening the file, no? is afaik useful with images similarily -- three.js separates e.g. .png and .dds handling based on file extensions and those seem more useful than mypicture.png.binary & mypicture.dds.binary would be. with extensions like xyz.scene.json i'm afraid it can be ambiguous if someone makes a file called scene.json (which is perhaps just a single mesh geom called 'scene', for a theatre app :) etc.

btw the .assimp2json files i have on-line now seem to come as zip-compressed from the server but i don't know if that's due to special confs @erno has made on the server (checked from the headers of http://playsign.tklapp.com:8000/oulu3dlive/models/b1_1/b1_1.assimp2json)

so i don't know what a good extension to assimp2json would be (if not just .assimp? but perhaps assimp has / wants some binary format too and not just json?) but just hope that it would be something else than plain .json .. or at least that's how our current code would need it.

[acgessler]

As an update, I've updated assimp2json to use assimp.json by default, and to write a format metadata header similar to the one proposed by mrdoob.

I'll follow-up with a PR to update the threejs sample.

[mrdoob]

Nice!

[antont]

ok, i figure will rename my files when touch those the next time :) .. and that probably is fine for supporting in our asset loader which depends on the extensions to pass the data to handlers. so thanks for providing a unique one!