Compressing integer accessors

[lasalvavida]

For #120

• Add utility for accessor type (this should exclude index accessors and doesn't currently) - just having bufferView and buffer accessible on AccessorReader is good enough. You can check the bufferView target from there.
• Make functions that iterate over accessors use the added AccessorReader - Some of removedUnusedVertices was left alone because it is faster to copy data in chunks
• Tests

Results look good except for cases where the first checkmark is an issue.

[coveralls]

Coverage increased (+0.2%) to 93.894% when pulling 650e38f on compressIntegerAccessors into 5a7bdda on master.

[lasalvavida]

Results:

	Box.gltf	CesiumMan.gltf	BrainStem.gltf
Original	8.10 KB	1.55 MB	15.0 MB
w/o compressIntegerAccessors	6.54 KB	716 KB	4.33 MB
w/ compressIntegerAccessors	6.25 KB	662 KB	3.27 MB

All models render correctly and this compression is completely lossless!
Just needs tests

[lilleyse]

Nice results! I'll check the code out when everything is ready.

[lasalvavida]

@lilleyse This should be ready for a look. Not super high priority, but it would be nice to get into master since it comes with a decent amount of cleanup as well.

[lilleyse]

Using -q is creating broken models on this branch.

[pjcozzi]

For Box.gltf above (#121 (comment)), why is it smaller with integer compression? What integer attributes did it have?

[lasalvavida]

For Box.gltf above (#121 (comment)), why is it smaller with integer compression? What integer attributes did it have?

Its positions and normals are all made up of 0, 1 or -1, which can be stored as a byte instead of a float.

edit: actually just the normals

[lasalvavida]

Good catch @lilleyse! This was an issue with AccessorReader that should be fixed now

[pjcozzi]

For Box.gltf above (#121 (comment)), why is it smaller with integer compression? What integer attributes did it have?

It's positions and normals are all made up of 0, 1 or -1, which can be stored as a byte instead of a float.

Ah, OK. Then it is rendered with bytes, right?

This is fine for now, but I would not be surprised if this is slower to render on many GPUs or if the data is padded / converted when uploaded to the WebGL buffer (e.g., we said bytes, but the driver converts to floats to get the fast path).

No need to do performance testing now since this is an edge case for most models.

[lasalvavida]

Yes, it is rendered with bytes. Definitely an edge case though; this is mostly for compressing JOINT that get stored as floats. I just wanted to show that rendering still worked for other semantics.

[pjcozzi]

All good with me, what's left before we can merge this? #121 (comment)?

[lasalvavida]

I don't have anything left on my list; should be good to merge.

[pjcozzi]

@lilleyse when you are ready...

[lilleyse]

I confirmed that quantization works normally now.