HI Raymond,

Once things settle down at my end I'll have a bash at compiling and
running your example.  I'd appreciate if others could have a look at
it as well.

As a general note, there isn't a big difference between single
threaded and multithread usage of the OSG in terms of OpenGL dispatch,
with two separate windows there should be two separate graphics
contexts and it should make no difference if you drive these from one
thread one two, the state for each context should be kept local to
each one.

W.r.t the glClientActiveTexture(GL_TEXTURE0) this should only be
called when required, not if the state is already in this mode.
osg::State trackes this and uses lazy state updating.  If you are
finding it not set when it needs to be then perhaps there is an issue
lurking somewhere in the OSG.  There is also a chance that you've come
across a buggy OpenGL driver.  What hardware are you working on?

Robert.



On 10/27/07, Raymond de Vries <[EMAIL PROTECTED]> 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

Reply via email to