Three.js and/or Babylon.js loaders?

[sunnystormy]

Hello!

I'm interested in spearheading the addition of some modern JSON-based formats into the engine?

I know Irrlicht has a built-in XML parser... but is there anything for JSON?

Please let me know!

[CuteAlien]

Which 3d formats are using JSON? Actually I also only know collada and .irr using xml - all others tend to use their own formats.

[sunnystormy]

Three.js and Babylon.js have JSON exporters that can be installed in Blender. Each has a specification of the kinds of mesh/camera/scene details that are encapsulated by the resulting JSON file.

Three.js exporter: https://github.com/mrdoob/three.js/tree ... rs/blender

Babylon.js exporter: https://github.com/BabylonJS/Babylon.js ... rs/Blender

[CuteAlien]

Ah ok. And no - we don't have anything for JSON so far.

[sunnystormy]

Does that mean I'd have to link a JSON-parsing library to Irrlicht in order to connect those formats to AnimatedMeshSceneNode? Or build a JSON-parsing mechanism from scratch in order to keep the Irrlicht codebase clean?

I just want to write code that will fit comfortably within Irrlicht's source, any recommendations/advice would be greatly appreciated!

[CuteAlien]

We tend to avoid external library dependencies when they can be avoided.
Thought when it comes to readers I think my favorite way to go foward would be in that direction (work with assimp): http://irrlicht.sourceforge.net/forum/v ... =9&t=50751

[sunnystormy]

Hey, CuteAlien!

Not a bad idea, but checking out the GitHub repo showed that it doesn't support animated meshes yet... >_>

I've found a JSON-parsing library that can actually create amalgamated source which will allow it to be included with Irrlicht as one header and one source file:

https://github.com/open-source-parsers/jsoncpp

That will expedite the inclusion of JSON-based formats into the engine.

[CuteAlien]

Thanks for the info. But if we add a lib it's not good to do it that way. Especiallly not when it comes with another license (even if it's very similar to zlib - it's still having differences). Basically libs should go in an own subdirectly and it has to be possible to disable them with a define and switch to system libraries (distributions want that).

But you can always add loaders without modifying Irrlicht itself. The code in irrExt (https://sourceforge.net/projects/irrext/) does that generally. And it has the advantage that we don't have to maintain it in core. Right now I would prefer to get rid of a few loaders because it's really hard to unify them as it's all code written by different people which are no longer available and for some formats I don't even have any test-models. It was a nice idea to have the engine support everything out of the box.. but it's not so nice anymore if you have to maintain it a decade later and want to improve anything. I learned that when trying to unify texture-loading - I managed to do it for 13 loader and 2 more didn't need it - for the other 6 loaders the new features are still not available because rewriting those is more tricky and I don't get to it. Over 20 loaders in the engine mean - every little change where you spend maybe an hour with coding&testing per loader - you need 2 1/2 full days to get it done already.

So that's why assimp looks so promising to me and I'm not that keen on adding more loaders directly to Irrlicht.
I might make an exception if someone produces a good fbx loader - simply because that format is so popular in games that it would be worth it. But for custom formats used by just one more engine I'd prefer if it goes into irrExt (I can ask the maintainers there to add you there if you have code to contribute).

[sunnystormy]

*mind blown*

I had no idea you could extend Irrlicht like that!?

I am in complete agreement with you, then. I'll have to add this as an extension, and would love to contribute if you could help facilitate it.