Some thoughts about BONES

-rotation operations to resolve all of the bones in a rig are only dependent on previous bones within that rig.
-this means the longest series of dependent transforms is, at worst case,
transform-call-cost * bones-in-biggest-rig-graph
-if you wanted a really stupid number of animated entities in a scene, you could run the operations to transform skeleton 1 through 23,467 concurrently.
-the transforms we want to apply on our BONES sure sound like they might be modeled by lin alg.
-i google “javascript cuda” -> “about 16,200,000 results (0.44 seconds) "

Looking at gpu.js first and neglecting to cross-compare any other libraries,
it sure sounds like we can just serve up a bunch of matrix multiplications to someone else’s GPU compute API.
This seems worth exploring! It would be ‘nice’ to have ridiculous density of rigged objects in a scene if a capable GPU is detected.

(EXTREME GIRAFFICAL MODE ENGAGED)

If this library is too cumbersome or we run into major problems integrating it, we can just drop it lol.

In conclusion:

downsides:
-One more stinky library to add to the library stack
-More variation in behaviour between platforms
-(This means a much broader scope of possible errors)
upsides:
+SUPER COOL
+Probably a qualitative difference between having 5 dynamic objects in a scene vs 500.
+haha cuda in the browser
+increases project buzzword density