cache PLY

[ngokevin]

Makes it so it doesn't request duplicate models twice. Was using a 6MB three times, this makes it load much faster.

Makes me think we should have a single loader system and component that handles all of this, and we create a registerLoader API, and then we have a repo of wrapping all three.js loaders.

[donmccurdy]

Thanks! Are you thinking ply-model might be part of a recommended workflow from MagicaVoxel to A-Frame? I'm open to splitting it into a separate repo if that's better. But, I'm still sort of hoping we'll get a way to export or convert baked models into something more compact.

[ngokevin]

Yeah, for now. Since it's the easiest and best visual result. It's a bit big, but for the ease and result, and given today's internet speeds and the fact we shouldn't have to worry about mobile, I'm not troubled.

For my all-out Pokemon Stadium, the seating was 6MB, the battle stage was 3.6MB, and my Pokemon was 150KB.

The A-Frame scene/landscape was about 6MB.

[ngokevin]

Yeah, maybe we could temporarily split it out so it's more discoverable and consumable...but I'm thinking of perhaps a place we could just maintain every loader, whether you can own that or under the aframevr org.

[donmccurdy]

Seems a bit early in the game to dismiss mobile. 😉

But anyway, carrying this over into aframevr/aframe#1662.

[ngokevin]

Not dismissing mobile in the future, but the mobile browsers as they are today are not how VR is going to be, and it's not really worth trying to fit into those constraints. When they catch up, and on-the-go VR is more accessible, then yeah, getting assets down is a bit more important. Although service workers and progressive apps will be prevalent by then.