[osg-users] Threading mode causes texture mode trouble? ( 'loosing' textures? = How to create a proper .osg file with multi-texturing?)

Raymond de Vries reedev at xs4all.nl
Sat Oct 27 01:08:02 PDT 2007


Hi again,

I think I've tracked down the problem with texturing a little further, 
and put a demonstration of the error in an osgwindows-based example. By 
setting the threading model to singlethreaded to the viewers in this 
application one can see the difference as shown in the attached screenshots.

Could someone please give this small program a try and verify/confirm 
the error that I am seeing?

I think it has to do with the fact that glClientActiveTexture is not 
explicitly set for unit 0 when a display list is created for geometry. 
(see also the message from DC Fennel yesterday) E.g. this is typically 
done for a multitextured geometry (log from gDEBugger):
glGenLists(1)
glNewList(14, GL_COMPILE)
glVertexPointer(3, GL_FLOAT, 0, 0x19B2320)
glNormalPointer(GL_FLOAT, 0, 0x19B23A8)
glEnableClientState(GL_TEXTURE_COORD_ARRAY)
glTexCoordPointer(2, GL_FLOAT, 0, 0x19B2BD8)
glClientActiveTexture(GL_TEXTURE1)
glEnableClientState(GL_TEXTURE_COORD_ARRAY)
glTexCoordPointer(2, GL_FLOAT, 0, 0x19B2D38)
glDrawArrays(GL_TRIANGLES, 0, 6)
glEndList()

Shouldn't glClientActiveTexture(GL_TEXTURE0) here be as well?

I think this is typically not noticed since most applications are 
multi-threaded by default, and geometry is properly sorted. In a single 
threaded application texture states can be left in a wrong state.

Thanks for your time, I would appreciate it when someone tries to 
confirm this.

best regards
Raymond



Raymond de Vries wrote:
> Hi Robert,
>
>   
>> State the leaks out of one subgraph into the next is typically down to
>> some geometry not having color or normal arrays attached to them when
>> they need it, or in your case it could be that your are enabling the
>> second texture unit for all the scene, but only defining tex coords
>> for that texture unit for a small proportion of the scene.
>>     
>
> Agreed, this makes sense, I had come up with this myself too. In the
> scene, it looks as loosing textures, which is not really the case.
>
> I assume that osg disables the texture units when no texture and/or
> texture coordinates are set for these units, right? At the moment it seems
> that there is a dependancy whether or not models are in the same frustum.
>
>   
>> BTW, if you want other people to try out your models its best to zip
>> them all up together as copying and pasting text files is really error
>> prone.
>>     
>
> Ok.
>
> I will dive into this deeper.
>
> thanks again,
> Raymond
>
>   
>> Robert.
>>
>> On 9/21/07, Raymond de Vries <reedev at xs4all.nl> wrote:
>>     
>>> Hi Robert, good morning,
>>>
>>> I fully understand your point of view about the osgViewer, and I support
>>> that. Actually, I've set up a test project to give it a try.
>>>
>>> It seems that my problem has to do with my (hand-made) multi-textured
>>> models! So it seems that I am not handling the statesets properly... I
>>> created a multi-textured .osg file by hand, and I suspect that I forgot
>>> to set/change something. It looks ok when I load it in osgviewer and I
>>> don't see any errors reported by osgviewer (env var set to DEBUG_FP).
>>> Other models then this multi-textured plane loose their texture in this
>>> situation:
>>> - 2 windows, each has its own sceneview
>>> - sceneview's frustums are set so that the multi-textured plane is only
>>> visible in 1 sceneview
>>> - it doesn't matter if the other models are in the viewing frustum of
>>> each window
>>>
>>> This is how I created the multi-textured plane in .osg file format:
>>> 1) export a textured plane from 3dsmax
>>> 2) added the "textureUnit 1" section by copying from the "textureUnit 0"
>>> section
>>> 3) added the "TexCoordArray 1" section by copying from the
>>> "TexCoordArray 0" section
>>> 3) added "TexEnv" section
>>> I tried to change the renderbin but it does not change anything.
>>>
>>> Can someone please take a look at the attached model? Or point me to a
>>> properly multi-textured model in .osg format?
>>>
>>> pfew, it's driving me nuts.
>>>
>>> Thanks a lot for your time!
>>> Raymond
>>>
>>> Btw I'm now using osg 2.1.11 on WindowsXP, Visual Studio 2005 SP1
>>>
>>>
>>> Robert Osfield wrote:
>>>       
>>>> On 9/20/07, Raymond de Vries <reedev at xs4all.nl> wrote:
>>>>
>>>>         
>>>>> I know, it sounds that I'm doing strange things. But the opposite is
>>>>> true. Well, I am stripping everything and see where it is. Eventually
>>>>>           
>>> it
>>>       
>>>>> will be something small & stupid, as always ;-)
>>>>>
>>>>>           
>>>> I'm afraid your set up is novel enough that others will only be clutch
>>>> at straws at what the issue.  One of the reasons for the new osgViewer
>>>> library is to pull a whole range of disparate usage models together
>>>> under one family of classes to avoid the issues of users rolling a lot
>>>> of functionality on their own as its almost impossible to remotely
>>>> support such bespoke configurations.
>>>>
>>>> The OSG does support multiple graphics context just fine, but your
>>>> have to be careful about management of threads, contextIDs.  In the
>>>> case of 2.x it is more robust than ever in multi-threaded
>>>> multi-context role, and with osgViewer the vast majority of the
>>>> complexity of supporting these configurations is wrapped for you.
>>>>
>>>> Robert.
>>>> _______________________________________________
>>>> osg-users mailing list
>>>> osg-users at lists.openscenegraph.org
>>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>>
>>>>
>>>>
>>>>         
>>> MatrixTransform {
>>>   DataVariance STATIC
>>>   name "Scene Root"
>>>   nodeMask 0xff
>>>   cullingActive TRUE
>>>   StateSet {
>>>     UniqueID StateSet_0
>>>     DataVariance STATIC
>>>     rendering_hint DEFAULT_BIN
>>>     renderBinMode INHERIT
>>>     GL_LIGHTING ON
>>>   }
>>>   referenceFrame RELATIVE
>>>   Matrix {
>>>     1 0 0 0
>>>     0 1 0 0
>>>     0 0 1 0
>>>     0 0 0 1
>>>   }
>>>   num_children 1
>>>   MatrixTransform {
>>>     DataVariance STATIC
>>>     name "Front"
>>>     nodeMask 0xff
>>>     cullingActive TRUE
>>>     referenceFrame RELATIVE
>>>     Matrix {
>>>       1 0 0 0
>>>       0 1 0 0
>>>       0 0 1 0
>>>       0 0 0 1
>>>     }
>>>     num_children 1
>>>     Geode {
>>>       UniqueID Geode_1
>>>       DataVariance STATIC
>>>       nodeMask 0xff
>>>       cullingActive TRUE
>>>       num_drawables 1
>>>       Geometry {
>>>         DataVariance DYNAMIC
>>>         StateSet {
>>>           UniqueID StateSet_2
>>>           DataVariance STATIC
>>>           rendering_hint DEFAULT_BIN
>>>           renderBinMode INHERIT
>>>           GL_CULL_FACE ON
>>>           GL_LIGHTING ON
>>>           0xba1 ON
>>>           Material {
>>>             DataVariance STATIC
>>>             ColorMode OFF
>>>             ambientColor 0.588235 0.588235 0.588235 1
>>>             diffuseColor 1 1 1 1
>>>             specularColor 0 0 0 1
>>>             emissionColor 0 0 0 1
>>>             shininess 0
>>>           }
>>>           textureUnit 0 {
>>>             GL_TEXTURE_2D ON
>>>             Texture2D {
>>>               DataVariance STATIC
>>>               file "LIMESTO1.jpg"
>>>               wrap_s CLAMP_TO_EDGE
>>>               wrap_t CLAMP_TO_EDGE
>>>               wrap_r CLAMP_TO_EDGE
>>>               min_filter LINEAR_MIPMAP_LINEAR
>>>               mag_filter LINEAR
>>>               maxAnisotropy 1
>>>               borderColor 0 0 0 0
>>>               borderWidth 0
>>>               useHardwareMipMapGeneration TRUE
>>>               unRefImageDataAfterApply FALSE
>>>               internalFormatMode USE_IMAGE_DATA_FORMAT
>>>               resizeNonPowerOfTwo TRUE
>>>             }
>>>           }
>>>                                         textureUnit 1 {
>>>                                                 GL_TEXTURE_2D ON
>>>                                                 Texture2D {
>>>                                                         DataVariance
>>> STATIC
>>>                                                         file
>>> "checkerboard.png"
>>>                                                         wrap_s
>>> CLAMP_TO_EDGE
>>>                                                         wrap_t
>>> CLAMP_TO_EDGE
>>>                                                         wrap_r
>>> CLAMP_TO_EDGE
>>>                                                         min_filter
>>> LINEAR_MIPMAP_LINEAR
>>>                                                         mag_filter
>>> LINEAR
>>>                                                         maxAnisotropy 1
>>>                                                         borderColor 0 0
>>> 0 0
>>>                                                         borderWidth 0
>>>                                                         useHardwareMipMapGeneration
>>> TRUE
>>>                                                         unRefImageDataAfterApply
>>> FALSE
>>>                                                         internalFormatMode
>>> USE_IMAGE_DATA_FORMAT
>>>                                                         resizeNonPowerOfTwo
>>> TRUE
>>>                                                 }
>>>                                         }
>>>                                 TexEnv {
>>>                                                 DataVariance STATIC
>>>                                                 mode MODULATE
>>>                                         }
>>>         }
>>>         useDisplayList TRUE
>>>         useVertexBufferObjects FALSE
>>>         PrimitiveSets 1
>>>         {
>>>           DrawArrays TRIANGLES 0 6
>>>         }
>>>         VertexArray Vec3Array 6
>>>         {
>>>           -1 -0.5 0
>>>           1 -0.5 0
>>>           1 -0.5 3
>>>           1 -0.5 3
>>>           -1 -0.5 3
>>>           -1 -0.5 0
>>>         }
>>>         NormalBinding PER_VERTEX
>>>         NormalArray Vec3Array 6
>>>         {
>>>           0 -1 0
>>>           0 -1 0
>>>           0 -1 0
>>>           0 -1 0
>>>           0 -1 0
>>>           0 -1 0
>>>         }
>>>         TexCoordArray 0 Vec2Array 6
>>>         {
>>>           0 0
>>>           1 0
>>>           1 1
>>>           1 1
>>>           0 1
>>>           0 0
>>>         }
>>>         TexCoordArray 1 Vec2Array 6
>>>         {
>>>           0 0
>>>           1 0
>>>           1 1
>>>           1 1
>>>           0 1
>>>           0 0
>>>         }
>>>       }
>>>     }
>>>   }
>>> }
>>>
>>> _______________________________________________
>>> osg-users mailing list
>>> osg-users at lists.openscenegraph.org
>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>
>>>
>>>
>>>       
>> _______________________________________________
>> osg-users mailing list
>> osg-users at lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>     
>
>
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: osgwindows_multitextured_error_model.rar
Type: application/octet-stream
Size: 54253 bytes
Desc: not available
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20071027/3b040ca4/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: output_multi_threaded.jpg
Type: image/jpeg
Size: 24226 bytes
Desc: not available
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20071027/3b040ca4/attachment-0004.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: output_single_threaded.jpg
Type: image/jpeg
Size: 21713 bytes
Desc: not available
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20071027/3b040ca4/attachment-0005.jpg>


More information about the osg-users mailing list