Re: [osg-users] C++11 for next stable release of OpenSceneGraph?

[Björn Blissing]

I am also in total support to move to C++11.

I am even inclined to favor moving all the way to C++17, which includes some 
nice features (my favorite being allowing initializers in if and switch 
statements). And even Visual Studio is somewhat conformant:
https://blogs.msdn.microsoft.com/vcblog/2018/05/07/announcing-msvc-conforms-to-the-c-standard/

Regards
Björn

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





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

Re: [osg-users] C++11 for next stable release of OpenSceneGraph?

[Chris Hanson]

I'm totally in support of moving to C++11.



On Mon, Jun 11, 2018 at 2:14 AM Alberto Luaces  wrote:

> Robert Osfield writes:
>
> > I would suggest that OpenSceneGraph-3.x series remain compilable
> > without needing C++11.  So 3.6.x for instance we'll make bug fixes etc
> > but never change the compiler requirements.
>
> Having that fallback (3.x) for the tiny amount of systems that don't
> support C++11 is a sensible approach, and I would even dare to say
> extra-conservative, given the support of C+11 among current compilers.
>
> --
> Alberto
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>


-- 
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] OsgMovie ffmpeg and audio (SDL2) - Audio seems to make video slower. Audio has hiccoughing

[Voerman, L.]

Hi Andrea,
To display the usage of the cpu cores in the task viewer you need to right
click the cpu graph, select "Change graph to" and select "Logical
Processors".
>From "overall usage" we cannot see if that's one core at 100% and the rest
near zero or something else.
Laurens.

On Mon, Jun 11, 2018 at 5:33 PM, Andrea Martini 
wrote:

> Hi Voerman,
> thank you for your fast replay.
> I looked at post you suggested, and i downloaded (and compiled) the
> FFmpegDecoderVideo.zip
> Unfortunally, i get the same result.
> Following i attached some graphical information about stats and CPU usage.
>
> Cheers,
> Andrea
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=74038#74038
>
>
>
>
> ___
> 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] VBO Bug with 3.6.1 and Normal Arrays

[Daniel Emminizer, Code 5773]

Hi Robert,

I have committed and pushed my solution at 
https://github.com/emminizer/OpenSceneGraph/commit/4d2601e05e96aa

It's on my branch 
https://github.com/emminizer/OpenSceneGraph/tree/crash-vbo-array-bindings

As Laurens pointed out earlier, it may not catch all use cases, including some 
important ones.  I'm (mildly) confident that the solution is to detect the 
change in array bindings and call addVertexBuffObjectIfRequired() -- but I just 
don't know the right insertion point in the code to do this.

I hope this helps in some way.

 - Dan


> -Original Message-
> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> Behalf Of Robert Osfield
> Sent: Monday, June 11, 2018 10:48 AM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
> 
> Hi Daniel,
> 
> Thanks for looking further into this.  I did some investigation
> originally but didn't get to the bottom of the issue.  FYI, the
> support for Vertex Array Objects is what instigated these changes to
> way that VBO's had to be managed.  Essentially all osg::Array with per
> vertex bindings now need have a a VertexBufferObject assigned.
> 
> If you have made a commit for this fix against your own git clone of
> the OSG just pointing me at this commit should help me understand what
> is going on better.
> 
> Cheers,
> Robert.
> On Mon, 11 Jun 2018 at 14:44, Daniel Emminizer, Code 5773
>  wrote:
> >
> > Hi Robert,
> >
> > I am back from travel and looking at this again.  Didn't get a response on 
> > last
> set of questions about this crash.  Sorry to distract from the Vulkan work -- 
> it
> sounds interesting, and I'm watching your progress there excitedly.
> >
> >
> > Core problem seems to be that Array::setBinding() can change after
> Geometry::set*Array().  Geometry::set*Array() is responsible for calling
> addVertexBufferObjectIfRequired(), and doesn't have enough information
> to correctly do so.
> >
> > During the draw traversal, as a result, the Array::getBinding() flag does 
> > not
> match the VBO state in Geometry.
> >
> > One solution is to create the VBO as needed (using
> addVertexBufferObjectIfRequired) sometime between the start of cull
> phase and before the Geometry::drawImplementation().  But
> drawImplementation() is const, and not a place where this can happen.
> >
> >
> > Another possible solution that might help is to modify
> Geometry::setPrimitiveSet() and addPrimitiveSet() to call
> addVertexBufferObjectIfRequired() on the various arrays.  I prototyped this
> solution locally and it resolved the issue in the FLT loader.  I know it's not
> perfect, but most places I've seen that would trigger this bug have defined
> an array binding by the time a primitive set is added.
> >
> > Should I submit a PR for this approach?  It keeps binary compatibility and 
> > is
> fairly straightforward, and helps my immediate crash out of FLT and most of
> the other use cases I've encountered.
> >
> > Thanks,
> >
> >  - Dan
> >
> >
> >
> > > -Original Message-
> > > From: Daniel Emminizer, Code 5773
> > > Sent: Monday, June 04, 2018 8:45 AM
> > > To: OpenSceneGraph Users
> > > Subject: RE: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
> > >
> > > Hi Robert,
> > >
> > > The file you sent is identical to the one I sent.  Was that intentional?  
> > > You
> also
> > > mention Cessna; do you have the examples mixed up perhaps?
> > >
> > > The bug will manifest if the geometry's normal array (and presumably
> fog,
> > > colors, etc) are set before the array binding type is set.  It's entirely
> possible
> > > to have correctly loaded models.  I only ran across this because the
> > > OpenFlight loader sets the binding late.
> > >
> > >
> > > This bug prints on console:
> > >
> > > Warning: detected OpenGL error 'invalid operation' at after
> > > drawable.compileGLObjects() call in
> GLObjectsVisitor::apply(osg::Drawable&
> > > drawable)
> > >
> > >
> > > No change in error message with with OSG_GL_ERROR_CHECKING=on.
> No
> > > change in error message with --ro, with --reset, or with --ro --reset.
> > >
> > > I am building OSG 3.6.1 (and tried OpenSceneGraph-3.6) in core profile on
> > > Windows 10.  Video card data is:
> > >
> > > Vendor = NVIDIA Corporation
> > > Renderer = NVS 510/PCIe/SSE2
> > > Version = 3.3.0 NVIDIA 388.19
> > > GLSL Version = 330
> > >
> > >
> > > Responses from me will be slow this week; my email access will be
> spotty.
> > >
> > > Hope this helps.  Thanks,
> > >
> > >  - Dan
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org]
> On
> > > > Behalf Of Robert Osfield
> > > > Sent: Sunday, June 03, 2018 6:11 AM
> > > > To: OpenSceneGraph Users
> > > > Subject: Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
> > > >
> > > > Hi Dan,
> > > >
> > > > On 1 June 2018 at 16:01, Daniel Emminizer, Code 5773
> > > >  wrote:
> > > > > Attached is a demo of the problem that generates a 

Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays

[Daniel Emminizer, Code 5773]

Hi Laurens,

Thanks for the response.

I’m not super familiar with the back-end of OSG.  I tried to tackle the problem 
by looking for possible insertion points for the 
addVertexBufferObjectIfRequired(), in a way that won’t break binary 
compatibility.  This attempt did fix the crash for me in the dozen files I 
attempted to load.

I debugged a bit more at your prodding.  It’s working for me because the models 
that I am loading are reusing arrays in multiple primitive sets.  As I load the 
models, each of them has thousands of calls to setBinding(), but tens of 
thousands of primitive sets, most occurring well after the setBinding() calls.  
This implies array reuse to me.


Yes, the problem can definitely be avoided by editing the FLT plugin.  However, 
this problem occurred in lots of our own user code (unrelated to FLT), and in 
osgEarth too.  My first naïve approach was to fix all locations that set up 
arrays to configure binding before setting the array.  But there are so many, 
and any missed one will cause a crash.  I’ve been months into my OSG 3.6 (and 
GL3 core profile) upgrade before encountering this bug; how many more are 
waiting?

This used to be valid usage in the sense that it used to work in 3.4, and 
presumably is still valid because setBinding() is still public, not deprecated, 
and there’s no warnings in the code to avoid this condition.  That’s part of 
the reason for my original email – if this is not a valid use case, then 
someone’s going to have to find and fix all the violations in OSG code like 
FLT.  I don’t mind taking a crack at it since it impacts me, but I’d rather fix 
the source of the problem than every symptom.

What you’ve posted below is definitely my fallback if the problem can’t be 
solved by changing osg::Array/Geometry.

- Dan



  Dan Emminizer
  Code 5773.40
  Naval Research Laboratory
  https://simdis.nrl.navy.mil


From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of Voerman, L.
Sent: Monday, June 11, 2018 10:26 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays

Hi Daniel,
I don't understand why your modification to addPrimitiveSet() resolves your 
issue with the openflight plugin, as it's called before the proper array 
bindings have been set (src\osgPlugins\OpenFlight\GeometryRecords.cpp line 601)
Can your problem be avoided by changing
if (geometry->getColorArray()) 
geometry->getColorArray()->setBinding(osg::Array::BIND_PER_VERTEX);
to
if (geometry->getColorArray()) geometry->setColorArray( 
geometry->getColorArray(), osg::Array::BIND_PER_VERTEX);
and
if (geometry->getNormalArray()) 
geometry->getNormalArray()->setBinding(osg::Array::BIND_PER_VERTEX);
by
if (geometry->getNormalArray()) geometry->setNormalArray( 
geometry->getNormalArray(), osg::Array::BIND_PER_VERTEX);

(both changes appear two times in  
src\osgPlugins\OpenFlight\GeometryRecords.cpp )
Regards, Laurens.

On Mon, Jun 11, 2018 at 3:37 PM, Daniel Emminizer, Code 5773 
mailto:dan.emmini...@nrl.navy.mil>> wrote:
Hi Robert,

I am back from travel and looking at this again.  Didn't get a response on last 
set of questions about this crash.  Sorry to distract from the Vulkan work -- 
it sounds interesting, and I'm watching your progress there excitedly.


Core problem seems to be that Array::setBinding() can change after 
Geometry::set*Array().  Geometry::set*Array() is responsible for calling 
addVertexBufferObjectIfRequired(), and doesn't have enough information to 
correctly do so.

During the draw traversal, as a result, the Array::getBinding() flag does not 
match the VBO state in Geometry.

One solution is to create the VBO as needed (using 
addVertexBufferObjectIfRequired) sometime between the start of cull phase and 
before the Geometry::drawImplementation().  But drawImplementation() is const, 
and not a place where this can happen.


Another possible solution that might help is to modify 
Geometry::setPrimitiveSet() and addPrimitiveSet() to call 
addVertexBufferObjectIfRequired() on the various arrays.  I prototyped this 
solution locally and it resolved the issue in the FLT loader.  I know it's not 
perfect, but most places I've seen that would trigger this bug have defined an 
array binding by the time a primitive set is added.

Should I submit a PR for this approach?  It keeps binary compatibility and is 
fairly straightforward, and helps my immediate crash out of FLT and most of the 
other use cases I've encountered.

Thanks,

 - Dan



> -Original Message-
> From: Daniel Emminizer, Code 5773
> Sent: Monday, June 04, 2018 8:45 AM
> To: OpenSceneGraph Users
> Subject: RE: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
>
> Hi Robert,
>
> The file you sent is identical to the one I sent.  Was that intentional?  You 
> also
> mention Cessna; do you have the examples mixed up perhaps?
>
> The bug will manifest if the geometry's normal array (and 

Re: [osg-users] OsgMovie ffmpeg and audio (SDL2) - Audio seems to make video slower. Audio has hiccoughing

[Voerman, L.]

Hi Andrea,
did you have a look at the load on the cpu cores? The slowdown seems to
indicate a cpu core hitting 100% load.
this link might help you further:
http://forum.openscenegraph.org/viewtopic.php?p=72124#72124
Regards, Laurens.

On Mon, Jun 11, 2018 at 4:36 PM, Andrea Martini 
wrote:

> Hi everyone,
> i'm using osg3.5.6 on visual studio 2013 (windows 10), and i'm using
> ffmpeg  plugin combined with SDL2 to play video and audio streaming with
> osgmovie example.
> If i don't use SDL2 (no audio), video streaming works fine.
> If i add SDL2 (audio), i get two bad results:
> 1) video stream get slower
> 2) Audio has hiccoughing
>
> I tryied with some video examples (with different resolutions) but i get
> the same result.
>
> Following, i report audio streaming output displayed on the console:
>
> ffmpeg::open(C:\Movie\surfers_360.mp4) size(2048, 1024) aspect ratio 1
> Attaching FFmpegAudioStream
> AudioStream read []
> FFmpegAudioStream::setAudioSink( 0277C50FEEE0)
> Assigning 0277C50FEEE0
> image->s()2048 image-t()=1024 aspectRatio=1
> SDLAudioSink()::startPlaying()
>   audioFrequency()=48000
>   audioNbChannels()=2
>   audioSampleFormat()=4
>   SampleFormat  = SAMPLE_FORMAT_F32
>
> I'm wondering if i should continue with ffmpeg and sdl libraries, or i
> have to look at another one. In this last case, could you suggest me some
> way to follow? (link, examples, ...)
>
> Thank you!
>
> Cheers,
> Andrea
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=74033#74033
>
>
>
>
>
> ___
> 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] VBO Bug with 3.6.1 and Normal Arrays

[Robert Osfield]

Hi Daniel,

Thanks for looking further into this.  I did some investigation
originally but didn't get to the bottom of the issue.  FYI, the
support for Vertex Array Objects is what instigated these changes to
way that VBO's had to be managed.  Essentially all osg::Array with per
vertex bindings now need have a a VertexBufferObject assigned.

If you have made a commit for this fix against your own git clone of
the OSG just pointing me at this commit should help me understand what
is going on better.

Cheers,
Robert.
On Mon, 11 Jun 2018 at 14:44, Daniel Emminizer, Code 5773
 wrote:
>
> Hi Robert,
>
> I am back from travel and looking at this again.  Didn't get a response on 
> last set of questions about this crash.  Sorry to distract from the Vulkan 
> work -- it sounds interesting, and I'm watching your progress there excitedly.
>
>
> Core problem seems to be that Array::setBinding() can change after 
> Geometry::set*Array().  Geometry::set*Array() is responsible for calling 
> addVertexBufferObjectIfRequired(), and doesn't have enough information to 
> correctly do so.
>
> During the draw traversal, as a result, the Array::getBinding() flag does not 
> match the VBO state in Geometry.
>
> One solution is to create the VBO as needed (using 
> addVertexBufferObjectIfRequired) sometime between the start of cull phase and 
> before the Geometry::drawImplementation().  But drawImplementation() is 
> const, and not a place where this can happen.
>
>
> Another possible solution that might help is to modify 
> Geometry::setPrimitiveSet() and addPrimitiveSet() to call 
> addVertexBufferObjectIfRequired() on the various arrays.  I prototyped this 
> solution locally and it resolved the issue in the FLT loader.  I know it's 
> not perfect, but most places I've seen that would trigger this bug have 
> defined an array binding by the time a primitive set is added.
>
> Should I submit a PR for this approach?  It keeps binary compatibility and is 
> fairly straightforward, and helps my immediate crash out of FLT and most of 
> the other use cases I've encountered.
>
> Thanks,
>
>  - Dan
>
>
>
> > -Original Message-
> > From: Daniel Emminizer, Code 5773
> > Sent: Monday, June 04, 2018 8:45 AM
> > To: OpenSceneGraph Users
> > Subject: RE: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
> >
> > Hi Robert,
> >
> > The file you sent is identical to the one I sent.  Was that intentional?  
> > You also
> > mention Cessna; do you have the examples mixed up perhaps?
> >
> > The bug will manifest if the geometry's normal array (and presumably fog,
> > colors, etc) are set before the array binding type is set.  It's entirely 
> > possible
> > to have correctly loaded models.  I only ran across this because the
> > OpenFlight loader sets the binding late.
> >
> >
> > This bug prints on console:
> >
> > Warning: detected OpenGL error 'invalid operation' at after
> > drawable.compileGLObjects() call in GLObjectsVisitor::apply(osg::Drawable&
> > drawable)
> >
> >
> > No change in error message with with OSG_GL_ERROR_CHECKING=on.  No
> > change in error message with --ro, with --reset, or with --ro --reset.
> >
> > I am building OSG 3.6.1 (and tried OpenSceneGraph-3.6) in core profile on
> > Windows 10.  Video card data is:
> >
> > Vendor = NVIDIA Corporation
> > Renderer = NVS 510/PCIe/SSE2
> > Version = 3.3.0 NVIDIA 388.19
> > GLSL Version = 330
> >
> >
> > Responses from me will be slow this week; my email access will be spotty.
> >
> > Hope this helps.  Thanks,
> >
> >  - Dan
> >
> >
> >
> > > -Original Message-
> > > From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> > > Behalf Of Robert Osfield
> > > Sent: Sunday, June 03, 2018 6:11 AM
> > > To: OpenSceneGraph Users
> > > Subject: Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
> > >
> > > Hi Dan,
> > >
> > > On 1 June 2018 at 16:01, Daniel Emminizer, Code 5773
> > >  wrote:
> > > > Attached is a demo of the problem that generates a console warning.
> > > More complex scenes can cause crashes.  The red triangle has the problem,
> > > but the green one does not.
> > >
> > > I have built the example, and to help with test have changed the #ifdef
> > > blocks to ones that check arguments.read("--ro") for the RealizerOperation
> > > usage and "--reset" for the
> > > resetVertexAttributeAlias.   Attached is the modified file.
> > >
> > > If you run the test with --ro and have it use the custom 
> > > RealizerOperation I
> > > see a completely red cessna.  If I used --ro and --reset I see 
> > > multi-colour
> > > (blue, red etc) one, if I run without any options I see the multi-colour 
> > > one.
> > >
> > > I don't see any command line warnings though.  I'm testing under Kubuntu
> > > with OSG-3.6 branch, my drive info is:
> > >
> > > OpenGL vendor string: NVIDIA Corporation OpenGL renderer string:
> > GeForce
> > > GTX 760/PCIe/SSE2 OpenGL core profile version string: 4.5.0 NVIDIA
> > 384.111
> > > OpenGL core profile shading language 

[osg-users] OsgMovie ffmpeg and audio (SDL2) - Audio seems to make video slower. Audio has hiccoughing

[Andrea Martini]

Hi everyone,
i'm using osg3.5.6 on visual studio 2013 (windows 10), and i'm using ffmpeg  
plugin combined with SDL2 to play video and audio streaming with osgmovie 
example.
If i don't use SDL2 (no audio), video streaming works fine. 
If i add SDL2 (audio), i get two bad results:
1) video stream get slower
2) Audio has hiccoughing

I tryied with some video examples (with different resolutions) but i get the 
same result.

Following, i report audio streaming output displayed on the console:

ffmpeg::open(C:\Movie\surfers_360.mp4) size(2048, 1024) aspect ratio 1
Attaching FFmpegAudioStream
AudioStream read []
FFmpegAudioStream::setAudioSink( 0277C50FEEE0)
Assigning 0277C50FEEE0
image->s()2048 image-t()=1024 aspectRatio=1
SDLAudioSink()::startPlaying()
  audioFrequency()=48000
  audioNbChannels()=2
  audioSampleFormat()=4
  SampleFormat  = SAMPLE_FORMAT_F32

I'm wondering if i should continue with ffmpeg and sdl libraries, or i have to 
look at another one. In this last case, could you suggest me some way to 
follow? (link, examples, ...)

Thank you!

Cheers,
Andrea

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





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

Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays

[Voerman, L.]

Hi Daniel,
I don't understand why your modification to addPrimitiveSet() resolves your
issue with the openflight plugin, as it's called before the proper array
bindings have been set (src\osgPlugins\OpenFlight\GeometryRecords.cpp line
601)
Can your problem be avoided by changing
if (geometry->getColorArray())
geometry->getColorArray()->setBinding(osg::Array::BIND_PER_VERTEX);
to
if (geometry->getColorArray()) geometry->setColorArray(
geometry->getColorArray(), osg::Array::BIND_PER_VERTEX);
and
if (geometry->getNormalArray())
geometry->getNormalArray()->setBinding(osg::Array::BIND_PER_VERTEX);
by
if (geometry->getNormalArray()) geometry->setNormalArray(
geometry->getNormalArray(), osg::Array::BIND_PER_VERTEX);

(both changes appear two times in
src\osgPlugins\OpenFlight\GeometryRecords.cpp )
Regards, Laurens.

On Mon, Jun 11, 2018 at 3:37 PM, Daniel Emminizer, Code 5773 <
dan.emmini...@nrl.navy.mil> wrote:

> Hi Robert,
>
> I am back from travel and looking at this again.  Didn't get a response on
> last set of questions about this crash.  Sorry to distract from the Vulkan
> work -- it sounds interesting, and I'm watching your progress there
> excitedly.
>
>
> Core problem seems to be that Array::setBinding() can change after
> Geometry::set*Array().  Geometry::set*Array() is responsible for calling
> addVertexBufferObjectIfRequired(), and doesn't have enough information to
> correctly do so.
>
> During the draw traversal, as a result, the Array::getBinding() flag does
> not match the VBO state in Geometry.
>
> One solution is to create the VBO as needed (using
> addVertexBufferObjectIfRequired) sometime between the start of cull phase
> and before the Geometry::drawImplementation().  But drawImplementation()
> is const, and not a place where this can happen.
>
>
> Another possible solution that might help is to modify
> Geometry::setPrimitiveSet() and addPrimitiveSet() to call
> addVertexBufferObjectIfRequired() on the various arrays.  I prototyped
> this solution locally and it resolved the issue in the FLT loader.  I know
> it's not perfect, but most places I've seen that would trigger this bug
> have defined an array binding by the time a primitive set is added.
>
> Should I submit a PR for this approach?  It keeps binary compatibility and
> is fairly straightforward, and helps my immediate crash out of FLT and most
> of the other use cases I've encountered.
>
> Thanks,
>
>  - Dan
>
>
>
> > -Original Message-
> > From: Daniel Emminizer, Code 5773
> > Sent: Monday, June 04, 2018 8:45 AM
> > To: OpenSceneGraph Users
> > Subject: RE: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
> >
> > Hi Robert,
> >
> > The file you sent is identical to the one I sent.  Was that
> intentional?  You also
> > mention Cessna; do you have the examples mixed up perhaps?
> >
> > The bug will manifest if the geometry's normal array (and presumably fog,
> > colors, etc) are set before the array binding type is set.  It's
> entirely possible
> > to have correctly loaded models.  I only ran across this because the
> > OpenFlight loader sets the binding late.
> >
> >
> > This bug prints on console:
> >
> > Warning: detected OpenGL error 'invalid operation' at after
> > drawable.compileGLObjects() call in GLObjectsVisitor::apply(osg::
> Drawable&
> > drawable)
> >
> >
> > No change in error message with with OSG_GL_ERROR_CHECKING=on.  No
> > change in error message with --ro, with --reset, or with --ro --reset.
> >
> > I am building OSG 3.6.1 (and tried OpenSceneGraph-3.6) in core profile on
> > Windows 10.  Video card data is:
> >
> > Vendor = NVIDIA Corporation
> > Renderer = NVS 510/PCIe/SSE2
> > Version = 3.3.0 NVIDIA 388.19
> > GLSL Version = 330
> >
> >
> > Responses from me will be slow this week; my email access will be spotty.
> >
> > Hope this helps.  Thanks,
> >
> >  - Dan
> >
> >
> >
> > > -Original Message-
> > > From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> > > Behalf Of Robert Osfield
> > > Sent: Sunday, June 03, 2018 6:11 AM
> > > To: OpenSceneGraph Users
> > > Subject: Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
> > >
> > > Hi Dan,
> > >
> > > On 1 June 2018 at 16:01, Daniel Emminizer, Code 5773
> > >  wrote:
> > > > Attached is a demo of the problem that generates a console warning.
> > > More complex scenes can cause crashes.  The red triangle has the
> problem,
> > > but the green one does not.
> > >
> > > I have built the example, and to help with test have changed the #ifdef
> > > blocks to ones that check arguments.read("--ro") for the
> RealizerOperation
> > > usage and "--reset" for the
> > > resetVertexAttributeAlias.   Attached is the modified file.
> > >
> > > If you run the test with --ro and have it use the custom
> RealizerOperation I
> > > see a completely red cessna.  If I used --ro and --reset I see
> multi-colour
> > > (blue, red etc) one, if I run without any options I see the
> multi-colour one.
> > >
> > > I don't see any command line 

Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays

[Daniel Emminizer, Code 5773]

Hi Robert,

I am back from travel and looking at this again.  Didn't get a response on last 
set of questions about this crash.  Sorry to distract from the Vulkan work -- 
it sounds interesting, and I'm watching your progress there excitedly.


Core problem seems to be that Array::setBinding() can change after 
Geometry::set*Array().  Geometry::set*Array() is responsible for calling 
addVertexBufferObjectIfRequired(), and doesn't have enough information to 
correctly do so.

During the draw traversal, as a result, the Array::getBinding() flag does not 
match the VBO state in Geometry.

One solution is to create the VBO as needed (using 
addVertexBufferObjectIfRequired) sometime between the start of cull phase and 
before the Geometry::drawImplementation().  But drawImplementation() is const, 
and not a place where this can happen.


Another possible solution that might help is to modify 
Geometry::setPrimitiveSet() and addPrimitiveSet() to call 
addVertexBufferObjectIfRequired() on the various arrays.  I prototyped this 
solution locally and it resolved the issue in the FLT loader.  I know it's not 
perfect, but most places I've seen that would trigger this bug have defined an 
array binding by the time a primitive set is added.

Should I submit a PR for this approach?  It keeps binary compatibility and is 
fairly straightforward, and helps my immediate crash out of FLT and most of the 
other use cases I've encountered.

Thanks,

 - Dan



> -Original Message-
> From: Daniel Emminizer, Code 5773
> Sent: Monday, June 04, 2018 8:45 AM
> To: OpenSceneGraph Users
> Subject: RE: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
> 
> Hi Robert,
> 
> The file you sent is identical to the one I sent.  Was that intentional?  You 
> also
> mention Cessna; do you have the examples mixed up perhaps?
> 
> The bug will manifest if the geometry's normal array (and presumably fog,
> colors, etc) are set before the array binding type is set.  It's entirely 
> possible
> to have correctly loaded models.  I only ran across this because the
> OpenFlight loader sets the binding late.
> 
> 
> This bug prints on console:
> 
> Warning: detected OpenGL error 'invalid operation' at after
> drawable.compileGLObjects() call in GLObjectsVisitor::apply(osg::Drawable&
> drawable)
> 
> 
> No change in error message with with OSG_GL_ERROR_CHECKING=on.  No
> change in error message with --ro, with --reset, or with --ro --reset.
> 
> I am building OSG 3.6.1 (and tried OpenSceneGraph-3.6) in core profile on
> Windows 10.  Video card data is:
> 
> Vendor = NVIDIA Corporation
> Renderer = NVS 510/PCIe/SSE2
> Version = 3.3.0 NVIDIA 388.19
> GLSL Version = 330
> 
> 
> Responses from me will be slow this week; my email access will be spotty.
> 
> Hope this helps.  Thanks,
> 
>  - Dan
> 
> 
> 
> > -Original Message-
> > From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> > Behalf Of Robert Osfield
> > Sent: Sunday, June 03, 2018 6:11 AM
> > To: OpenSceneGraph Users
> > Subject: Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
> >
> > Hi Dan,
> >
> > On 1 June 2018 at 16:01, Daniel Emminizer, Code 5773
> >  wrote:
> > > Attached is a demo of the problem that generates a console warning.
> > More complex scenes can cause crashes.  The red triangle has the problem,
> > but the green one does not.
> >
> > I have built the example, and to help with test have changed the #ifdef
> > blocks to ones that check arguments.read("--ro") for the RealizerOperation
> > usage and "--reset" for the
> > resetVertexAttributeAlias.   Attached is the modified file.
> >
> > If you run the test with --ro and have it use the custom RealizerOperation I
> > see a completely red cessna.  If I used --ro and --reset I see multi-colour
> > (blue, red etc) one, if I run without any options I see the multi-colour 
> > one.
> >
> > I don't see any command line warnings though.  I'm testing under Kubuntu
> > with OSG-3.6 branch, my drive info is:
> >
> > OpenGL vendor string: NVIDIA Corporation OpenGL renderer string:
> GeForce
> > GTX 760/PCIe/SSE2 OpenGL core profile version string: 4.5.0 NVIDIA
> 384.111
> > OpenGL core profile shading language version string: 4.50 NVIDIA
> >
> > I don't yet have any idea what is going wrong, it's obviously very odd that
> the
> > custom RealizeOperation is having an effect when it does nothing itself.
> >
> > Before I start diving deeper I'd like to know what others are seeing with
> > these different combinations and if any errors are being printed in the
> > console, if so what are they.  Also let us know the OSG version and
> driver/OS
> > details.
> >
> > Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenGL function does not return on Titan Xp

[Voerman, L.]

Hi Lionel,
as this seems to be a driver issue, the operating system and driver version
info would be useful to compare.
Regards, Laurens.

On Mon, Jun 11, 2018 at 3:01 PM, Lionel Lagarde 
wrote:

> Hi,
>
> We have a set of products based on OSG that run well on common hardware.
>
> Recently a customer bought a NVidia Titan Xp. Our software do not work on
> this graphics card.
> The software do not crash, it stop responding to any event.
>
> The software is always stuck in the middle of a glGenTexture call
> (osg::Texture2D::apply).
>
> We use OSG 3.0.1 but I tested with OSG 3.6.1 and the 2 have the same issue
>
> Other graphics tools, like COIN based software or the demos that come with
> GPU Caps Viewer work fine.
>
> The behavior is reproducible using the command "osgviewer cow.osg", and
> display the rendering stats using "s".
> The stats use text, that use textures for the glyph of the characters. The
> GL function used to reserve the texture
> ID  (which I think is a pure CPU/driver job) never returns.
>
> I wonder if somebody that have a Titan Xp (I know it is a very rare and
> useless card, a 1080 Ti does the job pretty well) have a similar issue
>
> ___
> 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] OpenGL function does not return on Titan Xp

[Lionel Lagarde]

Hi,

We have a set of products based on OSG that run well on common hardware.

Recently a customer bought a NVidia Titan Xp. Our software do not work 
on this graphics card.

The software do not crash, it stop responding to any event.

The software is always stuck in the middle of a glGenTexture call 
(osg::Texture2D::apply).


We use OSG 3.0.1 but I tested with OSG 3.6.1 and the 2 have the same issue

Other graphics tools, like COIN based software or the demos that come 
with GPU Caps Viewer work fine.


The behavior is reproducible using the command "osgviewer cow.osg", and 
display the rendering stats using "s".
The stats use text, that use textures for the glyph of the characters. 
The GL function used to reserve the texture

ID  (which I think is a pure CPU/driver job) never returns.

I wonder if somebody that have a Titan Xp (I know it is a very rare and 
useless card, a 1080 Ti does the job pretty well) have a similar issue


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

Re: [osg-users] C++11 for next stable release of OpenSceneGraph?

[Alberto Luaces]

Robert Osfield writes:

> I would suggest that OpenSceneGraph-3.x series remain compilable
> without needing C++11.  So 3.6.x for instance we'll make bug fixes etc
> but never change the compiler requirements.

Having that fallback (3.x) for the tiny amount of systems that don't
support C++11 is a sensible approach, and I would even dare to say
extra-conservative, given the support of C+11 among current compilers.

-- 
Alberto

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

Re: [osg-users] [forum] how can i static link to OSG

[Alberto Luaces]

"lee xingshun" writes:

> Hi,
>
> while i using staic link libarary to write a demo,i found many error link 2019
> this is my code ,have anybody know? do i need link the lib file or not ?

Hi, so link 2019 means "unresolved external symbol - function".  Can you
please copy the names of the unresolved symbols the linker is missing?

-- 
Alberto

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

Re: [osg-users] [forum] how can i static link to OSG

[Voerman, L.]

Hi Lee,
you will need to link to the static libraries, and there will be quite a
few.
something like:
OpenThreads.lib;osg.lib;osgDB.lib;osgUtil.lib;osgText.lib;osgViewer.lib;osgGA.lib;osgdb_ive.lib;osgdb_osg.lib;osgdb_deprecated_osg.lib;osgdb_deprecated_osgparticle.lib;osgdb_deprecated_osganimation.lib;osgdb_deprecated_osgfx.lib;osgdb_deprecated_osgsim.lib;osgdb_deprecated_osgtext.lib;osgdb_deprecated_osgviewer.lib;osgdb_deprecated_osgshadow.lib;osgdb_deprecated_osgterrain.lib;osgdb_deprecated_osgvolume.lib;osgdb_deprecated_osgwidget.lib;osgdb_serializers_osg.lib;osgdb_serializers_osgparticle.lib;osgdb_serializers_osgtext.lib;osgdb_serializers_osgterrain.lib;osgdb_serializers_osganimation.lib;osgdb_serializers_osgfx.lib;osgdb_serializers_osgshadow.lib;osgdb_serializers_osgmanipulator.lib;osgdb_serializers_osgsim.lib;osgdb_serializers_osgvolume.lib

could resolve your linking errors.
Laurens.

On Sun, Jun 10, 2018 at 11:16 AM, lee xingshun  wrote:

> Hi,
>
> while i using staic link libarary to write a demo,i found many error link
> 2019
> this is my code ,have anybody know? do i need link the lib file or not ?
>
> code:from website using static libarary osg
>
> Thank you!
>
> Cheers,
> lee
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=74019#74019
>
>
>
>
> Attachments:
> http://forum.openscenegraph.org//files/win32project1_147.cpp
>
>
> ___
> 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] Export the cropped model

[Alberto Luaces]

"Bingqian Wang" writes:

> Hi,
>
> I want to export the model to a file,the model was cliped by clipNode,how can 
> i do that?
> Thank you!
>

Hi, I'm afraid that it is not possible to do it in an automatic way,
since the clipped model is computed by the GPU on the fly, not by OSG,
so it is not recoverable, as far as I know.

You could search for a library featuring boolean operations to get the
clipped model.

-- 
Alberto

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

[osg-users] C++11 for next stable release of OpenSceneGraph?

[Robert Osfield]

Hi All,

My current focus is on the VulkanSceneGraph, exploring C+11, Vulkan
and new ideas of what a next gen scene graph should look like.
OpenSceneGraph is still very much my baby though.  Stuff that is
working well on the VulkanSceneGraph could serve as a model for what
we can do to elements of the OpenSceneGraph, so potentially as
advances are made in VulkanSceneGraph would could refactor the
OpenSceneGraph to take advantage of similar approaches.

While OpenSceneGraph will remain focused on OpenGL and aim to retain
good backwards compatibility there may be opportunities to make life
easier to OpenSceneGraph users.  One of these areas is taking
advantage of some of the features that C++11 has to offer.  So far on
the VulkanSceneGraph side I've experimented with some low level
equivalents of things like ref counting, ref pointers, observer
pointers taking advantage of C++11 and it's a delight, the code is
S much simpler and cleaner that what's presently in the
OpenSceneGraph.

So I'd like to put out the topic for discussion about whether we could
set the min compiler version of the OpenSceneGraph to C++11 for the
next major stable release.  I don't have any specific plans to this
next stable release, I'm assuming it'll be 4.0, it'll likely be
another year or so before being released.  I would like to this
OpenSceneGraph stable release to sync in a bit with the
VulkanSceneGraph efforts but as this project is just beginning the
schedule for it's own releases is completely open.  When I say sync a
bit, I'm really just referring to taking opportunities to cross
pollinate ideas a bit, make co-existance of the two projects easier,
what that will mean in practice I absolutely can't say, it's really
just an aspiration right now.

Back to C++11, the pros of adopting it for OpenSceneGraph-4.0 is that
we could simplify parts of the core OpenSceneGraph, making it both
easier to lean and maintain.  Potentially even OpenThreads could be
removed as dependency and then from the core OpenSceneGraph and made
it's own separate project once again.

The cons of adopting C++ would be restrictions on just how old the
compilers can be to be used with OpenSceneGraph-4.x, so could limit
one aspect to backwards compatibility.

I would suggest that OpenSceneGraph-3.x series remain compilable
without needing C++11.  So 3.6.x for instance we'll make bug fixes etc
but never change the compiler requirements.

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

[osg-users] [forum] how can i static link to OSG

[lee xingshun]

Hi,

while i using staic link libarary to write a demo,i found many error link 2019
this is my code ,have anybody know? do i need link the lib file or not ?

code:from website using static libarary osg

Thank you!

Cheers,
lee

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




Attachments: 
http://forum.openscenegraph.org//files/win32project1_147.cpp


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

[osg-users] problem with picking/intersecting in window space

[Andreas Mueller]

Hi,

I have a problem with picking via an intersector in window space.
For picking I use the following code:


Code:
osgUtil::LineSegmentIntersector* pIntersector = new 
osgUtil::LineSegmentIntersector(osgUtil::Intersector::WINDOW, x, y);
pIntersector->setIntersectionLimit(osgUtil::Intersector::LIMIT_NEAREST);
osgUtil::IntersectionVisitor iv(pIntersector);
camera->accept(iv);



If I zoom in then it happens that I can not pick elements just in front of me 
near the eye position.
It seems that some (near plane) clipping/culling happens in the intersector 
while the rendering uses another near plane for clipping.
The camera uses the default COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES mode.

For testing purposes, I set in the camera the DO_NOT_COMPUTE_NEAR_FAR mode. 
Then I noticed near plane clipping when zooming in (that I don't have in 
COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES mode) but I can pick all elements that 
are rendered.

So I guess the intersector don't use the automatically computed near/far 
clipping planes of the camera (if in COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES 
mode) for the conversion of the intersector line segment coordinates from 
window to world space where the intersection is actually done. 
Is this correct? And what do I have to do to be able to pick all elements that 
are rendered with the COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES mode?

Thank you!

Regards,
Andreas

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





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

Re: [osg-users] Draw geometry on demand

[Robert Osfield]

HI Tyler.

> I like to know how to redraw geometry on demand.
> I have a osg:geometry with attached VertexArray and PrimitiveSet.
> I need to send draw command to redraw geometry.
> I see there is a "draw" method in DrawElements class, but that wants
> an osg::State that i dont know how to get.
> Or alternatively is there any other procedure how to do that, like some 
> UpdateCallback?
> Can anyone help me?

You don't normally draw "on demand" with a scene graph, it's purpose
is to manage the culling and draw dispatch for you.

There are times when you can manage low level rendering, but this
tends to be niche task done for very specific techniques, it's
something I'd expect advanced users might consider occasionally, but
for the most part users will likely never call the low level draw code
themselves.

Could you take a step back and explain what you are trying to do at a
higher level.  I suggest this as there may well be a much more
straight forward way of doing things that starting to get your hand
dirty with low level stuff.

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