OpenSceneGraph Forum Forum Index OpenSceneGraph Forum
Official forum which mirrors the existent OSG mailing lists. Messages posted here are forwarded to the mailing list and vice versa.
 
   FAQFAQ    SearchSearch    MemberlistMemberlist    RulesRules    UsergroupsUsergroups    RegisterRegister 
 Mail2Forum SettingsMail2Forum Settings  ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
   AlbumAlbum  OpenSceneGraph IRC ChatOpenSceneGraph IRC Chat   SmartFeedSmartFeed 

Exporting OpenFlight Models


 
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General
View previous topic :: View next topic  
Author Message
Daniel Emminizer, Code...
Guest





PostPosted: Wed Jun 27, 2018 5:02 pm    Post subject:
Exporting OpenFlight Models
Reply with quote

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<osgDB::Options> opts = new osgDB::Options;
opts->setOptionString("keepExternalReferences");
osg::ref_ptr<osg::Node> 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



------------------
Post generated by Mail2Forum
Back to top
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12148

PostPosted: Wed Jun 27, 2018 8:08 pm    Post subject:
Exporting OpenFlight Models
Reply with quote

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:
Quote:

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<osgDB::Options> opts = new osgDB::Options;
opts->setOptionString("keepExternalReferences");
osg::ref_ptr<osg::Node> 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




------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Daniel Emminizer, Code...
Guest





PostPosted: Thu Jun 28, 2018 10:56 am    Post subject:
Exporting OpenFlight Models
Reply with quote

Hi Robert,

Thanks for the merge! It helps.


A little explanation, if you have any interest. It's a little long, but I hope to explain why we're looking at Core Profile. I'd like to think it's for good reason.

I'm with you on the OSX issues. I think it's a shame about what's going on over there. I've seen your comments on the mailing list about their direction of development and I do agree with it.

However, core profile isn't a requirement only on OSX. We have a lot of users that run our software on a variety of hardware and platforms, supporting primarily Windows and RedHat systems, but also other Linux variants, on both real and virtual hardware. In a perfect world, everyone is using a reasonable graphics card (better than an etch-a-sketch) with good drivers. But what we've found is far from that.

Requirements wise, we're using osgEarth on top of OSG. They're invested pretty heavily in Interface Blocks ( https://www.khronos.org/opengl/wiki/Interface_Block_(GLSL) ), which require OpenGL 3.1 (GLSL 1.4), but there are also several shaders that start to push into GLSL 3.3 territory (GLSL 3.3). Ultimately we have a required minimum version of OpenGL in the 3.3 territory. That is no problem on most systems.

But we've run into more issues on three system configurations in particular:

* VMware systems running Windows using hardware acceleration
* Linux systems running Intel drivers (open source)
* Linux systems running Nvidia cards with open source drivers

In all three of these systems, we're seeing Mesa-based accelerated systems where core profile is supported somewhere between version GL 3.3 and GL 4.2. But compatibility profile support is extremely lacking. Some of these systems report "high" OpenGL versions of 2.0, with GLSL shader versions of 1.4 or 1.5 (note the official mismatch between OpenGL version and GLSL version). Others support only OpenGL 1.x, with GLSL versions as low as 1.2 in compatibility profile.

But they have full core profile support.

We're stuck with these systems because we don't get to configure the hardware on our users' systems. The third bullet in particular can be frustrating because the users have good hardware, but are unable (for a variety of reasons) to install the proprietary drivers that address these issues.


As I understand, some of the newer Mesa drivers are pushing towards better compatibility profile support. While that's great, we've seen a drastic difference in correctness of compatibility profile features across Nvidia to ATI to Intel drivers. Now there's Mesa drivers to consider too, and the various related variants. We've noticed fewer differences (bugs) as we migrate towards a more shader-heavy infrastructure and away from relying on compatibility profile, er, hacks.

However, even if Mesa were to support better compatibility mode drivers, that does not help us now, where we are stuck supporting RedHat 6 and RedHat 7 machines with the much older Mesa implementations.

Simply telling our users they must upgrade their hardware and drivers isn't a reasonable path forward; in many cases they cannot. We could try to back up to OpenGL 1.x and GLSL 1.2 to hit lowest common denominator, but that is extremely limiting, and would take a great deal of effort. Vulkan isn't an option for hopefully obvious reasons. Our remaining option to run on these systems is Core Profile.

Core Profile is supported on far more systems past 3.3 since Compatibility Profile is optional. It's messy comparatively and although I don't like it, I understand why Compatibility Profile support is more dicey for drivers to implement correctly (or at all in some cases)

I also understand your desire to want to support and push primarily Compatibility Profile. Mixing and matching the two is messy, and requiring a full new build of OpenSceneGraph to run on systems that only support Core Profile can be painful, at least on the Windows side, due to long build times (thanks MSVC) and poor system support for modern GL (e.g. glcorearb.h discussion in the last week). But that's our problem to deal with, not necessarily yours, and that's OK.

Anyways, I just wanted to point out that it's more than just OSX that needs Core Profile. If you're doing anything with more modern GLSL you'll also need to be looking at Core Profile, or you'll lock yourself away from a reasonable segment of a potential user base. And unlike Vulkan, support for Core Profile seems to be pretty reasonable across drivers for hardware that's been deployed in the last 8 years, at least in our particular user base.

I appreciate your receptiveness to patches that help with Core Profile support. The work you did on VAO and Text in particular have been invaluable. Thanks for your work on OpenSceneGraph. Sorry for the long message.

- Dan



Quote:
-----Original Message-----
From: osg-users [mailto:] On
Behalf Of Robert Osfield
Sent: Wednesday, June 27, 2018 4:08 PM
To: OpenSceneGraph Users
Subject: Re: 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.



------------------
Post generated by Mail2Forum
Back to top
Display posts from previous:   
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum

Similar Topics
Topic Author Forum Replies Posted
No new posts Unbounded growth in OpenFlight Reader... Daniel Emminizer, Code... General 6 Tue Jul 31, 2018 9:55 am View latest post
No new posts No specular maps, exporting from blen... Klemen Červ Plugins [osgPlugins] 1 Wed May 16, 2018 1:08 pm View latest post
No new posts Looking for FBX models to test out ou... robertosfield General 6 Fri Mar 09, 2018 4:24 pm View latest post
No new posts Exporting to 3D studio? bbjorn General 2 Fri Dec 08, 2017 9:49 am View latest post
No new posts Displaying the normals of your models SMesserschmidt General 2 Fri Dec 01, 2017 9:18 am View latest post


Board Security Anti Bot Question MOD - phpBB MOD against Spam Bots
Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP