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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
>>>>> [email protected]
>>>>> 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
>>>> [email protected]
>>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> osg-users mailing list
>>> [email protected]
>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> osg-users mailing list
>> [email protected]
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>
>>
>>
>
>
> ------------------------------------------------------------------------
>
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> osg-users mailing list
> [email protected]
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
