Consider adding some kind of index file

[emackey]

I'm thinking about using this repo as a git submodule in other projects that could use sample models, specifically glTF-WebGL-PBR, and possibly @cx20's gltf-test if he's willing.

To make the models more discoverable, in an automated fashion, it might be nice to have a JSON file included with this repo that lists each of the available samples, along with its name, description, screenshot URL, and available variants (embedded, binary, pbrSpecGloss, etc).

I'm imagining a NodeJS script or similar that would scan the 1.0 and 2.0 folders and compile a list of this information, and save it into some generic JSON structure. The gltf-test project already has the beginnings of such a structure hard-coded into it, but I'm picturing one that's a little more fleshed out. The file would likely be called model-index.json in the root folder and could be rebuilt from the command line whenever the sample models change. Such a file could be used or ignored at will by any software looking to load sample models.

Thoughts?

[pjcozzi]

As long as we keep the barrier-to-entry low for submitting sample models, e.g., generate the .md or an HTML file from this and the contributor only needs to provide the JSON, I think it could work.

Perhaps one .json per file and then a bot running in CI to generate the master .json.

[bwasty]

I've written a Python script to generate two index files (for 1.0 and 2.0) from the existing data: master...bwasty:generate_index

The reason actually is to get rid of a git submodule, because it doesn't really work that well. The idea is to download individual models via raw.githubusercontent.com.

Not sure about the .json per file and CI ideas - perhaps this could be enough as a first step?

[emackey]

Thanks @bwasty, I'll take a closer look soon. One thought off the top of my head, the json files look nice and tidy now with some baked-in assumptions about the folder structure:

 {
   "name": "BarramundiFish", 
   "screenshot": "screenshot/screenshot.png", 
   "variants": [
     "glTF", 
     "glTF-Binary", 
     "glTF-Embedded"
   ]
 }, 

But this requires the user to be aware of some strange rules, for example the rule that the "glTF-Binary" variant is typically .glb instead of .gltf. Do you think it would be worth expanding this out?

 {
   "name": "BarramundiFish", 
   "screenshot": "screenshot/screenshot.png", 
   "variants": [
     "glTF/BarramundiFish.gltf", 
     "glTF-Binary/BarramundiFish.glb", 
     "glTF-Embedded/BarramundiFish.gltf"
   ]
 }, 

Or maybe even further:

 {
   "name": "BarramundiFish", 
   "screenshot": "screenshot/screenshot.png", 
   "variants": {
     "glTF" : "BarramundiFish.gltf", 
     "glTF-Binary" : "BarramundiFish.glb", 
     "glTF-Embedded" : "BarramundiFish.gltf"
   }
 }, 

Also, please go ahead and open a pull request on your branch. Thanks!

[alteous]

But this requires the user to be aware of some strange rules, for example the rule that the "glTF-Binary" variant is typically .glb instead of .gltf. Do you think it would be worth expanding this out?

@emackey Since all binary glTF ends in .glb it's not a great concern, unless the folder structure is subject to change.

[bwasty]

@alteous I already changed the generator to use the second option. I think it makes sense since a client just has to concatenate all the strings to get a valid path.

[emackey]

Fixed in #112.