Re: [osg-users] Please test OpenScenGraph-3.6 branch in prep for the up commign 3.6.5 maintainance release
Nathan Mielcarek writes: > Since the 43b274f commit (Mar 21, 2019) OSG has been installing 64-bit > libraries in /usr/local/lib instead of /usr/local/lib64 due to the > condition of LIB_POSTFIX not being defined when using cmake > 2.8.5. Strange; it has created lib64/ for me, using cmake 3.15.4. Nevertheless, I am not installing to the default /usr/local, but elsewhere. -- Alberto ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test OpenScenGraph-3.6 branch in prep for the up commign 3.6.5 maintainance release
Hi Robert, I made an easy fix to the cmake file that avoids having to rewrite a lot of the variables and sent it to osg-submissions. Thanks, Nathan On Wed, Dec 18, 2019 at 10:09 AM Nathan Mielcarek wrote: > Hi Robert, > > Looks good except for the following issue I just noticed since 3.6.3: > > Since the 43b274f commit (Mar 21, 2019) OSG has been installing 64-bit > libraries in /usr/local/lib instead of /usr/local/lib64 due to the > condition of LIB_POSTFIX not being defined when using cmake > 2.8.5. > > Let me know if you would like me to attempt a fix, I believe it needs > either LIB_POSTFIX re-defined when 64-bit it detected or to change > CMakeLists.txt to use OSG_INSTALL_LIBDIR instead. > > Thanks, > Nathan > > On Wed, Dec 18, 2019 at 8:29 AM Ravi Mathur wrote: > >> Hi Robert, >> >> The OpenSceneGraph-3.6 branch compiles and runs properly on my OSX Mojave >> (10.14.6) system. I tried osgviewer, several OSG examples, and my own >> OSG-based projects. >> >> Thanks, >> Ravi >> >> On Mon, Dec 16, 2019 at 12:16 PM Robert Osfield >> wrote: >> >>> Hi All, >>> >>> I have merged the outstanding pull requests and made a couple of bug >>> fixes that are now checked into the OpenSceneGraph-3.6 branch: >>> >>> >>> https://github.com/openscenegraph/OpenSceneGraph/tree/OpenSceneGraph-3.6 >>> >>> Could everyone test out this branch to see how well it's working on your >>> build platforms and against your hardware/OS/application combinations. If >>> everything looks solid I make a 3.6.5 release candidate with the aim to >>> make a 3.6.5 in January. >>> >>> Thanks in advance with your help in testing. >>> Robert. >>> >>> *-- ChangeLog since the 3.6.4 release on 26th of July 2019:* >>> >>> Mon, 16 Dec 2019 16:51:16 + >>> Author : Robert Osfield >>> Added automatically removal from the OjbectCache when a object or it's >>> subgraph contain Texture that no longer have an osg::Image. >>> >>> Mon, 16 Dec 2019 11:54:12 + >>> Author : OpenSceneGraph git repository >>> Merge pull request #871 from LaurensVoerman/commit_tgaFixfix debug >>> compile error for ReaderWriterTGA >>> >>> Mon, 16 Dec 2019 11:02:41 +0100 >>> Author : Laurens Voerman >>> fix debug compile error for ReaderWriterTGA >>> >>> Mon, 16 Dec 2019 09:40:30 + >>> Author : OpenSceneGraph git repository >>> Merge pull request #870 from >>> eligovision/OpenSceneGraph-3.6_glext_fixGLExtensions's isPBOSupported and >>> isVAOSupported flags fixed >>> >>> Mon, 16 Dec 2019 09:40:00 + >>> Author : OpenSceneGraph git repository >>> Merge pull request #869 from eligovision/OpenSceneGraph-3.6_glextAdded >>> FBO GL extensions (useful for mobile VR etc.) >>> >>> Fri, 13 Dec 2019 19:40:11 +0300 >>> Author : konstantin.matveyev >>> GLExtensions's isPBOSupported and isVAOSupported flags fixed for >>> GLES2+GLES3 configuration >>> >>> Fri, 13 Dec 2019 19:42:30 +0300 >>> Author : konstantin.matveyev >>> GLExtensions's isInvalidateFramebufferSupported flag improved >>> >>> Tue, 26 Nov 2019 17:17:38 +0800 >>> Author : PntAndCnt >>> Fontconfig should be external library.Add Fontconfig to TARGET_LIBRARIES >>> cause osg3::osgText target looking for >>> openscegraph-Fontconfig-import-targets.cmake, which doesn't exists. >>> >>> >>> Sun, 13 Oct 2019 20:24:36 +0800 >>> Author : PntAndCnt >>> Fix a typo and invisible 3dtext in examples/osgtext.Second text >>> alignment is wrong when "--alignment" specified. >>> >>> 3D text radius is too small, only SCREEN_COORDS can be seen. >>> >>> Text position should multiply radius. >>> >>> >>> Tue, 3 Sep 2019 16:11:14 +0800 >>> Author : Kent >>> Mered fix for internalFormat >>> >>> Thu, 12 Dec 2019 18:41:23 +0300 >>> Author : valid-ptr >>> glInvalidateFramebuffer added to GLExtensions >>> >>> Thu, 31 Oct 2019 18:59:04 +0300 >>> Author : konstantin.matveyev >>> glFramebufferTexture2DMultisample added to GLExtensions >>> >>> Tue, 10 Dec 2019 15:08:25 +0300 >>> Author : Dmitry Marakasov >>> Add FreeBSD-specific code bits for pthread_setaffinity_np support >>> >>> Thu, 12 Dec 2019 13:25:44 + >>> Author : Robert Osfield >>> Fix linking with Xinerama >>> >>> Thu, 12 Dec 2019 13:09:33 + >>> Author : OpenSceneGraph git repository >>> Merge pull request #861 from aluaces/default-ffmpegSet ffmpeg as the >>> default plugin for video files. >>> >>> Fri, 22 Nov 2019 21:07:36 +0100 >>> Author : elsid >>> Fix clang 8 & libc++ build errorsReplace operators for implicit type >>> conversion by explicit data() method to >>> access implementation pointer and subscript operator to access element by >>> index just like in std::vector. >>> >>> src/osgPlugins/tga/ReaderWriterTGA.cpp:455:22: error: use of overloaded >>> operator '==' is ambiguous (with operand types 'SafeArray' >>> and 'long') >>> if (colormap == NULL) >>> ^ >>> src/osgPlugins/tga/ReaderWriterTGA.cpp:525:16: error: use of overloaded >>> operator '==' is ambiguous (with operand types 'SafeArray' >>> and 'long') >>> if (buffer == NULL ||
Re: [osg-users] Please test OpenScenGraph-3.6 branch in prep for the up commign 3.6.5 maintainance release
>
> I can't investigate either issue without being able to recreate the
> crash/GL errors myself. If either of these issues occur on an existing OSG
> example then I can take it from there.
Short of being able to recreate the issue and investigate it myself the
> only thing I can do is suggest ways of investigating the issue that might
> reveal the cause of the issues.
Your suggestions are the kinds of thing I'd be looking at if I had more
time, but unfortunately, I don't. However, it might actually be reasonable
for you to take a look yourself. I'd put money on OpenMW being the most
widely-installed OSG application, and it's open-source, so it would be a
good candidate for part of your own regression testing.
Sorry to just pile on work when I'm unable to help myself. We just don't
have anyone who's both got time and familiarity with OSG.
Thanks,
Chris
On Wednesday, 18 December 2019 10:56:39 UTC, Robert Osfield wrote:
>
>
>
> On Tuesday, 17 December 2019 21:40:37 UTC, Chris Djali / AnyOldName3 wrote:
>>
>> Hi Robert,
>>
>> OpenMW still experiences some regressions when built with OSG 3.6.x
>> instead of 3.4.1. It's completely possible they're because we're trying to
>> coerce OSG systems to do things they weren't intended to as it's a big
>> project created without much interaction with the OSG community.
>>
>> The two issues we're tracking are:
>>
>>- https://gitlab.com/OpenMW/openmw/issues/5205 the builds provided by
>>Arch Linux crash. The Arch packagers think they're not doing anything
>>abnormally, so I don't have a clue where the issue actually lies.
>>
>> My best guess is there is some threading issue where a slightly different
> build resulting slightly different data alignment in a race condition
> becoming critical. That's just a guess though, there isn't any evidence in
> the thread above that can pin point any specific problem.
>
> Given the fickle nature of threading problems, just because it occurs in
> 3.6.x but not 3.4.x doesn't mean that there has been a bug introduced after
> 3.4, it just needs some condition to slightly change that cause some of the
> data in the application to be aligned different and over the application
> goes.
>
> The best I can recommend is to run the application with valgrind
> --tool=helgrind to see if it picks up any race conditions.
>
>>
>>-
>>- https://gitlab.com/OpenMW/openmw/issues/4773 OpenGL errors we
>>didn't use to get. This hasn't been very thoroughly investigated at all.
>>
>> There are potentially other issues, too. I had a collection of stack
>> traces of crashes and OpenGL errors that I was working through, and not all
>> of them ended up on our tracker. As the issues I'd already brought up on
>> the forums were taking a while to flush through due to your focus on VSG,
>> tracking down OSG regressions had been put on the back burner, and I don't
>> have a huge amount of time right now. That means the best I can do if you
>> want things narrowing down is to try and get people to replicate the issues
>> with the tip of the 3.6 branch and potentially get stack traces.
>>
>>
> Does this happen with all hardware/OS/driver combinations or just
> particular ones?
>
> From the glTextStorage2D documentation at
> https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glTexStorage2D.xhtml
>
> Errors
>
> GL_INVALID_OPERATION is generated by glTexStorage2D if zero is bound to
> target.
>
> GL_INVALID_OPERATION is generated by glTextureStorage2D if texture is not
> the name of an existing texture object.
>
> GL_INVALID_ENUM is generated if internalformat is not a valid sized
> internal format.
>
> GL_INVALID_ENUM is generated if target or the effective target of texture
> is not one of the accepted targets described above.
>
> GL_INVALID_VALUE is generated if width, height or levels are less than 1.
>
> GL_INVALID_OPERATION is generated if target is GL_TEXTURE_1D_ARRAY or
> GL_PROXY_TEXTURE_1D_ARRAY and levels is greater than ⌊log2(width)⌋+1
>
> GL_INVALID_OPERATION is generated if target is not GL_TEXTURE_1D_ARRAY or
> GL_PROXY_TEXTURE_1D_ARRAY and levels is greater than ⌊log2(max(width,
> height))⌋+1
>
> Given the glTexStorage2D(GL_TEXTURE_2D, 1, GL_RGB8, 320, 320) looks valid
> on it's own we are left with:
>
> GL_INVALID_OPERATION is generated by glTexStorage2D if zero is bound to
> target.
>
> The next step would be to put into some test code that Texture2D.cpp to
> track what is happening right before the call. There is a
> textureObject->bind() before each call to glTexStorage2D, but perhaps this
> is failing for some reason.
>
> GLenum texStorageSizedInternalFormat =
> extensions->isTextureStorageEnabled && (_borderWidth==0) ?
> selectSizedInternalFormat() : 0;
> if (texStorageSizedInternalFormat!=0)
> {
> textureObject = generateAndAssignTextureObject(contextID,
> GL_TEXTURE_2D, _numMipmapLevels,
Re: [osg-users] Texture Caching Problem with 3.6.3/4
Robert, Thanks for the fix. That solved the problem. I had previously worked around it with your suggestion to disable texture caching. unsigned int options = osgUtil::Optimizer::ALL_OPTIMIZATIONS; options ^= osgUtil::Optimizer::OPTIMIZE_TEXTURE_SETTINGS; optimizer.optimize(model, options); But this is a better fix. Greg -- You received this message because you are subscribed to the Google Groups "OpenSceneGraph Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to osg-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/osg-users/2ace79a0-1141-465a-80ab-a0ba90bc8f5c%40googlegroups.com. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test OpenScenGraph-3.6 branch in prep for the up commign 3.6.5 maintainance release
Hi Robert, Looks good except for the following issue I just noticed since 3.6.3: Since the 43b274f commit (Mar 21, 2019) OSG has been installing 64-bit libraries in /usr/local/lib instead of /usr/local/lib64 due to the condition of LIB_POSTFIX not being defined when using cmake > 2.8.5. Let me know if you would like me to attempt a fix, I believe it needs either LIB_POSTFIX re-defined when 64-bit it detected or to change CMakeLists.txt to use OSG_INSTALL_LIBDIR instead. Thanks, Nathan On Wed, Dec 18, 2019 at 8:29 AM Ravi Mathur wrote: > Hi Robert, > > The OpenSceneGraph-3.6 branch compiles and runs properly on my OSX Mojave > (10.14.6) system. I tried osgviewer, several OSG examples, and my own > OSG-based projects. > > Thanks, > Ravi > > On Mon, Dec 16, 2019 at 12:16 PM Robert Osfield > wrote: > >> Hi All, >> >> I have merged the outstanding pull requests and made a couple of bug >> fixes that are now checked into the OpenSceneGraph-3.6 branch: >> >> >> https://github.com/openscenegraph/OpenSceneGraph/tree/OpenSceneGraph-3.6 >> >> Could everyone test out this branch to see how well it's working on your >> build platforms and against your hardware/OS/application combinations. If >> everything looks solid I make a 3.6.5 release candidate with the aim to >> make a 3.6.5 in January. >> >> Thanks in advance with your help in testing. >> Robert. >> >> *-- ChangeLog since the 3.6.4 release on 26th of July 2019:* >> >> Mon, 16 Dec 2019 16:51:16 + >> Author : Robert Osfield >> Added automatically removal from the OjbectCache when a object or it's >> subgraph contain Texture that no longer have an osg::Image. >> >> Mon, 16 Dec 2019 11:54:12 + >> Author : OpenSceneGraph git repository >> Merge pull request #871 from LaurensVoerman/commit_tgaFixfix debug >> compile error for ReaderWriterTGA >> >> Mon, 16 Dec 2019 11:02:41 +0100 >> Author : Laurens Voerman >> fix debug compile error for ReaderWriterTGA >> >> Mon, 16 Dec 2019 09:40:30 + >> Author : OpenSceneGraph git repository >> Merge pull request #870 from >> eligovision/OpenSceneGraph-3.6_glext_fixGLExtensions's isPBOSupported and >> isVAOSupported flags fixed >> >> Mon, 16 Dec 2019 09:40:00 + >> Author : OpenSceneGraph git repository >> Merge pull request #869 from eligovision/OpenSceneGraph-3.6_glextAdded >> FBO GL extensions (useful for mobile VR etc.) >> >> Fri, 13 Dec 2019 19:40:11 +0300 >> Author : konstantin.matveyev >> GLExtensions's isPBOSupported and isVAOSupported flags fixed for >> GLES2+GLES3 configuration >> >> Fri, 13 Dec 2019 19:42:30 +0300 >> Author : konstantin.matveyev >> GLExtensions's isInvalidateFramebufferSupported flag improved >> >> Tue, 26 Nov 2019 17:17:38 +0800 >> Author : PntAndCnt >> Fontconfig should be external library.Add Fontconfig to TARGET_LIBRARIES >> cause osg3::osgText target looking for >> openscegraph-Fontconfig-import-targets.cmake, which doesn't exists. >> >> >> Sun, 13 Oct 2019 20:24:36 +0800 >> Author : PntAndCnt >> Fix a typo and invisible 3dtext in examples/osgtext.Second text alignment >> is wrong when "--alignment" specified. >> >> 3D text radius is too small, only SCREEN_COORDS can be seen. >> >> Text position should multiply radius. >> >> >> Tue, 3 Sep 2019 16:11:14 +0800 >> Author : Kent >> Mered fix for internalFormat >> >> Thu, 12 Dec 2019 18:41:23 +0300 >> Author : valid-ptr >> glInvalidateFramebuffer added to GLExtensions >> >> Thu, 31 Oct 2019 18:59:04 +0300 >> Author : konstantin.matveyev >> glFramebufferTexture2DMultisample added to GLExtensions >> >> Tue, 10 Dec 2019 15:08:25 +0300 >> Author : Dmitry Marakasov >> Add FreeBSD-specific code bits for pthread_setaffinity_np support >> >> Thu, 12 Dec 2019 13:25:44 + >> Author : Robert Osfield >> Fix linking with Xinerama >> >> Thu, 12 Dec 2019 13:09:33 + >> Author : OpenSceneGraph git repository >> Merge pull request #861 from aluaces/default-ffmpegSet ffmpeg as the >> default plugin for video files. >> >> Fri, 22 Nov 2019 21:07:36 +0100 >> Author : elsid >> Fix clang 8 & libc++ build errorsReplace operators for implicit type >> conversion by explicit data() method to >> access implementation pointer and subscript operator to access element by >> index just like in std::vector. >> >> src/osgPlugins/tga/ReaderWriterTGA.cpp:455:22: error: use of overloaded >> operator '==' is ambiguous (with operand types 'SafeArray' >> and 'long') >> if (colormap == NULL) >> ^ >> src/osgPlugins/tga/ReaderWriterTGA.cpp:525:16: error: use of overloaded >> operator '==' is ambiguous (with operand types 'SafeArray' >> and 'long') >> if (buffer == NULL || linebuf == NULL) >> ~~ ^ >> src/osgPlugins/tga/ReaderWriterTGA.cpp:525:35: error: use of overloaded >> operator '==' is ambiguous (with operand types 'SafeArray' >> and 'long') >> if (buffer == NULL || linebuf == NULL) >> ~~~ ^ >> src/osgPlugins/tga/ReaderWriterTGA.cpp:548:30: error: use of overloaded >>
Re: [osg-users] Please test OpenScenGraph-3.6 branch in prep for the up commign 3.6.5 maintainance release
Hi Robert, The OpenSceneGraph-3.6 branch compiles and runs properly on my OSX Mojave (10.14.6) system. I tried osgviewer, several OSG examples, and my own OSG-based projects. Thanks, Ravi On Mon, Dec 16, 2019 at 12:16 PM Robert Osfield wrote: > Hi All, > > I have merged the outstanding pull requests and made a couple of bug fixes > that are now checked into the OpenSceneGraph-3.6 branch: > > > https://github.com/openscenegraph/OpenSceneGraph/tree/OpenSceneGraph-3.6 > > Could everyone test out this branch to see how well it's working on your > build platforms and against your hardware/OS/application combinations. If > everything looks solid I make a 3.6.5 release candidate with the aim to > make a 3.6.5 in January. > > Thanks in advance with your help in testing. > Robert. > > *-- ChangeLog since the 3.6.4 release on 26th of July 2019:* > > Mon, 16 Dec 2019 16:51:16 + > Author : Robert Osfield > Added automatically removal from the OjbectCache when a object or it's > subgraph contain Texture that no longer have an osg::Image. > > Mon, 16 Dec 2019 11:54:12 + > Author : OpenSceneGraph git repository > Merge pull request #871 from LaurensVoerman/commit_tgaFixfix debug compile > error for ReaderWriterTGA > > Mon, 16 Dec 2019 11:02:41 +0100 > Author : Laurens Voerman > fix debug compile error for ReaderWriterTGA > > Mon, 16 Dec 2019 09:40:30 + > Author : OpenSceneGraph git repository > Merge pull request #870 from > eligovision/OpenSceneGraph-3.6_glext_fixGLExtensions's isPBOSupported and > isVAOSupported flags fixed > > Mon, 16 Dec 2019 09:40:00 + > Author : OpenSceneGraph git repository > Merge pull request #869 from eligovision/OpenSceneGraph-3.6_glextAdded FBO > GL extensions (useful for mobile VR etc.) > > Fri, 13 Dec 2019 19:40:11 +0300 > Author : konstantin.matveyev > GLExtensions's isPBOSupported and isVAOSupported flags fixed for > GLES2+GLES3 configuration > > Fri, 13 Dec 2019 19:42:30 +0300 > Author : konstantin.matveyev > GLExtensions's isInvalidateFramebufferSupported flag improved > > Tue, 26 Nov 2019 17:17:38 +0800 > Author : PntAndCnt > Fontconfig should be external library.Add Fontconfig to TARGET_LIBRARIES > cause osg3::osgText target looking for > openscegraph-Fontconfig-import-targets.cmake, which doesn't exists. > > > Sun, 13 Oct 2019 20:24:36 +0800 > Author : PntAndCnt > Fix a typo and invisible 3dtext in examples/osgtext.Second text alignment > is wrong when "--alignment" specified. > > 3D text radius is too small, only SCREEN_COORDS can be seen. > > Text position should multiply radius. > > > Tue, 3 Sep 2019 16:11:14 +0800 > Author : Kent > Mered fix for internalFormat > > Thu, 12 Dec 2019 18:41:23 +0300 > Author : valid-ptr > glInvalidateFramebuffer added to GLExtensions > > Thu, 31 Oct 2019 18:59:04 +0300 > Author : konstantin.matveyev > glFramebufferTexture2DMultisample added to GLExtensions > > Tue, 10 Dec 2019 15:08:25 +0300 > Author : Dmitry Marakasov > Add FreeBSD-specific code bits for pthread_setaffinity_np support > > Thu, 12 Dec 2019 13:25:44 + > Author : Robert Osfield > Fix linking with Xinerama > > Thu, 12 Dec 2019 13:09:33 + > Author : OpenSceneGraph git repository > Merge pull request #861 from aluaces/default-ffmpegSet ffmpeg as the > default plugin for video files. > > Fri, 22 Nov 2019 21:07:36 +0100 > Author : elsid > Fix clang 8 & libc++ build errorsReplace operators for implicit type > conversion by explicit data() method to > access implementation pointer and subscript operator to access element by > index just like in std::vector. > > src/osgPlugins/tga/ReaderWriterTGA.cpp:455:22: error: use of overloaded > operator '==' is ambiguous (with operand types 'SafeArray' > and 'long') > if (colormap == NULL) > ^ > src/osgPlugins/tga/ReaderWriterTGA.cpp:525:16: error: use of overloaded > operator '==' is ambiguous (with operand types 'SafeArray' > and 'long') > if (buffer == NULL || linebuf == NULL) > ~~ ^ > src/osgPlugins/tga/ReaderWriterTGA.cpp:525:35: error: use of overloaded > operator '==' is ambiguous (with operand types 'SafeArray' > and 'long') > if (buffer == NULL || linebuf == NULL) > ~~~ ^ > src/osgPlugins/tga/ReaderWriterTGA.cpp:548:30: error: use of overloaded > operator '==' is ambiguous (with operand types 'SafeArray' > and 'long') > if (formattedMap == NULL) > ^ > src/osgPlugins/tga/ReaderWriterTGA.cpp:574:40: error: use of overloaded > operator '[]' is ambiguous (with operand types 'SafeArray' > and 'int') > index = linebuf[x]; > ~~~^~ > src/osgPlugins/tga/ReaderWriterTGA.cpp:577:50: error: use of overloaded > operator '+' is ambiguous (with operand types 'SafeArray' > and 'int') > index = getInt16(linebuf + x * 2); > ~~~ ^ ~ >
Re: [osg-users] incorrectly imported TEXTURE_DIMENSION macro in osgText_Text.frag
Hi Robert, On 12/18/2019 8:30 AM, Robert Osfield wrote: This is exactly the fix I wrote 20 minutes ago, and now checked in :-) https://github.com/openscenegraph/OpenSceneGraph/commit/1968f3d6e14fe4cdfa98df465c1f383d2bb7d8de This fix is checked into OSG-3.6 branch and master. Thank you so much for your help with this. I'll update later today. If I encounter other similar situations I'll submit patches. Thanks, Cory ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] incorrectly imported TEXTURE_DIMENSION macro in osgText_Text.frag
Hi Cory, On Wed, 18 Dec 2019 at 14:21, Cory Riddell wrote: > Thank you for pointing me to exactly the right spot. I made a change at > the top of that function rather than in the spot you indicated. > > I set the locale immediately after the stringstream is constructed (line > 104): > > std::stringstream ss; > ss.imbue(std::locale::classic()); > ss< This is exactly the fix I wrote 20 minutes ago, and now checked in :-) https://github.com/openscenegraph/OpenSceneGraph/commit/1968f3d6e14fe4cdfa98df465c1f383d2bb7d8de This fix is checked into OSG-3.6 branch and master. > I see that the method createStateSet() is virtual. Rather than edit the > OSG source, would you advise creating a subclass and overriding this method? > This is something you could do if you had to for older versions of the OSG. The best solution is to have it part of the stringstream setup in Text.cpp as I'm sure this issue will crop up for others that change don't have standard locale. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] incorrectly imported TEXTURE_DIMENSION macro in osgText_Text.frag
Hi Robert,
Thank you for pointing me to exactly the right spot. I made a change
at the top of that function rather than in the spot you indicated.
I set the locale immediately after the stringstream is constructed
(line 104):
std::stringstream ss;
ss.imbue(std::locale::classic());
ss<
I see that the method createStateSet() is virtual. Rather than edit
the OSG source, would you advise creating a subclass and overriding
this method?
Cory
On 12/18/2019 5:14 AM, Robert Osfield
wrote:
Hi Cory,
Looking at osgText there following line (152,
OpenSceneGraph/src/osgText/Text.cpp sets up the
TEXTURE_DIMENSION:
ss.str("");
ss <<
float(activeFont->getTextureWidthHint());
defineList["TEXTURE_DIMENSION"] =
osg::StateSet::DefinePair(ss.str(),
osg::StateAttribute::ON);
Which makes me think that the
std::stringstream ss used is defaulting to your locale and
then GLSL is using the standard locale.
If this is so then setting the locale
on the stringstream would be the appropriate thing to do.
Robert.
___
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
Re: [osg-users] incorrectly imported TEXTURE_DIMENSION macro in osgText_Text.frag
Hi Cory,
Looking at osgText there following line (152,
OpenSceneGraph/src/osgText/Text.cpp sets up the TEXTURE_DIMENSION:
ss.str("");
ss << float(activeFont->getTextureWidthHint());
defineList["TEXTURE_DIMENSION"] =
osg::StateSet::DefinePair(ss.str(), osg::StateAttribute::ON);
Which makes me think that the std::stringstream ss used is defaulting to
your locale and then GLSL is using the standard locale.
If this is so then setting the locale on the stringstream would be the
appropriate thing to do.
Robert.
--
You received this message because you are subscribed to the Google Groups
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/osg-users/CAFN7Y%2BW_LqHjg7Lyhnm6xS%2BuTjAPigCHu_UKRw6M9Q50Ksp87A%40mail.gmail.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
You received this message because you are subscribed to the Google Groups
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/osg-users/CAFN7Y%2BW_LqHjg7Lyhnm6xS%2BuTjAPigCHu_UKRw6M9Q50Ksp87A%40mail.gmail.com.
Re: [osg-users] incorrectly imported TEXTURE_DIMENSION macro in osgText_Text.frag
Hi Cory, What version of the OSG, OS and hardware are you using? Do you see the issue with any of the OSG examples? What is you OS's default locale? Looking the #defines, is this osgText related? Or State that your application has set up? Cheers, Robert. On Tue, 17 Dec 2019 at 16:34, Cory Riddell wrote: > This may be related to something having to do with my locale settings, > but for some reason the fragment shader is failing to compile. This is > the error from the log: > > FRAGMENT glCompileShader "" FAILED > FRAGMENT Shader "" infolog: > Fragment shader failed to compile with the following errors: > ERROR: 1:184: error(#132) Syntax error: "024.0" parse error > ERROR: error(#273) 1 compilation errors. No code generated > > When I look for the source that is echoed to the log, the problem is the > thousands separator on line 4: > > Compiling C: FRAGMENT source: > 1: #define BACKDROP_COLOR vec4(0.300, 0.300, 0.300, 1.000) > 2: #define GLYPH_DIMENSION 240.0 > 3: #define OUTLINE 0.070 > 4: #define TEXTURE_DIMENSION 1,024.0 > > I believe the line is generated from this pragma: > > #pragma import_defines( SIGNED_DISTANCE_FIELD, TEXTURE_DIMENSION, > GLYPH_DIMENSION) > > At this point I'm stuck. What controls the generation of those #define > macros? How do I tell it to use the C locale? > > Thanks for any help, > Cory Riddell > > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- You received this message because you are subscribed to the Google Groups "OpenSceneGraph Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to osg-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/osg-users/CAFN7Y%2BVOhFWStNiTN54cLs1BufdhxkkERynFW1KCrx1dAHTSew%40mail.gmail.com. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- You received this message because you are subscribed to the Google Groups "OpenSceneGraph Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to osg-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/osg-users/CAFN7Y%2BVOhFWStNiTN54cLs1BufdhxkkERynFW1KCrx1dAHTSew%40mail.gmail.com.
Re: [osg-users] Please test OpenScenGraph-3.6 branch in prep for the up commign 3.6.5 maintainance release
On Tuesday, 17 December 2019 21:40:37 UTC, Chris Djali / AnyOldName3 wrote:
>
> Hi Robert,
>
> OpenMW still experiences some regressions when built with OSG 3.6.x
> instead of 3.4.1. It's completely possible they're because we're trying to
> coerce OSG systems to do things they weren't intended to as it's a big
> project created without much interaction with the OSG community.
>
> The two issues we're tracking are:
>
>- https://gitlab.com/OpenMW/openmw/issues/5205 the builds provided by
>Arch Linux crash. The Arch packagers think they're not doing anything
>abnormally, so I don't have a clue where the issue actually lies.
>
> My best guess is there is some threading issue where a slightly different
build resulting slightly different data alignment in a race condition
becoming critical. That's just a guess though, there isn't any evidence in
the thread above that can pin point any specific problem.
Given the fickle nature of threading problems, just because it occurs in
3.6.x but not 3.4.x doesn't mean that there has been a bug introduced after
3.4, it just needs some condition to slightly change that cause some of the
data in the application to be aligned different and over the application
goes.
The best I can recommend is to run the application with valgrind
--tool=helgrind to see if it picks up any race conditions.
>
>-
>- https://gitlab.com/OpenMW/openmw/issues/4773 OpenGL errors we didn't
>use to get. This hasn't been very thoroughly investigated at all.
>
> There are potentially other issues, too. I had a collection of stack
> traces of crashes and OpenGL errors that I was working through, and not all
> of them ended up on our tracker. As the issues I'd already brought up on
> the forums were taking a while to flush through due to your focus on VSG,
> tracking down OSG regressions had been put on the back burner, and I don't
> have a huge amount of time right now. That means the best I can do if you
> want things narrowing down is to try and get people to replicate the issues
> with the tip of the 3.6 branch and potentially get stack traces.
>
>
Does this happen with all hardware/OS/driver combinations or just
particular ones?
>From the glTextStorage2D documentation at
https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glTexStorage2D.xhtml
Errors
GL_INVALID_OPERATION is generated by glTexStorage2D if zero is bound to
target.
GL_INVALID_OPERATION is generated by glTextureStorage2D if texture is not
the name of an existing texture object.
GL_INVALID_ENUM is generated if internalformat is not a valid sized
internal format.
GL_INVALID_ENUM is generated if target or the effective target of texture
is not one of the accepted targets described above.
GL_INVALID_VALUE is generated if width, height or levels are less than 1.
GL_INVALID_OPERATION is generated if target is GL_TEXTURE_1D_ARRAY or
GL_PROXY_TEXTURE_1D_ARRAY and levels is greater than ⌊log2(width)⌋+1
GL_INVALID_OPERATION is generated if target is not GL_TEXTURE_1D_ARRAY or
GL_PROXY_TEXTURE_1D_ARRAY and levels is greater than ⌊log2(max(width,
height))⌋+1
Given the glTexStorage2D(GL_TEXTURE_2D, 1, GL_RGB8, 320, 320) looks valid
on it's own we are left with:
GL_INVALID_OPERATION is generated by glTexStorage2D if zero is bound to
target.
The next step would be to put into some test code that Texture2D.cpp to
track what is happening right before the call. There is a
textureObject->bind() before each call to glTexStorage2D, but perhaps this
is failing for some reason.
GLenum texStorageSizedInternalFormat =
extensions->isTextureStorageEnabled && (_borderWidth==0) ?
selectSizedInternalFormat() : 0;
if (texStorageSizedInternalFormat!=0)
{
textureObject = generateAndAssignTextureObject(contextID,
GL_TEXTURE_2D, _numMipmapLevels, texStorageSizedInternalFormat,
_textureWidth, _textureHeight, 1, _borderWidth);
textureObject->bind();
applyTexParameters(GL_TEXTURE_2D, state);
extensions->glTexStorage2D( GL_TEXTURE_2D,
osg::maximum(_numMipmapLevels,1), texStorageSizedInternalFormat,
_textureWidth, _textureHeight);
}
else
{
GLenum internalFormat = _sourceFormat ? _sourceFormat :
_internalFormat;
textureObject = generateAndAssignTextureObject(contextID,
GL_TEXTURE_2D, _numMipmapLevels, internalFormat, _textureWidth,
_textureHeight, 1, _borderWidth);
textureObject->bind();
applyTexParameters(GL_TEXTURE_2D, state);
glTexImage2D( GL_TEXTURE_2D, 0, _internalFormat,
_textureWidth, _textureHeight, _borderWidth,
internalFormat,
_sourceType ? _sourceType : GL_UNSIGNED_BYTE,
0);
}
I can't investigate either issue without being able to recreate the
crash/GL errors myself. If either of
