[osg-users] Fixed (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 08:39:42 PDT 2007


Hi Robert,

Thanks for your answer. Of course my remark was not a bug fix, only a way
of showing how the rendering can be fixed, in a quick n dirty way.

I look forward to the moment that you have time to try the sample
yourself. I've seen other issues as well so it might indeed be a more
fundamental issue.

best regards
Raymond


> HI Raymond,
>
> Disabling lazy state updating isn't really a bug fix, rather its
> hiding a problem elsewhere - why the osg::State object is getting out
> of sync.  I can't answer this as I've not see the problem you are
> seeing first hand let alone tried to debug it.
>
> As osg::State is getting of sync then it could be more things that
> might come unstuck than just the client texture state.  It would be
> worth investigating why osg::State is getting out of sync.
>
> Robert.
>
> On 10/27/07, Raymond de Vries <reedev at xs4all.nl> wrote:
>> Hi again,
>>
>> The texture state 'leaking' was indeed the problem, I verified in my
>> application (and various test applications). It is ok in single and
>> multi threaded versions.
>>
>> Ok, I've simplified State.cpp into:
>> bool State::setClientActiveTextureUnit( unsigned int unit )
>> {
>>   _glClientActiveTexture(GL_TEXTURE0+unit);
>>   _currentClientActiveTextureUnit = unit;
>>   return true;
>> }
>>
>>
>> /** set the current texture unit, return true if selected, false if
>> selection failed such as when multitexturing is not supported.
>>   * note, only updates values that change.*/
>> bool State::setActiveTextureUnit( unsigned int unit )
>> {
>>   _glActiveTexture(GL_TEXTURE0+unit);
>>   _currentActiveTextureUnit = unit;
>>   return true;
>> }
>>
>> and my problem is solved (of course both single and multi threaded).
>> Verified with gDEBugger, for the multitextured geometry:
>> glGenLists(1)
>> glNewList(14, GL_COMPILE)
>> glVertexPointer(3, GL_FLOAT, 0, 0x19B2320)
>> glNormalPointer(GL_FLOAT, 0, 0x19B23A8)
>> glClientActiveTexture(GL_TEXTURE0)
>> 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()
>>
>> Robert, after all my application works fine in my (free)glut based,
>> multi-window, program :-) So it had nothing to do with shared contexts
>> issues in (free)glut.
>>
>> Cheers
>> Raymond
>>
>>
>> Raymond de Vries wrote:
>> > 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
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>> > ------------------------------------------------------------------------
>> >
>> >
>> >
>> > ------------------------------------------------------------------------
>> >
>> >
>> > ------------------------------------------------------------------------
>> >
>> > _______________________________________________
>> > 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
>





More information about the osg-users mailing list