Hi,

first, yes, the texture unit id must be passed to the shader as a sampler
uniform.  You could use app code to set the sampler, however, the .osg
fileformat does support the recording of uniform values, so the corresponding
sampler uniform setup can be captured in the .osg file without application code.

For example, the glsl_dataflag.osg demo (included in the win32 binary installer
or from http://mew.cx/drawtext/drawtext.html) demonstrates loading a texture to
unit 0 and passing that unit id to the GlyphTexSampler uniform.  That demo loads
directly into osgviewer without additional app code.

cheers
-- mew



Ed wrote:
> As I began to reformulate my question, I think I found the answer.
> 
> If I were to run
> 
> osgsimple skydome.osg
> 
> I would see a skydome textured with skymap.jpg.
> 
> In osgsimple.cpp, there is no explicity loading of the texture and
> mapping it to the sphere etc.  Right?  I assume this is done in the
> model loader code.  In looking in skydome.osg, I see that skymap.jpg is
> specified as a texture to be used and that it appears to be assigned to
> texture unit 0.
> My question was basically this; If I have a bunch of osg files, each of
> which have these embedded textures, then how do I know which texture
> unit they reside in when I need to do a texture fetch in my shader.
> 
> It appears that the answer is that I will have to have information from
> the osg file to know that.... In other words, I know that in the osg
> file for a given model, Texture A is in texunit 0 and Texture B is in
> texture unit 1 for example.  Then in my app code I will need to use a
> uniform to specify this.  Is this correct?
> 
> 
> Ed
> 
> Mike Weiblen wrote:
> 
>> Hi Ed,
>>
>> Not sure I'm following your question.
>>
>> The app supplies the id of the texture unit and the tex coords as
>> uniforms to
>> the shader.   The shader code is responsible for using the sampler and
>> texcoord
>> in a GLSL texture*() call, which retrieves the "texture data", then
>> using that
>> texture data to achieve the desired result.
>>
>> For example, in the OpenSceneGraph-Data distribution are a couple
>> shaders that
>> use textures in different ways; the marble.frag shader uses a 3D noise
>> texture
>> and a 1D sine lookup-table texture to generate a banded marble-like
>> coloring.  A
>> texture need not contain color data; the shader is free to determine
>> how to use
>> any texture result to compute the gl_FragColor.
>>
>> hth
>> -- mew
>>
>>
>>
>> Ed wrote:
>>  
>>
>>> Ok... Here is another strange, and most likely stupid, question:
>>>
>>> In the GLSL texture mapping examples I have seen, the texture is created
>>> via the usual glGenTex*/glTex* functions.  Then the object is rendered,
>>> tex coords are specified, and  the texunit is specified via a gluniform*
>>> call which informs the shader which texture unit to use in the
>>> texRECT/tex2D call.
>>>
>>> Let's say I have a GLSL fragment shader.  I enable the shader only when
>>> running a particular object.  How can i access the texture data from
>>> within the shader?  I am storing some non-visual data in the texture,
>>> which is mapped to my objects, and using that data for various
>>> calculations.  If I have an OSG app, which uses a frag shader while
>>> rendering a particular object, how do i retrieve the texture unit
>>> information to perform the texRECT/tex2D?

_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Reply via email to