Re: [osg-users] INVALID_OPERATION with compressed textures with mipmaps in OSG 3.4.0.
Hi Scott, The problem under OSX looks to be a driver bug, there is small chance that it's related to the problems you are seeing but likely a different issue. The problem you describe sounds like a driver bug too, testing out without other drivers/hardware/OS combinations would help with this. Have you tried any other combinations? There is possibility that different drivers handle the input data in different ways. The addition of the glTextureStorage2D usage might be adding another code pathway in the drivers that adds/removes/changes the way that data is handled introducing the inconsistency that you are seeing. The driver shouldn't be doing this, but no code is perfect. Without an example model that can reproduce the problem there isn't much others can do at this stage. Potentially we could add a catch for compressed textures + mipmap levels into osg::Texture*, but before any mods to the core OSG I'd need to have a test example to work from that exhibits a problem so that can confirm that these changes actually work. Robert. On 23 September 2015 at 22:24, Davis, Timothy S CTR comnavairsyscom < timothy.s.davis@navy.mil> wrote: > Robert > > Sorry for the bad posting of my last message. I'll repeat here and update > with new information. > > The code in question was added sometime during OSG 3.3.x development. It > was not in OSG 3.2.1. I just recently jumped from 3.2.1 to 3.4.0 for my > application which is when I ran into the problem. It worked fine with OSG > 3.2.1. In particular, it appears to be the added support for texture > storage objects and not specifically "compressed texture support". I noted > the call that gave the error was glCompressTexSubImage2D. However I should > point out that I determined this using gDEBugger. My version doesn't seem > to understand the texture storage extension. So the error may have been > generated by the earlier call to setup the texture storage. I checked into > this and indeed an INVALID_OPERATION was generated by the call to > glTexStorage2D. > > In addition, on my machine the problem doesn't affect all compressed > textures with mipmaps. The model that first caused the problem had several > such textures, but only a small 32x32 texture resulted in a problem. I > have no idea why this would be the case. However I remember others > reporting issues with loading DDS textures and working around it by > commenting out the following line in ReaderWriterDDS: > If ( mipmap_offset.size()>0) osgImage->setMipmapLevels(mipmap_offsets); > Commenting that line out would appear to disable mipmaps for compressed > textures and avoid the problems I've indicated. This older problem was > reported only on OSX, but may be related. This type of changed made to the > IVE loader would also have fixed my problem at the expense of disabling > mipmaps. > > Looking at a different model, the one problem texture was 128x128. So > there appears to be nothing special about the size. I did see that the > rendering result for the models that have the problem is different between > using the fixed-function pipeline and a shader. With the FFP, the > rendering appears correct, though the INVALID_OPERATION error is > generated. With a shader, the textures rendered black. > > I looked at making a simple model that would reproduce the problem. > However, I've failed to create such a model. It just always works with no > render problems or OpenGL errors. > > For my application, I've worked around the problem by reducing the number > of mipmap levels to avoid using levels smaller than the compression block > size. So I consider the problem fixed for me. However, I feel this is > information that you and the rest of the community can use. > > > Scott > > > ___ > 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] Modern GLSL and OSG
NOTE: the current development version of ANGLE is targeting OpenGL ES 3.0, if you want to be more up to date. I am not sure about its level of completion and stability though. Maybe you can find more complete (commercial?) virtualization solutions to run the DX backend. Also maybe Wine is suitable for this. DirectX 9.0c should be well supported by Wine (or its commercial counterpart Crossover). Christian 2015-09-23 14:49 GMT+02:00 Christian Buchner: > > If you're using Windows you could try building OSG against ANGLE > and limit yourself to the OpenGL ES 2.0 API feature set. Here you can't > accidentially fall back into using deprecated (fixed function) features > because these have been stripped from the API. > > There would also be plenty of books about OpenGL ES 2.0 available - and > you can immediately target mobile platforms (iOS, Android) > > Christian > > > 2015-09-23 14:44 GMT+02:00 Garth D : > >> >> Hi all, >> >> I was wondering if anyone can make some suggestions as to resources that >> are useful for learning GLSL in modern OpenGL (say, 3.0+) with a specific >> focus on use with OSG. >> >> My existing GLSL knowledge is weak compared to my general 3D knowledge, >> and mostly dates back to the early days of shaders. A lot of what I have >> personally done with OpenGL and OSG has involved the fixed-function >> pipeline, or things that map to it fairly closely. >> >> Thus far I've been digging around online for GLSL resources, but tend to >> frequently find myself doing it the wrong way as I'm using features that >> have since become deprecated. On the OSG side I tend to dig around in the >> OSG examples and search the source to try to find the OSG equivalents to >> OpenGL calls I see mentioned in the GLSL resources. I then put these >> together and if I'm lucky something useful comes out. :) >> >> I think I'll figure things out eventually if I continue to crash around >> blindly as I have been, but if anyone can suggest some better starting >> points for GLSL use in OSG specifically, it would be much appreciated. :) >> >> Cheers, >> Garth >> ___ >> 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] INVALID_OPERATION with compressed textures with mipmaps in OSG 3.4.0
Hi Scott, I am experiencing this issue on OSX .. Can you submit a patch/fix to test it against the problematic models I have? Thanks a bunch! Nick On Thu, Sep 24, 2015 at 4:18 PM, Davis, Timothy S CTR comnavairsyscom < timothy.s.davis@navy.mil> wrote: > Robert > > I'd agree that I'm dealing with a driver bug. I'm just not sure what the > bug is. I think we are working in a underspecified area of OpenGL when > dealing with mipmap levels smaller than the compression block size. > However, I know that my driver generates 2x2 and 1x1 mipmaps for hardware > generated compressed textures and this would suggest that it should happily > work with these levels. > > I don't agree that it is unrelated to the OSX driver issue. Certainly the > drivers are different and the symptoms may be different. But they both > appear to touch the same question; what happens with mipmaps smaller than > the block size. I don't have access to an OSX machine however, so I cannot > investigate this claim further. > > I have not tried different driver/hardware/OS combinations. I'd agree > that this would be useful, but I'm somewhat limited in how far I can go > with this. > > I'd agree that a change to the core OSG is not warranted at this time. > The models that cause the problem are not distributable. I may continue to > try and create a model that has the issue as time permits. > > Scott > > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] INVALID_OPERATION with compressed textures with mipmaps in OSG 3.4.0
Robert I'd agree that I'm dealing with a driver bug. I'm just not sure what the bug is. I think we are working in a underspecified area of OpenGL when dealing with mipmap levels smaller than the compression block size. However, I know that my driver generates 2x2 and 1x1 mipmaps for hardware generated compressed textures and this would suggest that it should happily work with these levels. I don't agree that it is unrelated to the OSX driver issue. Certainly the drivers are different and the symptoms may be different. But they both appear to touch the same question; what happens with mipmaps smaller than the block size. I don't have access to an OSX machine however, so I cannot investigate this claim further. I have not tried different driver/hardware/OS combinations. I'd agree that this would be useful, but I'm somewhat limited in how far I can go with this. I'd agree that a change to the core OSG is not warranted at this time. The models that cause the problem are not distributable. I may continue to try and create a model that has the issue as time permits. Scott smime.p7s Description: S/MIME cryptographic signature ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] INVALID_OPERATION with compressed textures with mipmaps in OSG 3.4.0
smime.p7m Description: S/MIME encrypted message ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] INVALID_OPERATION with compressed textures with mipmaps in OSG 3.4.0
Sorry. It keeps trying to encrypt the message. Robert While continuing to build a model that results in the problem, I discovered something I didn't see before. The IVE model had an incorrect number of mipmap levels (it had 8) for a 32x32 texture. It makes sense that glTexStorage2D would generate INVALID_OPERATION in this case. Rebuilding the model from a source with uncompressed textures and recompressing the textures worked. The original model was converted with a much older version of OSG, pre OSG 3 for sure. So I was barking up the wrong tree:) That addresses my specific issue without needing a change to OSG 3.4.0. However, I still think it is worth trying for the OSX case. Trajce In osg/Texture.cpp, function applyTexImage2D(), find the line: useTexStorage &= sizedInternalFormat != 0; add the following after the line: if ( useTexStorage && compressed_image && numMipmapLevels > 2 ) { numMipmapLevels -= 2; } This is clearly not production quality as it assumes block size is 4 and complete mipmaps to 1x1. It should be enough to check the approach. You may have to set GL_TEXTURE_MAX_LEVEL if the driver thinks the texture is incomplete, but I didn't have that issue. Scott ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] INVALID_OPERATION with compressed textures with mipmaps in OSG 3.4.0
Hi Scott, Thanks for the follow up. Could you post the whole modified file, this way we can avoid any possible copy and past errors. Thanks, Robert. On 24 September 2015 at 20:13, Davis, Timothy S CTR comnavairsyscom < timothy.s.davis@navy.mil> wrote: > Sorry. It keeps trying to encrypt the message. > > Robert > > While continuing to build a model that results in the problem, I > discovered something I didn't see before. The IVE model had an incorrect > number of mipmap levels (it had 8) for a 32x32 texture. It makes sense > that glTexStorage2D would generate INVALID_OPERATION in this case. > Rebuilding the model from a source with uncompressed textures and > recompressing the textures worked. The original model was converted with a > much older version of OSG, pre OSG 3 for sure. > > So I was barking up the wrong tree:) > > That addresses my specific issue without needing a change to OSG 3.4.0. > However, I still think it is worth trying for the OSX case. > > > Trajce > > In osg/Texture.cpp, function applyTexImage2D(), find the line: > > useTexStorage &= sizedInternalFormat != 0; > > add the following after the line: > > if ( useTexStorage && compressed_image && numMipmapLevels > 2 ) > { > numMipmapLevels -= 2; > } > > This is clearly not production quality as it assumes block size is 4 and > complete mipmaps to 1x1. It should be enough to check the approach. You > may have to set GL_TEXTURE_MAX_LEVEL if the driver thinks the texture is > incomplete, but I didn't have that issue. > > Scott > ___ > 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] Modern GLSL and OSG
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24/09/15 00:19, Garth D wrote: > > Hi Christian, > > Many thanks for the interesting suggestion. :) > > My main development environment is Linux-based, with a secondary > virtualised Windows development environment. Due to the > visualization (VirtualBox) I don't believe I can do much in the way > of development with ANGLE due to its DX backend, at least with my > current setup. Um, wouldn't it be far easier to simply ask OSG to create an OpenGL 3.x/4.x core context instead? Then you don't have the legacy stuff available and don't need to bother with hacks like Angle. J. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iD8DBQFWBFOUn11XseNj94gRArP1AKDneqprlIWSFje9RJ6gGmgJuBCGFQCeN0hL I2nYYPPFemO/2jo40R7PH14= =V73u -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Modern GLSL and OSG
Hi Jan, On 25/09/15 05:18, Jan Ciger wrote:> -BEGIN PGP SIGNED MESSAGE- > On 24/09/15 00:19, Garth D wrote: >> Many thanks for the interesting suggestion. :) >> >> My main development environment is Linux-based, with a secondary >> virtualised Windows development environment. Due to the >> visualization (VirtualBox) I don't believe I can do much in the way >> of development with ANGLE due to its DX backend, at least with my >> current setup. > > Um, wouldn't it be far easier to simply ask OSG to create an OpenGL > 3.x/4.x core context instead? Then you don't have the legacy stuff > available and don't need to bother with hacks like Angle. Thankyou for the suggestion. :) I have to admit being unsure how to set the specific context at present. From what I've read, there'd need to be a glXCreateContextAttribsARB call somewhere to create the GL3 context under Linux- and there doesn't seem to be one. Skimming the source (I'm presently using OSG 3.2.1, but had a peek at 3.4.0) suggests that perhaps this support is only available on a Windows build. On the cmake side, OSG_GL3_AVAILABLE in my build is off. However, glVersion=4.4 appears in my log during a build. However, I am probably fine even if I am not grasping things entirely at this point. It is something I can experiment with later on, probably on my existing Windows build environment. Whether I experiment with ANGLE from there or not is something I can weigh up from that point. Thanks for the additional input. I also just noticed that my prior email used "visualization" rather than "virtualisation". Whoops. ;} I think I need to place a little less faith in spellcheck suggestions. I'm beginning to suspect that aiming for strict OpenGL 3+ or 4+ might not be the best thing for me to concentrate at the moment. I might be better off just using it where it helps and leaving a jump to "pure" modern GL until a later date. Cheers, Garth ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org