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