On Wed, Jul 25, 2012 at 12:16 AM, Chris Forbes <chr...@ijw.co.nz> 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.


Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Flightgear-devel mailing list

Reply via email to