Cleanup

Here is a rough list of tasks for bringing this repo up to production. Feel free to edit or add new items to the list:

• We should have a common set of models that we use for testing new features, especially models that have created problems in the past. However I’m not sure if they should be hosted in this repo.
• Refactor gltf-pipeline as a series of stages with dependencies
  • https://github.com/AnalyticalGraphicsInc/gltf-pipeline/issues/99
  • https://github.com/AnalyticalGraphicsInc/gltf-pipeline/pull/75
  • Use promises instead of callbacks
• General cleanup, api standardizing, file renaming, folder organization
  • Many functions expect an options object. Instead of sending in {} in a lot of places, just do it the Cesium way and create the options object if it’s not defined with options = defaultValue(options, defaultValue.EMPTY_OBJECT);
• Use recommended libraries, #178
• Use JSDoc everywhere
• Progress events: https://github.com/AnalyticalGraphicsInc/gltf-pipeline/issues/92
• Something like jQuery for glTF to eliminate redundant glTF data structure traversal
• Note: If there are any changes to the api we will need to update OBJ2GLTF and the website model converter

[lasalvavida]

To whom it may concern,

I had a quick question about npm’s policy on data for unit tests. Over at https://github.com/AnalyticalGraphicsInc/gltf-pipeline, we are looking to add unit tests for a set of sample models. We were wondering if it would be within the terms of use to have an npm module for providing those test models. This would also be useful for tests for other glTF utilities and renderers.

I understand that npm generally doesn’t allow this type of usage as in “Service as a personal general-purpose database is also not allowed for this reason”, but wasn’t sure if this still applied when it was being used as test data for other node modules.

Thank you, Rob

[lilleyse]

Oh yes, this is pretty old now. ForEach pretty much fixed the traversal item.