|
From: Tim M. <tim...@gm...> - 2012-07-25 05:38:06
|
On Wed, Jul 25, 2012 at 12:16 AM, Chris Forbes <ch...@ij...> wrote: >> Somewhat inversely, I'm also wondering if a simple texture1D() lookup might not be faster than evaluating the light function e / pow((1.0 + a * exp(-b * (x-c)) ),(1.0/d)) three times to get an (rgb)-triplet. > > That depends a lot on the GPU, and how coherent the texture > coordinates are across a triangle. You also need enough ALU work > elsewhere in the shader to mask the latency of the texture lookup. > > For the existing noise texture generation, take a look at > make3DNoiseImage in scene/material/TextureBuilder.cxx in the simgear > tree. This particular texture is filled CPU-side, but if you're more > comfortable expressing things in a shader, you/someone could rig up > some FBO wiring to quickly render a shader-defined function into a > texture. Actually, the code that creates the texture is in scene/util/StateAttributeFactory.cxx, but you would have to do something similar to the noise texture code in TextureBuilder to access your texture from a texture. It would be nice if the Effects framework had a way to load arbitrary textures and make them available to effects. These days you aren't limited to 8 bit texture components. There is a rich set of data formats for textures: 32 bit floats, 16 bit floats, exotic combinations of different length floats per RGB component... I don't know if there is a better way to create your texture offline than write C++ code in simgear. OSG will read a TIFF file with 32bits per component as a floating point texture... assuming you can create such a thing. Tim |