On Thu, Jul 5, 2012 at 7:16 PM, Gregg Tavares (社用) <firstname.lastname@example.org> wrote:I don't expect most libraries will handle it automatically. Most will require the user to specify upfront what they want.but yes, if they want to support dynamic textures I do expect them to handle it. Only they know when is the appropriate time to compile and when to fail. On top of that they have to call dynamicTextureAcquireFrame to use these textures so it's not like they can magically do nothing and have it just work.Those libraries that do want to type handle it automatically are already most likely handling it dynamically. They generate shaders based on number of lights and other material parameters. The can just as easily add dynamic textures as an option to their generator.The only remotely reasonable sane way that this extension can be "handled" by frameworks is creating ghost textures, creating an FBO, then doing a copy shader, that just uses this one sampler, copies it to an RGB texture and then drop in that RGB texture in place of this broken piece of mess. So that's fine, we can do that, no problem, I just thought, you know, maybe don't make people jump trough complicated mad hoops just to make it possible to write a sane library/framework/toolkit.