Re: [osg-users] Using 'NodeTrackerManipulator' while holding camera steady

2018-05-10 Thread Andrew Cunningham
The osgmanipulators example is very clear. I should have checked the examples 
first!

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=73606#73606





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] OpenSceneGraph-3.6.1 release candidate 3 tagged

2018-05-10 Thread Alberto Luaces
Hi, I think this issue was commented somewhere else, but I couldn't find
it again: there is something broken with the cloning of osgDB::Options.
This minimal working example works fine with 3.4.x, but SIGSEVs with
3.6.1-rc3 and current master:

#include 

int main(){
auto globalopts = new osgDB::Options;
globalopts->setObjectCacheHint(osgDB::Options::CACHE_NODES);

// any.obj is not needed to get the crash.
auto *node = osgDB::readNodeFile("any.obj", globalopts);
}

-- 
Alberto

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Can a FrameBufferObject be shared by multiple cameras?

2018-05-10 Thread Julien Valentin
Hi Robert and Glenn,
I struggle against this problem too for a will now..
Wouldn't it be a good design to make FBO a Camera property and RenderStage take 
this one if exist for its stuff?

Cheers



robertosfield wrote:
> Hi Glenn,
> 
> If there is a way to share FBO's between osg::Camera I don't know of
> it off the top of my head.  You'd need to look at the
> src/osgUtil/RenderStage.cpp so see how it sets up the FBO's.  It's
> able to ruse it's own FBO on subsequent frames so there may be a way
> for forcing it to use an existing FBO.
> 
> Robert.
> 
> On 10 May 2018 at 14:02, Glenn Waldron <> wrote:
> 
> > Hi Robert,
> > 
> > I have a scenario that uses multiple RTT cameras. (The approach is similar
> > in concept to CSM - Cascading Shadow Maps - where you compose a texture
> > using multiple frustums). Each RTT camera renders to a different layer of a
> > Texture2DArray. This works great! However, it uses a lot more memory than I
> > was expecting.
> > 
> > I realized that each osg::Camera creates its own separate FBO, resulting in
> > a lot of extra memory usage. Since the cameras render sequentially, it makes
> > sense for all the RTT cameras to just re-use a single FBO. Is there any way
> > to make that happen in OSG? Any other suggestions?
> > 
> > Glenn Waldron / osgEarth
> > 
> > ___
> > osg-users mailing list
> > 
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> > 
> > 
> ___
> osg-users mailing list
> 
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> 
>  --
> Post generated by Mail2Forum



Twirling twirling twirling toward freedom

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=73604#73604





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Setting OpenGL and graphics card settings prgrammatically?

2018-05-10 Thread Wojciech Lewandowski
Hi,

AFAIK there is also a https://developer.nvidia.com/nvapi library.
Unfortunately I have no personal experience with this but I believe it can
be used to prgramatically override the setings usually set with NVidia
Control Panel.

Cheers,
Wojtek


2018-05-10 20:18 GMT+02:00 Daniel Emminizer, Code 5773 <
dan.emmini...@nrl.navy.mil>:

> Hi Chris,
>
> Not sure if this is what you’re looking for, but you can give a hint to
> the drivers by exporting variables in your code.  In my main.cpp I do
> something like:
>
> #ifdef WIN32
> extern "C" {
>
>   /// Declare this variable in public to enable the NVidia side of Optimus
> - http://developer.download.nvidia.com/devzone/devcenter/
> gamegraphics/files/OptimusRenderingPolicies.pdf
>   __declspec(dllexport) int NvOptimusEnablement = 1;
>
>   /// Declare this variable in public to enable the AMD side of AMD
> Switchable Graphics (13.35 driver or newer needed) -
> http://devgurus.amd.com/thread/169965
>   __declspec(dllexport) int AmdPowerXpressRequestHighPerformance = 1;
>
> }
> #endif /* WIN32 */
>
>
> We have not had a problem since.
>
>  - Dan
>
>
>
> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> Behalf Of Chris Hanson
> Sent: Thursday, May 10, 2018 2:15 PM
> To: OpenSceneGraph Users
> Subject: [osg-users] Setting OpenGL and graphics card settings
> prgrammatically?
>
>   As you are aware, drivers like the NVidia Windows driver have a variety
> of tuneable settings accessible through the vendor-specific setting
> application. Many times these accomplish things that can't be accessed
> through the standard OpenGL APIs or extensions.
>
>   Is there any way to force settings (like use of dedicated GPU versus
> integrated GPU) from application code via an API?
>
>   Basically, we're trying to avoid having to teach the untrained user how
> to mess with those settings when we know the preferred settings for the
> application.
>
>   Interested in NVidia and optionally AMD, Windows primarily but
> cross-platform APIs are welcomed.
>
>   I'm digging into this: https://docs.nvidia.com/gameworks/index.html#
> gameworkslibrary/coresdk/gsa_api.htm
>
>   to see if it does what I want, but welcome input from others.
>
>
>
> --
> Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com
> http://www.alphapixel.com/
> Training • Consulting • Contracting
> 3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4
> • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
> Legal/IP • Forensics • Imaging • UAVs • GIS • GPS •
> osgEarth • Terrain • Telemetry • Cryptography • LIDAR • Embedded • Mobile •
> iPhone/iPad/iOS • Android
> @alphapixel facebook.com/alphapixel (775) 623-PIXL [7495]
> ___
> 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] Setting OpenGL and graphics card settings prgrammatically?

2018-05-10 Thread Daniel Emminizer, Code 5773
Hi Chris,

Not sure if this is what you’re looking for, but you can give a hint to the 
drivers by exporting variables in your code.  In my main.cpp I do something 
like:

#ifdef WIN32
extern "C" {

  /// Declare this variable in public to enable the NVidia side of Optimus - 
http://developer.download.nvidia.com/devzone/devcenter/gamegraphics/files/OptimusRenderingPolicies.pdf
  __declspec(dllexport) int NvOptimusEnablement = 1;

  /// Declare this variable in public to enable the AMD side of AMD Switchable 
Graphics (13.35 driver or newer needed) - http://devgurus.amd.com/thread/169965
  __declspec(dllexport) int AmdPowerXpressRequestHighPerformance = 1;

}
#endif /* WIN32 */


We have not had a problem since.

 - Dan



From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of Chris Hanson
Sent: Thursday, May 10, 2018 2:15 PM
To: OpenSceneGraph Users
Subject: [osg-users] Setting OpenGL and graphics card settings prgrammatically?

  As you are aware, drivers like the NVidia Windows driver have a variety of 
tuneable settings accessible through the vendor-specific setting application. 
Many times these accomplish things that can't be accessed through the standard 
OpenGL APIs or extensions.

  Is there any way to force settings (like use of dedicated GPU versus 
integrated GPU) from application code via an API?

  Basically, we're trying to avoid having to teach the untrained user how to 
mess with those settings when we know the preferred settings for the 
application.

  Interested in NVidia and optionally AMD, Windows primarily but cross-platform 
APIs are welcomed.

  I'm digging into this: 
https://docs.nvidia.com/gameworks/index.html#gameworkslibrary/coresdk/gsa_api.htm

  to see if it does what I want, but welcome input from others.



-- 
Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com 
http://www.alphapixel.com/
Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • 
GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
Legal/IP • Forensics • Imaging • UAVs • GIS • GPS • osgEarth • Terrain • 
Telemetry • Cryptography • LIDAR • Embedded • Mobile • iPhone/iPad/iOS • Android
@alphapixel facebook.com/alphapixel (775) 623-PIXL [7495]
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


[osg-users] Setting OpenGL and graphics card settings prgrammatically?

2018-05-10 Thread Chris Hanson
  As you are aware, drivers like the NVidia Windows driver have a variety
of tuneable settings accessible through the vendor-specific setting
application. Many times these accomplish things that can't be accessed
through the standard OpenGL APIs or extensions.

  Is there any way to force settings (like use of dedicated GPU versus
integrated GPU) from application code via an API?

  Basically, we're trying to avoid having to teach the untrained user how
to mess with those settings when we know the preferred settings for the
application.

  Interested in NVidia and optionally AMD, Windows primarily but
cross-platform APIs are welcomed.

  I'm digging into this:
https://docs.nvidia.com/gameworks/index.html#gameworkslibrary/coresdk/gsa_api.htm

  to see if it does what I want, but welcome input from others.


-- 
Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com
http://www.alphapixel.com/
Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 •
GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
Legal/IP • Forensics • Imaging • UAVs • GIS • GPS •
osgEarth • Terrain • Telemetry • Cryptography • LIDAR • Embedded • Mobile •
iPhone/iPad/iOS • Android
@alphapixel  facebook.com/alphapixel (775)
623-PIXL [7495]
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] OpenSceneGraph-3.6.1 release candidate 3 tagged

2018-05-10 Thread Robert Osfield
On 10 May 2018 at 18:38, Bolstad, Mark  wrote:
> It looks like you hypothesis was correct, I must have fat-fingered a build 
> in-source as a clean checkout of the code fixed the issue.

I was able to recreate this on my system : I built OSG-3.4 in source
then 3.6 out of source and got a conflict.

As you suggested, moving the include for the build include directory
in front of the source include directory avoids to conflict so I have
checked this fix in.

Mixing in source and out of source builds still isn't a recommended
practice but at least we'll have caught one obscure way of breaking
the build so that others won't get tripped up :-)

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] OpenSceneGraph-3.6.1 release candidate 3 tagged

2018-05-10 Thread Bolstad, Mark
It looks like you hypothesis was correct, I must have fat-fingered a build 
in-source as a clean checkout of the code fixed the issue.

Thanks

Mark

> On May 10, 2018, at 1:30 PM, Bolstad, Mark  wrote:
> 
> I’m doing an out-of-source build. I’ll try and prune all the directories and 
> re-git the source.
> 
> Mark
> 
>> On May 10, 2018, at 12:18 PM, Robert Osfield  
>> wrote:
>> 
>> Hi Mark,
>> 
>> I am trying to work out why you have the build problem.  Is there a
>> chance you've done an in source build previously that set the
>> include/osg/GL prior the OSG_GL_CONTEXT was added, then you're out of
>> source build is not overriding this as the out of date in source
>> version of include/osg/GL is being picked up?
>> 
>> Robert.
>> 
>> On 10 May 2018 at 16:05, Bolstad, Mark  wrote:
>>> I’m getting a compile failure on OS X 10.12 with the latest version:
>>> 
>>> DisplaySettings.cpp:243:25: error:
>>> use of undeclared identifier 'OSG_GL_CONTEXT_VERSION'
>>>   _glContextVersion = OSG_GL_CONTEXT_VERSION;
>>>   ^
>>> 1 error generated.
>>> 
>>> I’ve traced this down to an order of includes issue. flags.cmake has the 
>>> order of -I  followed by -I . 
>>> The order needs to be reversed as it is in the build dir where 
>>> OSG_GL_CONTEXT is set.
>>> 
>>> Mark
>>> 
 On May 6, 2018, at 2:55 AM, Robert Osfield  
 wrote:
 
 Hi All,
 
 I have tagged 3.6.1-rc3 :
 
  
 https://github.com/openscenegraph/OpenSceneGraph/tree/OpenSceneGraph-3.6.1-rc3
 
 There a several bugs fixes since rc2, details below in ChangeLog and
 also a purge of use of std::auto_ptr<> as this is deprecated in C++11
 and will be removed in C++17.
 
 Please test and report success/failure.
 
 Thanks,
 Robert.
 
 
 -- ChangeLog since rc2
 
 Sat, 5 May 2018 15:47:28 +0100
 Author : Robert Osfield
 Restructed the handling of SCREEN_COORD scaling to better handle window 
 resizing
 
 Sat, 5 May 2018 12:31:00 +0100
 Author : Robert Osfield
 Added C++ specific path for calling std::map<>::erase() to avoid
 issues with std::map<>::erase implementation that invalidates
 iterators
 
 Sat, 5 May 2018 12:28:45 +0100
 Author : Robert Osfield
 Replaced std::auto_ptr<> usage as it's deprecated in C++11 and will be
 removed in C++17
 
 Fri, 4 May 2018 16:11:31 +0100
 Author : OpenSceneGraph git repository
 Merge pull request #545 from emminizer/fix-gl3-text-bad-modeText only
 applies GL_TEXTURE_2D modes when fixed function is availabl…
 
 Fri, 4 May 2018 06:44:13 -0400
 Author : Daniel Emminizer
 Text only applies GL_TEXTURE_2D modes when fixed function is
 available.  Prevents GL3 Core Profile console spam.
 
 Fri, 4 May 2018 10:54:02 +0100
 Author : Robert Osfield
 Added non const version of State::getActiveDisplaySettings()
 
 Fri, 4 May 2018 09:44:43 +0100
 Author : Robert Osfield
 Added check for null to prevent null entries getting into the cache
 
 Fri, 18 Nov 2016 14:56:05 +
 Author : Robert Osfield
 Added osg::MakeString class to make it easier to create std::string's
 using std::ostream style << usage.
 
 Fri, 4 May 2018 09:22:54 +0100
 Author : Robert Osfield
 Fixed null pointer warning
 
 Thu, 3 May 2018 12:56:08 +0200
 Author : Björn Blissing
 Check existence of path before reading imageWhen loading texture
 images inside the FBX plugin check that the path
 exists before trying to read the image. This is done to avoid
 unnecessary warnings inside the readRefImageFile function.
 ___
 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


Re: [osg-users] OpenSceneGraph-3.6.1 release candidate 3 tagged

2018-05-10 Thread Bolstad, Mark
I’m doing an out-of-source build. I’ll try and prune all the directories and 
re-git the source.

Mark

> On May 10, 2018, at 12:18 PM, Robert Osfield  wrote:
> 
> Hi Mark,
> 
> I am trying to work out why you have the build problem.  Is there a
> chance you've done an in source build previously that set the
> include/osg/GL prior the OSG_GL_CONTEXT was added, then you're out of
> source build is not overriding this as the out of date in source
> version of include/osg/GL is being picked up?
> 
> Robert.
> 
> On 10 May 2018 at 16:05, Bolstad, Mark  wrote:
>> I’m getting a compile failure on OS X 10.12 with the latest version:
>> 
>> DisplaySettings.cpp:243:25: error:
>>  use of undeclared identifier 'OSG_GL_CONTEXT_VERSION'
>>_glContextVersion = OSG_GL_CONTEXT_VERSION;
>>^
>> 1 error generated.
>> 
>> I’ve traced this down to an order of includes issue. flags.cmake has the 
>> order of -I  followed by -I . The 
>> order needs to be reversed as it is in the build dir where OSG_GL_CONTEXT is 
>> set.
>> 
>> Mark
>> 
>>> On May 6, 2018, at 2:55 AM, Robert Osfield  wrote:
>>> 
>>> Hi All,
>>> 
>>> I have tagged 3.6.1-rc3 :
>>> 
>>>   
>>> https://github.com/openscenegraph/OpenSceneGraph/tree/OpenSceneGraph-3.6.1-rc3
>>> 
>>> There a several bugs fixes since rc2, details below in ChangeLog and
>>> also a purge of use of std::auto_ptr<> as this is deprecated in C++11
>>> and will be removed in C++17.
>>> 
>>> Please test and report success/failure.
>>> 
>>> Thanks,
>>> Robert.
>>> 
>>> 
>>> -- ChangeLog since rc2
>>> 
>>> Sat, 5 May 2018 15:47:28 +0100
>>> Author : Robert Osfield
>>> Restructed the handling of SCREEN_COORD scaling to better handle window 
>>> resizing
>>> 
>>> Sat, 5 May 2018 12:31:00 +0100
>>> Author : Robert Osfield
>>> Added C++ specific path for calling std::map<>::erase() to avoid
>>> issues with std::map<>::erase implementation that invalidates
>>> iterators
>>> 
>>> Sat, 5 May 2018 12:28:45 +0100
>>> Author : Robert Osfield
>>> Replaced std::auto_ptr<> usage as it's deprecated in C++11 and will be
>>> removed in C++17
>>> 
>>> Fri, 4 May 2018 16:11:31 +0100
>>> Author : OpenSceneGraph git repository
>>> Merge pull request #545 from emminizer/fix-gl3-text-bad-modeText only
>>> applies GL_TEXTURE_2D modes when fixed function is availabl…
>>> 
>>> Fri, 4 May 2018 06:44:13 -0400
>>> Author : Daniel Emminizer
>>> Text only applies GL_TEXTURE_2D modes when fixed function is
>>> available.  Prevents GL3 Core Profile console spam.
>>> 
>>> Fri, 4 May 2018 10:54:02 +0100
>>> Author : Robert Osfield
>>> Added non const version of State::getActiveDisplaySettings()
>>> 
>>> Fri, 4 May 2018 09:44:43 +0100
>>> Author : Robert Osfield
>>> Added check for null to prevent null entries getting into the cache
>>> 
>>> Fri, 18 Nov 2016 14:56:05 +
>>> Author : Robert Osfield
>>> Added osg::MakeString class to make it easier to create std::string's
>>> using std::ostream style << usage.
>>> 
>>> Fri, 4 May 2018 09:22:54 +0100
>>> Author : Robert Osfield
>>> Fixed null pointer warning
>>> 
>>> Thu, 3 May 2018 12:56:08 +0200
>>> Author : Björn Blissing
>>> Check existence of path before reading imageWhen loading texture
>>> images inside the FBX plugin check that the path
>>> exists before trying to read the image. This is done to avoid
>>> unnecessary warnings inside the readRefImageFile function.
>>> ___
>>> 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


Re: [osg-users] OpenSceneGraph-3.6.1 release candidate 3 tagged

2018-05-10 Thread Daniel Emminizer, Code 5773
Hi Robert,

I got my build on Linux done.  I test both GLCORE configuration and non-GLCORE 
configuration on OpenSceneGraph-3.6.

I am seeing the error in all 3 configurations:

1) Linux Ubuntu 14.04; default OSG 3.6 branch build (GL compatibility mode); 
NVidia Quadro K1000M GL 4.5, 384.11 driver; Ubuntu 14.04

2) Linux Ubuntu 14.04; GLCORE OSG 3.6 branch build; NVidia Quadro K1000M GL 
3.3, 384.11 driver

3) Windows 10; GLCORE OSG 3.6 branch build; NVidia NVS 510, 388.19 driver


Can you just please reconfirm that when you run on OSG 3.6 branch build, and 
run "./osgtext --size2" (or resize the view to be short), that the text is all 
readable and you can clearly see "330  000  030  060" in the display with no 
significant overlap?

Thanks,

 - Dan


-Original Message-
From: Daniel Emminizer, Code 5773 
Sent: Thursday, May 10, 2018 11:42 AM
To: 'OpenSceneGraph Users'
Subject: RE: [osg-users] OpenSceneGraph-3.6.1 release candidate 3 tagged

Hi Robert,

Thanks for trying the example.  I'm perplexed why it's OK for you but not me.  
In case you're curious, I'm attaching the screenshots of the output.

I should note again that I am running with OPENGL_PROFILE="GLCORE" / GL3 mode.  
Would that make a difference?


I will rebuild on Linux and test there; I have not done that yet.  This doesn't 
seem like the kind of thing that would matter Windows vs Linux, but who knows.  
I will update this thread once I can check Linux.

- Dan


-Original Message-
From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of Robert Osfield
Sent: Thursday, May 10, 2018 11:32 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] OpenSceneGraph-3.6.1 release candidate 3 tagged

Hi Dan,

I finally had a chance to look at the your example.  It works the same under 
3.6 branch and 3.4 branch for me, I don't ever see any issues with the texture 
become skewed regardless of the size of the window.

Robert.

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] OpenSceneGraph-3.6.1 release candidate 3 tagged

2018-05-10 Thread Robert Osfield
Hi Mark,

I am trying to work out why you have the build problem.  Is there a
chance you've done an in source build previously that set the
include/osg/GL prior the OSG_GL_CONTEXT was added, then you're out of
source build is not overriding this as the out of date in source
version of include/osg/GL is being picked up?

Robert.

On 10 May 2018 at 16:05, Bolstad, Mark  wrote:
> I’m getting a compile failure on OS X 10.12 with the latest version:
>
> DisplaySettings.cpp:243:25: error:
>   use of undeclared identifier 'OSG_GL_CONTEXT_VERSION'
> _glContextVersion = OSG_GL_CONTEXT_VERSION;
> ^
> 1 error generated.
>
> I’ve traced this down to an order of includes issue. flags.cmake has the 
> order of -I  followed by -I . The 
> order needs to be reversed as it is in the build dir where OSG_GL_CONTEXT is 
> set.
>
> Mark
>
>> On May 6, 2018, at 2:55 AM, Robert Osfield  wrote:
>>
>> Hi All,
>>
>> I have tagged 3.6.1-rc3 :
>>
>>
>> https://github.com/openscenegraph/OpenSceneGraph/tree/OpenSceneGraph-3.6.1-rc3
>>
>> There a several bugs fixes since rc2, details below in ChangeLog and
>> also a purge of use of std::auto_ptr<> as this is deprecated in C++11
>> and will be removed in C++17.
>>
>> Please test and report success/failure.
>>
>> Thanks,
>> Robert.
>>
>>
>> -- ChangeLog since rc2
>>
>> Sat, 5 May 2018 15:47:28 +0100
>> Author : Robert Osfield
>> Restructed the handling of SCREEN_COORD scaling to better handle window 
>> resizing
>>
>> Sat, 5 May 2018 12:31:00 +0100
>> Author : Robert Osfield
>> Added C++ specific path for calling std::map<>::erase() to avoid
>> issues with std::map<>::erase implementation that invalidates
>> iterators
>>
>> Sat, 5 May 2018 12:28:45 +0100
>> Author : Robert Osfield
>> Replaced std::auto_ptr<> usage as it's deprecated in C++11 and will be
>> removed in C++17
>>
>> Fri, 4 May 2018 16:11:31 +0100
>> Author : OpenSceneGraph git repository
>> Merge pull request #545 from emminizer/fix-gl3-text-bad-modeText only
>> applies GL_TEXTURE_2D modes when fixed function is availabl…
>>
>> Fri, 4 May 2018 06:44:13 -0400
>> Author : Daniel Emminizer
>> Text only applies GL_TEXTURE_2D modes when fixed function is
>> available.  Prevents GL3 Core Profile console spam.
>>
>> Fri, 4 May 2018 10:54:02 +0100
>> Author : Robert Osfield
>> Added non const version of State::getActiveDisplaySettings()
>>
>> Fri, 4 May 2018 09:44:43 +0100
>> Author : Robert Osfield
>> Added check for null to prevent null entries getting into the cache
>>
>> Fri, 18 Nov 2016 14:56:05 +
>> Author : Robert Osfield
>> Added osg::MakeString class to make it easier to create std::string's
>> using std::ostream style << usage.
>>
>> Fri, 4 May 2018 09:22:54 +0100
>> Author : Robert Osfield
>> Fixed null pointer warning
>>
>> Thu, 3 May 2018 12:56:08 +0200
>> Author : Björn Blissing
>> Check existence of path before reading imageWhen loading texture
>> images inside the FBX plugin check that the path
>> exists before trying to read the image. This is done to avoid
>> unnecessary warnings inside the readRefImageFile function.
>> ___
>> 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


Re: [osg-users] OpenSceneGraph-3.6.1 release candidate 3 tagged

2018-05-10 Thread Daniel Emminizer, Code 5773
Hi Robert,

Thanks for trying the example.  I'm perplexed why it's OK for you but not me.  
In case you're curious, I'm attaching the screenshots of the output.

I should note again that I am running with OPENGL_PROFILE="GLCORE" / GL3 mode.  
Would that make a difference?


I will rebuild on Linux and test there; I have not done that yet.  This doesn't 
seem like the kind of thing that would matter Windows vs Linux, but who knows.  
I will update this thread once I can check Linux.

- Dan


-Original Message-
From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of Robert Osfield
Sent: Thursday, May 10, 2018 11:32 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] OpenSceneGraph-3.6.1 release candidate 3 tagged

Hi Dan,

I finally had a chance to look at the your example.  It works the same
under 3.6 branch and 3.4 branch for me, I don't ever see any issues
with the texture become skewed regardless of the size of the window.

Robert.

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] OpenSceneGraph-3.6.1 release candidate 3 tagged

2018-05-10 Thread Robert Osfield
Hi Mark,

Are you building out of source?

Robert.

On 10 May 2018 at 16:27, Bolstad, Mark  wrote:
> Mostly it’s just configuring cmake followed by make. Turn on build examples,
> delete the paths for inventor and sdl/sdl2 as I don’t need them and they
> typically cause compile problems due to age. Configure, Configure,
> Configure, Generate, Make.
>
> I’ve attached the CMakeCache file.
>
> Also, I just noticed that I’m on HEAD and not the rc3 candidate. Do you want
> me to switch and test there?
>
> Mark
>
>
>> On May 10, 2018, at 11:08 AM, Robert Osfield 
>> wrote:
>>
>> Hi Mark,
>>
>> Could you let me know the build steps you took to see this eror i.e.
>> the command line steps.  I want to see if I can recreate the build
>> issue under Linux.
>>
>> Robert.
>>
>> On 10 May 2018 at 16:05, Bolstad, Mark  wrote:
>>> I’m getting a compile failure on OS X 10.12 with the latest version:
>>>
>>> DisplaySettings.cpp:243:25: error:
>>>  use of undeclared identifier 'OSG_GL_CONTEXT_VERSION'
>>>_glContextVersion = OSG_GL_CONTEXT_VERSION;
>>>^
>>> 1 error generated.
>>>
>>> I’ve traced this down to an order of includes issue. flags.cmake has the
>>> order of -I  followed by -I . The
>>> order needs to be reversed as it is in the build dir where OSG_GL_CONTEXT is
>>> set.
>>>
>>> Mark
>>>
 On May 6, 2018, at 2:55 AM, Robert Osfield 
 wrote:

 Hi All,

 I have tagged 3.6.1-rc3 :


 https://github.com/openscenegraph/OpenSceneGraph/tree/OpenSceneGraph-3.6.1-rc3

 There a several bugs fixes since rc2, details below in ChangeLog and
 also a purge of use of std::auto_ptr<> as this is deprecated in C++11
 and will be removed in C++17.

 Please test and report success/failure.

 Thanks,
 Robert.


 -- ChangeLog since rc2

 Sat, 5 May 2018 15:47:28 +0100
 Author : Robert Osfield
 Restructed the handling of SCREEN_COORD scaling to better handle window
 resizing

 Sat, 5 May 2018 12:31:00 +0100
 Author : Robert Osfield
 Added C++ specific path for calling std::map<>::erase() to avoid
 issues with std::map<>::erase implementation that invalidates
 iterators

 Sat, 5 May 2018 12:28:45 +0100
 Author : Robert Osfield
 Replaced std::auto_ptr<> usage as it's deprecated in C++11 and will be
 removed in C++17

 Fri, 4 May 2018 16:11:31 +0100
 Author : OpenSceneGraph git repository
 Merge pull request #545 from emminizer/fix-gl3-text-bad-modeText only
 applies GL_TEXTURE_2D modes when fixed function is availabl…

 Fri, 4 May 2018 06:44:13 -0400
 Author : Daniel Emminizer
 Text only applies GL_TEXTURE_2D modes when fixed function is
 available.  Prevents GL3 Core Profile console spam.

 Fri, 4 May 2018 10:54:02 +0100
 Author : Robert Osfield
 Added non const version of State::getActiveDisplaySettings()

 Fri, 4 May 2018 09:44:43 +0100
 Author : Robert Osfield
 Added check for null to prevent null entries getting into the cache

 Fri, 18 Nov 2016 14:56:05 +
 Author : Robert Osfield
 Added osg::MakeString class to make it easier to create std::string's
 using std::ostream style << usage.

 Fri, 4 May 2018 09:22:54 +0100
 Author : Robert Osfield
 Fixed null pointer warning

 Thu, 3 May 2018 12:56:08 +0200
 Author : Björn Blissing
 Check existence of path before reading imageWhen loading texture
 images inside the FBX plugin check that the path
 exists before trying to read the image. This is done to avoid
 unnecessary warnings inside the readRefImageFile function.
 ___
 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


Re: [osg-users] OpenSceneGraph-3.6.1 release candidate 3 tagged

2018-05-10 Thread Robert Osfield
Hi Dan,

I finally had a chance to look at the your example.  It works the same
under 3.6 branch and 3.4 branch for me, I don't ever see any issues
with the texture become skewed regardless of the size of the window.

Robert.

On 7 May 2018 at 12:15, Daniel Emminizer, Code 5773
 wrote:
> Hi Robert,
>
> Attached is an osgtext.cpp that demonstrates the problem I'm seeing in our 
> application with text in SCREEN_COORDS scaling improperly.
>
> In this particular app, we're using a FIXED projection matrix mapping (-1,-1) 
> to the lower-left corner, and (+1,+1) to the upper-right corner (ortho 2D).  
> We have a layout system in this application that uses matrix transforms to 
> position items in the layout.
>
> In this section, the text is nested in two matrix transforms.  These 
> transforms update values as a result of window resizes.  I omitted this code 
> because it did not seem particularly relevant, and it is not required to 
> reproduce the behavior.  I got the current values for both matrices by saving 
> the scene to an .osg file and extracting the subgraph.
>
> What you're seeing in this app is 4 text labels that form the text part of a 
> 2D "compass", serving as a set of labels for a plot's X-axis.  Obviously this 
> is just a subset of the whole scene.
>
>
> When you resize the window with 3.6.1-rc2, you'll notice that the text skews 
> significantly.  If you run the same app in OSG 3.4.1, the text looks correct 
> regardless of window size.
>
> Side discovery -- setting the backdrop had a weird impact on text placement.  
> Not entirely sure that I understand why.  It doesn't really impact us in our 
> application, but I thought I'd mention it just in case it's important.
>
>  - 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


Re: [osg-users] OpenSceneGraph-3.6.1 release candidate 3 tagged

2018-05-10 Thread Robert Osfield
Hi Mark,

Could you let me know the build steps you took to see this eror i.e.
the command line steps.  I want to see if I can recreate the build
issue under Linux.

Robert.

On 10 May 2018 at 16:05, Bolstad, Mark  wrote:
> I’m getting a compile failure on OS X 10.12 with the latest version:
>
> DisplaySettings.cpp:243:25: error:
>   use of undeclared identifier 'OSG_GL_CONTEXT_VERSION'
> _glContextVersion = OSG_GL_CONTEXT_VERSION;
> ^
> 1 error generated.
>
> I’ve traced this down to an order of includes issue. flags.cmake has the 
> order of -I  followed by -I . The 
> order needs to be reversed as it is in the build dir where OSG_GL_CONTEXT is 
> set.
>
> Mark
>
>> On May 6, 2018, at 2:55 AM, Robert Osfield  wrote:
>>
>> Hi All,
>>
>> I have tagged 3.6.1-rc3 :
>>
>>
>> https://github.com/openscenegraph/OpenSceneGraph/tree/OpenSceneGraph-3.6.1-rc3
>>
>> There a several bugs fixes since rc2, details below in ChangeLog and
>> also a purge of use of std::auto_ptr<> as this is deprecated in C++11
>> and will be removed in C++17.
>>
>> Please test and report success/failure.
>>
>> Thanks,
>> Robert.
>>
>>
>> -- ChangeLog since rc2
>>
>> Sat, 5 May 2018 15:47:28 +0100
>> Author : Robert Osfield
>> Restructed the handling of SCREEN_COORD scaling to better handle window 
>> resizing
>>
>> Sat, 5 May 2018 12:31:00 +0100
>> Author : Robert Osfield
>> Added C++ specific path for calling std::map<>::erase() to avoid
>> issues with std::map<>::erase implementation that invalidates
>> iterators
>>
>> Sat, 5 May 2018 12:28:45 +0100
>> Author : Robert Osfield
>> Replaced std::auto_ptr<> usage as it's deprecated in C++11 and will be
>> removed in C++17
>>
>> Fri, 4 May 2018 16:11:31 +0100
>> Author : OpenSceneGraph git repository
>> Merge pull request #545 from emminizer/fix-gl3-text-bad-modeText only
>> applies GL_TEXTURE_2D modes when fixed function is availabl…
>>
>> Fri, 4 May 2018 06:44:13 -0400
>> Author : Daniel Emminizer
>> Text only applies GL_TEXTURE_2D modes when fixed function is
>> available.  Prevents GL3 Core Profile console spam.
>>
>> Fri, 4 May 2018 10:54:02 +0100
>> Author : Robert Osfield
>> Added non const version of State::getActiveDisplaySettings()
>>
>> Fri, 4 May 2018 09:44:43 +0100
>> Author : Robert Osfield
>> Added check for null to prevent null entries getting into the cache
>>
>> Fri, 18 Nov 2016 14:56:05 +
>> Author : Robert Osfield
>> Added osg::MakeString class to make it easier to create std::string's
>> using std::ostream style << usage.
>>
>> Fri, 4 May 2018 09:22:54 +0100
>> Author : Robert Osfield
>> Fixed null pointer warning
>>
>> Thu, 3 May 2018 12:56:08 +0200
>> Author : Björn Blissing
>> Check existence of path before reading imageWhen loading texture
>> images inside the FBX plugin check that the path
>> exists before trying to read the image. This is done to avoid
>> unnecessary warnings inside the readRefImageFile function.
>> ___
>> 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


Re: [osg-users] OpenSceneGraph-3.6.1 release candidate 3 tagged

2018-05-10 Thread Bolstad, Mark
I’m getting a compile failure on OS X 10.12 with the latest version:

DisplaySettings.cpp:243:25: error:
  use of undeclared identifier 'OSG_GL_CONTEXT_VERSION'
_glContextVersion = OSG_GL_CONTEXT_VERSION;
^
1 error generated.

I’ve traced this down to an order of includes issue. flags.cmake has the order 
of -I  followed by -I . The order 
needs to be reversed as it is in the build dir where OSG_GL_CONTEXT is set.

Mark

> On May 6, 2018, at 2:55 AM, Robert Osfield  wrote:
> 
> Hi All,
> 
> I have tagged 3.6.1-rc3 :
> 
>
> https://github.com/openscenegraph/OpenSceneGraph/tree/OpenSceneGraph-3.6.1-rc3
> 
> There a several bugs fixes since rc2, details below in ChangeLog and
> also a purge of use of std::auto_ptr<> as this is deprecated in C++11
> and will be removed in C++17.
> 
> Please test and report success/failure.
> 
> Thanks,
> Robert.
> 
> 
> -- ChangeLog since rc2
> 
> Sat, 5 May 2018 15:47:28 +0100
> Author : Robert Osfield
> Restructed the handling of SCREEN_COORD scaling to better handle window 
> resizing
> 
> Sat, 5 May 2018 12:31:00 +0100
> Author : Robert Osfield
> Added C++ specific path for calling std::map<>::erase() to avoid
> issues with std::map<>::erase implementation that invalidates
> iterators
> 
> Sat, 5 May 2018 12:28:45 +0100
> Author : Robert Osfield
> Replaced std::auto_ptr<> usage as it's deprecated in C++11 and will be
> removed in C++17
> 
> Fri, 4 May 2018 16:11:31 +0100
> Author : OpenSceneGraph git repository
> Merge pull request #545 from emminizer/fix-gl3-text-bad-modeText only
> applies GL_TEXTURE_2D modes when fixed function is availabl…
> 
> Fri, 4 May 2018 06:44:13 -0400
> Author : Daniel Emminizer
> Text only applies GL_TEXTURE_2D modes when fixed function is
> available.  Prevents GL3 Core Profile console spam.
> 
> Fri, 4 May 2018 10:54:02 +0100
> Author : Robert Osfield
> Added non const version of State::getActiveDisplaySettings()
> 
> Fri, 4 May 2018 09:44:43 +0100
> Author : Robert Osfield
> Added check for null to prevent null entries getting into the cache
> 
> Fri, 18 Nov 2016 14:56:05 +
> Author : Robert Osfield
> Added osg::MakeString class to make it easier to create std::string's
> using std::ostream style << usage.
> 
> Fri, 4 May 2018 09:22:54 +0100
> Author : Robert Osfield
> Fixed null pointer warning
> 
> Thu, 3 May 2018 12:56:08 +0200
> Author : Björn Blissing
> Check existence of path before reading imageWhen loading texture
> images inside the FBX plugin check that the path
> exists before trying to read the image. This is done to avoid
> unnecessary warnings inside the readRefImageFile function.
> ___
> 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] Can a FrameBufferObject be shared by multiple cameras?

2018-05-10 Thread Robert Osfield
Hi Glenn,

If there is a way to share FBO's between osg::Camera I don't know of
it off the top of my head.  You'd need to look at the
src/osgUtil/RenderStage.cpp so see how it sets up the FBO's.  It's
able to ruse it's own FBO on subsequent frames so there may be a way
for forcing it to use an existing FBO.

Robert.

On 10 May 2018 at 14:02, Glenn Waldron  wrote:
> Hi Robert,
>
> I have a scenario that uses multiple RTT cameras. (The approach is similar
> in concept to CSM - Cascading Shadow Maps - where you compose a texture
> using multiple frustums). Each RTT camera renders to a different layer of a
> Texture2DArray. This works great! However, it uses a lot more memory than I
> was expecting.
>
> I realized that each osg::Camera creates its own separate FBO, resulting in
> a lot of extra memory usage. Since the cameras render sequentially, it makes
> sense for all the RTT cameras to just re-use a single FBO. Is there any way
> to make that happen in OSG? Any other suggestions?
>
> Glenn Waldron / osgEarth
>
> ___
> 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] EXTERNAL: Re: FBO setup not working..

2018-05-10 Thread Robert Osfield
On 10 May 2018 at 13:48, Rowley, Marlin R  wrote:

> Robert,
>
>
>
> Could you do me a favor and see if the example in the OpenSceneGraph 3
> Cookbook, page 242 works on your computer?
>

I don't have the Cookbook.  And I'm really busy right now so now time to go
chasing obscure driver issues.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


[osg-users] Can a FrameBufferObject be shared by multiple cameras?

2018-05-10 Thread Glenn Waldron
Hi Robert,

I have a scenario that uses multiple RTT cameras. (The approach is similar
in concept to CSM - Cascading Shadow Maps - where you compose a texture
using multiple frustums). Each RTT camera renders to a different layer of a
Texture2DArray. This works great! However, it uses a lot more memory than I
was expecting.

I realized that each osg::Camera creates its own separate FBO, resulting in
a lot of extra memory usage. Since the cameras render sequentially, it
makes sense for all the RTT cameras to just re-use a single FBO. Is there
any way to make that happen in OSG? Any other suggestions?

Glenn Waldron / osgEarth
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] EXTERNAL: Re: FBO setup not working..

2018-05-10 Thread Rowley, Marlin R
Robert,

Could you do me a favor and see if the example in the OpenSceneGraph 3 
Cookbook, page 242 works on your computer?  I was originally wanting to test 
with that but when I get totally white on the left side of the screen (when it 
should have been showing the depth buffer), I went to trying the 
osgpackeddepthstencil.cpp file.

I just want to make sure I’m overlooking something simple.

-M


Marlin Rowley
Software Engineer, Staff
[cid:image002.jpg@01D39374.DEC5A2E0]
Missiles and Fire Control
972-603-1931 (office)
214-926-0622 (mobile)
marlin.r.row...@lmco.com

From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of Robert Osfield
Sent: Thursday, May 10, 2018 2:58 AM
To: OpenSceneGraph Users 
Subject: EXTERNAL: Re: [osg-users] FBO setup not working..

Hi Marlin,

On 9 May 2018 at 18:46, Rowley, Marlin R 
> wrote:
Hello,

I get the following error when running the example: osgpackeddepthstencil.cpp

RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd

I have a AMD Radeon RX580.

I have just tested osgpackeddepthstencil on my Linux/NVidia system and it runs 
without errors.

Camera::attach() is the mechanism that the OSG uses to tell the OSG's rendering 
back-end how to set up FBO's, there isn't another route for this.  Perhaps it's 
an issue with the enum values used with the attach calls, perhaps 
GL_STENCIL_INDEX8_EXT isn't supported by your system.
With driver/hardware specific issues like this having feedback from a range of 
users is helpful as it can give us an idea on what OS/drivers/hardware hard 
problems, this then gives clues as to what direction to look into.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Using 'NodeTrackerManipulator' while holding camera steady

2018-05-10 Thread Robert Osfield
On 9 May 2018 at 23:57, Andrew Cunningham  wrote:
> Clearly I **am** barking up the wrong tree and should be looking at 
> osgManipulators :)

Woof Woof :-)

Are you happy with trying out osgManipulator?  The osgmanipulators
example is the best place to start when learning about it.

Cheers,
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] FBO setup not working..

2018-05-10 Thread Robert Osfield
Hi Marlin,

On 9 May 2018 at 18:46, Rowley, Marlin R  wrote:

> Hello,
>
>
>
> I get the following error when running the example:
> osgpackeddepthstencil.cpp
>
>
>
> *RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd*
>
>
>
> I have a AMD Radeon RX580.
>

I have just tested osgpackeddepthstencil on my Linux/NVidia system and it
runs without errors.

Camera::attach() is the mechanism that the OSG uses to tell the OSG's
rendering back-end how to set up FBO's, there isn't another route for
this.  Perhaps it's an issue with the enum values used with the attach
calls, perhaps GL_STENCIL_INDEX8_EXT isn't supported by your system.

With driver/hardware specific issues like this having feedback from a range
of users is helpful as it can give us an idea on what OS/drivers/hardware
hard problems, this then gives clues as to what direction to look into.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org