Cleanup

[lilleyse]

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
  • Uniform function templates #99
  • Concept code for dependency management and custom pipelines #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, Review npm dependencies #178
• Use JSDoc everywhere
• Progress events: Progress events #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]

Added a list of functions that are considered "stages" and should be converted to use promises in #99.

[JoshuaStorm]

We use mkdirp in a handful of files, which the Node guide encourages be replaced with fs-extra's ensureDir and ensureFile. Should this be added to the cleanup?

[lasalvavida]

We use mkdirp in a handful of files, which the Node guide encourages be replaced with fs-extra's ensureDir and ensureFile. Should this be added to the cleanup?

Yes

[JoshuaStorm]

Oh, I guess that is included in the

Use libraries recommended in the node guide

my bad

[lasalvavida]

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.

@lilleyse What do you think about including the glTF sampleModels as a git submodule?

[lilleyse]

I'm worried that may bloat the size of this repo.

[lasalvavida]

If it's linked via submodule, don't the files only get pulled if you git submodule --init?

[pjcozzi]

I would if we could publish the sample models to npm. Is that a legit npm use case since it is not code? We might have to hold on this for a bit so Khronos can organize the models.

[JoshuaStorm]

• Consider changing the default output directory name for the createDirectory flag. Currently it just defaults to creating a new directory named output within the base of the output path

[lasalvavida]

I would if we could publish the sample models to npm. Is that a legit npm use case since it is not code?

Looks like probably not.

From https://www.npmjs.com/policies/conduct#acceptable-package-content:

Packages published to the Service must be created using the npm command-line client, or a functionally equivalent implementation. For example, a "package" must not be a PNG or JPEG image, movie file, or text document. Using the Service as a personal general-purpose database is also not allowed for this reason. Packages should be npm packages, and nothing else.

While 3D model files aren't explicitly prohibited here, I think the gist is that npm isn't for data.

[pjcozzi]

While 3D model files aren't explicitly prohibited here, I think the gist is that npm isn't for data.

Yes, agreed, but I wonder if there is an exception for data used for unit tests. Can you look into it? Maybe email them or ask on a forum?

[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

[pjcozzi]

@lasalvavida did you ever get a response from npm?

[lasalvavida]

No response from npm. A git submodule for the new gltf-sample-models repo is probably the way to go on this one.

[pjcozzi]

I wouldn't jump on that yet since we want some of those models, but not all of them, and we'll also want some of our own.

[emackey]

Just my $0.02. The git submodule strategy mentioned above sounds fine. Clients who want to run unit tests will need disk space for a copy of the sample model repo, but the size of the sample model repo doesn't "bloat" the size of this repo itself. This repo just gets a hash and a reference to the submodule. This means:

• You always have the option to delete it in the future, leaving behind only a history of 1-line hashes.
• Any clients who want to clone and run the pipeline without getting the sample models can do so simply by not running the git submodule commands when they clone/fetch/pull.

[ggetz]

@lilleyse OK to close? Added cleanup label to outstanding issues. Maybe open one for tree traversal?

[lilleyse]

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