cubemap support

[Aeva]

create a mechanism for defining and uploading cubemaps

[Aeva]

It looks to be the case that you get one texture object per a cube map. To render to a particular side of the cubemap, you just provide the texture id for the cube map and then provide the appropriate texture target instead of texture2d. http://www.gamedev.net/topic/610644-rendering-to-cubemap-for-environment-mapping/

I think from an implementation standpoint, the cubemaps can be stored in the same place as the 2d textures, and that all texture objects should also store their type, so that they can be differentiated between.

There should also be a omnidirectional camera mode that can be used for render-to-textures. For this, the projection matrix and the view matrix drivers are set to throw an error if they are ever called, and then the actual projection matrix and the six view matrices are just hard coded the projection matrix is fixed, relevant controls are dummied out, and the view matrix driver returns a dictionary of matricies or something? This article outlines what the appropriate up vectors are for the lookat function.

[Aeva]

Commit e119c910cc3f047aa91697bc25de99f428620374 from the fast_graph development branch (and subsequent related bug fixes) add support for texture arrays, finally. In looking through this and reading up again on the cubemap api, I feel as though it shouldn't be super hard to add in cubemap functionality soon.

I think there should be a CubeMap constructor, that takes the appropriate six images, and can be passed along in places where you might use a sampler URI. Type enforcement would be easy to do with this, though maybe only needs to be present in debug builds. The constructor might be used to bypass the need to call get_texture.

For starts, it should just take six images, and upload the appropriate cube map. There should also probably be an "error cube map" which might just be a simple gradient sky looking thing? It might be easiest to show the error cube map when waiting for the images to stream.

Later (perhaps in another issue), another constructor might prototype from the CubeMap constructor, and this could be how things like probes/omnidirectional cameras might be implemented. Pointlights that cast shadows will need this.