Re: [osg-users] Exporting OpenFlight Models
OpenSceneGraph. Sorry for the long message. - Dan > -Original Message- > From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On > Behalf Of Robert Osfield > Sent: Wednesday, June 27, 2018 4:08 PM > To: OpenSceneGraph Users > Subject: Re: [osg-users] Exporting OpenFlight Models > > Hi Dan, > > The PR looks like an acceptable level of hackiness to resolve this > problem so I've merged this. > > There is limit in how much we should go chasing our tails on this > suff, there is fixed function code all over the OSG so it'd be a > massive undertaking to try and find fall-backs for all these. I would > recommend that users don't use GLCORE unless they need to make it easy > port to GLES2/3 or to have to the latest GL features under OSX where > it's only possible with GLCORE. If you have to use GLCORE then I > think we just need to look at the real trouble points and resolve them > locally - this PR is an example where I think this is acceptable, but > it's not something I'd want to see spread across the whole OSG. > > If users really want a clean GL then that's Vulkan, it's what GLCORE > was attempting to achieve but falling along way short. So personally > I'd rather user just leave the legacy features of GL on when using the > OSG if there isn't any pressing need otherwise. > > Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Exporting OpenFlight Models
Hi Dan, The PR looks like an acceptable level of hackiness to resolve this problem so I've merged this. There is limit in how much we should go chasing our tails on this suff, there is fixed function code all over the OSG so it'd be a massive undertaking to try and find fall-backs for all these. I would recommend that users don't use GLCORE unless they need to make it easy port to GLES2/3 or to have to the latest GL features under OSX where it's only possible with GLCORE. If you have to use GLCORE then I think we just need to look at the real trouble points and resolve them locally - this PR is an example where I think this is acceptable, but it's not something I'd want to see spread across the whole OSG. If users really want a clean GL then that's Vulkan, it's what GLCORE was attempting to achieve but falling along way short. So personally I'd rather user just leave the legacy features of GL on when using the OSG if there isn't any pressing need otherwise. Robert. On Wed, 27 Jun 2018 at 18:09, Daniel Emminizer, Code 5773 wrote: > > Hi Robert, > > Tl;dr: I think I found a bug in OpenFlight's FltExportVisitor::isTextured() > when FFP is disabled. This email explains PR 568 more thoroughly. > > > > I am having problems saving out OpenFlight models and was hoping someone > could point out what I'm doing wrong. I think I might have identified a bug > but would like another set of eyes. > > I have an open source FLT that is textured that I'm trying to load, make a > minor edit to, and save out. My code is simple: > > osg::ref_ptr opts = new osgDB::Options; > opts->setOptionString("keepExternalReferences"); > osg::ref_ptr node = osgDB::readRefNodeFile(argv[1], > opts.get()); > > opts = new osgDB::Options; > bool succeeded = osgDB::writeNodeFile(*node, argv[2], opts.get()); > > It writes out the geometry, but never writes out the textures. I've spent > the last couple of hours tracking down why and I think I understand. I'm > using GL3 / GLCORE mode in OSG 3.6.2-rc2. I think it's important to note > this because I believe the bug is related to a FFP change with StateSet. > > The OpenFlight loader reads the image and the textures just fine, and > displays them. TexturePalette::readTexture() correctly calls > setTextureAttributeAndModes() with a valid texture. This ends up calling > osg::Texture::getModeUsage(), which is responsible for turning on > GL_TEXTURE_2D. > > Later on, the FltExportVisitor only respects a texture if GL_TEXTURE_2D is > enabled, via FltExportVisitor::isTextured(). > > But when OSG_GL_FIXED_FUNCTION_AVAILABLE is disabled due to GLCORE profile, > osg::Texture::getModeUsage() is not defined, so setTextureAttributeandModes() > never sets the mode on GL_TEXTURE_2D. > > > I think the fix is to update isTextured() to check for presence of a texture > when OSG_GL_FIXED_FUNCTION_AVAILABLE is not set. Does this seem reasonable? > > I have put up a PR to inspect at: > https://github.com/openscenegraph/OpenSceneGraph/pull/568 > > I do have workarounds on my side, so this isn't super critical. But I think > it will impact anyone who uses OSG with GLCORE mode who is trying to export > FLT files. > > Thanks, > > - Dan > > ___ > 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] Exporting OpenFlight Models
Hi Robert, Tl;dr: I think I found a bug in OpenFlight's FltExportVisitor::isTextured() when FFP is disabled. This email explains PR 568 more thoroughly. I am having problems saving out OpenFlight models and was hoping someone could point out what I'm doing wrong. I think I might have identified a bug but would like another set of eyes. I have an open source FLT that is textured that I'm trying to load, make a minor edit to, and save out. My code is simple: osg::ref_ptr opts = new osgDB::Options; opts->setOptionString("keepExternalReferences"); osg::ref_ptr node = osgDB::readRefNodeFile(argv[1], opts.get()); opts = new osgDB::Options; bool succeeded = osgDB::writeNodeFile(*node, argv[2], opts.get()); It writes out the geometry, but never writes out the textures. I've spent the last couple of hours tracking down why and I think I understand. I'm using GL3 / GLCORE mode in OSG 3.6.2-rc2. I think it's important to note this because I believe the bug is related to a FFP change with StateSet. The OpenFlight loader reads the image and the textures just fine, and displays them. TexturePalette::readTexture() correctly calls setTextureAttributeAndModes() with a valid texture. This ends up calling osg::Texture::getModeUsage(), which is responsible for turning on GL_TEXTURE_2D. Later on, the FltExportVisitor only respects a texture if GL_TEXTURE_2D is enabled, via FltExportVisitor::isTextured(). But when OSG_GL_FIXED_FUNCTION_AVAILABLE is disabled due to GLCORE profile, osg::Texture::getModeUsage() is not defined, so setTextureAttributeandModes() never sets the mode on GL_TEXTURE_2D. I think the fix is to update isTextured() to check for presence of a texture when OSG_GL_FIXED_FUNCTION_AVAILABLE is not set. Does this seem reasonable? I have put up a PR to inspect at: https://github.com/openscenegraph/OpenSceneGraph/pull/568 I do have workarounds on my side, so this isn't super critical. But I think it will impact anyone who uses OSG with GLCORE mode who is trying to export FLT files. Thanks, - Dan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org