render texture

[jfcameron]

think about how best to create "render texture" concept. in gl terms, its a nondefault fbo with textures attached to at least one of the buffers (e.g: depth, or color). necessary to produce effects like shadow casting. I think its worth trying very hard to keep it within the texture object itself, rather than having a specialized render_texture type as ive seen and done in the past

[jfcameron]

maybe instead of texture owning an fbo, fbos could be owned by the camera type. possible added methods to the camera interface: camera::attach_color_buffer_texture(pTexture) camera::attach_depth_buffer_texture(pTexture) ...detach_color_buffer_texture()....

manage FBOs statically, local to the camera.cpp file. when attach is called, grab an fbo if one is free else try to make a new one, then use that fbo in draw calls. what if an fbo cannot be created because it exceeds a limit? throw? when detach is called, if no buffers are attached then release the fbo to the pool, and when draw is called, use the default fbo.

[jfcameron]

implemented camera attach, detach above. allowing arbitray textures while technically possible is really not user friendly. textures attached to fbo buffers have strict requirements 0 mipmapping, for example, plus in other tickets I have decided to expand the mutable texture interface to allow replacing sections of data or all the data entirely. I dont want users to be able to accidentally make a working attached texture become invalid in the gl because they called some methods provided by the library that they were not supposed to while its attached to a buffer. I think the "render_texture" concept should still be avoided. its an akward abstraction because it in fact has multiple textures (the color buffer attached texture, optionally depth, stencil, ...). It also means that cameras have to determine if one is attached and then behave differently at ::activate() time, which i think is unnecessary: what really is the value of being able to attach and detach these things to a camera? A typical case of a texture attached camera is to keep it attached for its entire lifetime and use the output as an input for e.g: shadow casting, or some other shader effect. Instead I am going to creating a camera subclass called "texture_camera", which manages its fbo, buffers, attached textures. attached textures are determined at construction time and those textures are accessible as CONST pointers. This will let me avoid creating a silly texture specialization while expanding its mutable interface AND preventing the user from invalidating buffer attached textures.

[jfcameron]

implementation I went with was to split camera into camera, screen_camera, texture_camera. supports depth texture if the extension is available.

[jfcameron]

e8f8f916649c65f322be678c4e6407cb6ec3fc1b