Re: [osg-users] OSG-3.4 crashes under Android

2016-10-18 Thread michael kapelko
If anyone has a working OSG Android example, that would also help.
Anyone?

2016-10-18 23:09 GMT+07:00 michael kapelko :

> Hi.
> I have problem running minimal OSG application under Android.
> Here's the full source code for Android Studio 2.2 with prebuilt x86 and
> armeabi-v7a OSG libraries: https://bitbucket.org/kornerr/
> android-openscenegraph/src
> The OSGApp with initialization and rendering:
> https://bitbucket.org/kornerr/android-openscenegraph/src/
> tip/app/src/main/cpp/src/OSGApp.cpp?at=default&
> fileviewer=file-view-default
>
> I've added logs to locate the exact line of code that crashes.
> Here's the log:
>
> I/OSGLog: init
> I/OSGLog: got init
> D/EGLview: Renderer.onDrawFrame
> I/OSGLog: begin step
> I/OSGLog: 01. frame
> E/eglCodecCommon: glUtilsParamSize: unknow param 0x8073
> E/eglCodecCommon: glUtilsParamSize: unknow param 0x88ff
> I/OSGLog: 1. renderingTraversals
> I/OSGLog: 01. GC.runOperations
> I/OSGLog: 01. Renderer.operator()
> I/OSGLog: 01. Renderer.cull_draw
> I/OSGLog: 01.SceneView.cull
> I/OSGLog: 01.SceneView.cullStage
> I/OSGLog: 01.CullStack.pushProjectionMatrix
> I/OSGLog: _projectionStack.size: 0
> I/OSGLog: matrix: 0x2a1b5bb8
> I/OSGLog: 02.CullStack.pushProjectionMatrix
> I/OSGLog: 02.SceneView.cullStage
> I/OSGLog: 02.SceneView.cull
> I/OSGLog: 02. Renderer.cull_draw
> I/OSGLog: 02. Renderer.operator()
> I/OSGLog: 02. GC.runOperations
> I/OSGLog: 2. renderingTraversals
> I/OSGLog: 02. frame
> I/OSGLog: finish step
> D/EGLview: Renderer.onDrawFrame
> I/OSGLog: begin step
> I/OSGLog: 01. frame
> I/OSGLog: 1. renderingTraversals
> I/OSGLog: 01. GC.runOperations
> I/OSGLog: 01. Renderer.operator()
> I/OSGLog: 01. Renderer.cull_draw
> I/OSGLog: 01.SceneView.cull
> I/OSGLog: 01.SceneView.cullStage
> I/OSGLog: 01.CullStack.pushProjectionMatrix
> I/OSGLog: _projectionStack.size: 0
> I/OSGLog: matrix: 0x2a1b4f70
> A/libc: @@@ ABORTING: INVALID HEAP ADDRESS IN dlfree addr=0x5218a4a4
> A/libc: Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1), thread 655
> (Thread-72)
> Application terminated.
>
> The application crashes at https://github.com/
> openscenegraph/OpenSceneGraph/blob/master/src/osg/CullStack.cpp#L159
> when frame() is executed the SECOND time, the first frame() execution is
> fine.
>
> I observe standard purple screen for a second, then the application
> crashes.
>
> I'm stuck. Any idea?
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Fwd: OSG performance measurement

2016-10-18 Thread Hannes Naude
Hi Robert

Thanks for the reply. I toggled on the high levels of stats info and it was
immediately apparent that the delays were occurring in the event traversal,
which made no sense, since the only eventhandler that I explicitly added is
the StatsHandler and the problem predates that.

At this point, I abandoned my strong preconception that the problem was
somewhere in my OSG calling code or in the way that I set up my project and
just used htop to see whether any other processes were starving my little
OSG program of CPU time (something I did not consider earlier, because of
mentioned preconceptions and the fact that everything else running on my PC
appears responsive.) I saw a bunch of java processes that were hogging the
CPU (Attempts to install a newer eclipse via yatta that had failed silently
a few days ago). After killing these, the framerate went up to 60Hz and
stayed there after I uncommented all the actual functionality in my
program. So this was not OSG related at all after all. :-O

Thanks for your help.

Regards
Hannes

On Mon, Oct 17, 2016 at 5:18 PM, Robert Osfield 
wrote:

> Hi Hannes,
>
> There really isn't much info to go on from what you are written so
> far.  Using the StatsHandler is a good first step but just the frame
> rate reports doesn't tell us enough to know what is going on.
>
> Try toggling the the high levels of stats info and then look at the
> size of the update, event, cull, draw dispatch and draw GPU.
>
> Another thing to do is switch off vsync via the driver and see what
> the framerate is without vysunc on.
>
> Try with a range a models.  As a general note, the OSG with 980Ti
> should perform pretty well even for very large models.  I develop
> under Kubuntu and find the NVidia drivers work pretty well, it has to
> be a pretty serious model to get the frame rate down as low as
> 30-40fps, this requires ten's of millions of vertices per frame to be
> rendered or high res volume rendering.  With an small scene such as
> the OpenSceneGraph-Data's cow.osgt I get 6000+fps on a 1920x1080
> display.
>
> Robert.
>
> On 17 October 2016 at 16:05, Hannes Naude  wrote:
> > OK. Scratch that, I no longer believe that this is a performance
> measurement
> > issue, but rather a performance issue. I have replaced my measurement
> code
> > with the built in StatsHandler class, so my code now looks as follows:
> >
> > int main() {
> > ref_ptr viewer=new
> osgViewer::CompositeViewer();
> > ref_ptr view1 = new osgViewer::View;
> > viewer->addView(view1);
> > view1->addEventHandler( new osgViewer::StatsHandler );
> > return viewer->run();
> > }
> >
> > When I press S statshandler reports 30-40fps. Obviously there is not a
> lot
> > of room to have messed up in a 5-liner program, so I believe that that is
> > the actual framerate that I am getting. Question is why. I am running on
> a
> > NVIDIA Geforce 980Ti under Ubuntu 14.04 with nvidia driver version
> 352.63) .
> > I have optimization on (-O3 under gcc)  and believe that I am linking
> > against release libraries not debug ones.
> >
> > Any ideas where to look??
> >
> > Regards
> > Hannes
> > -- Forwarded message --
> > From: Hannes Naude 
> > Date: Mon, Oct 17, 2016 at 1:46 PM
> > Subject: OSG performance measurement
> > To: OpenSceneGraph Users 
> >
> >
> > Hi all
> >
> > New to OSG so apologies if this is a stupid question.
> >
> > I have written a visualization tool in OSG and as a last step, I wish to
> > ensure that it runs at the screen refresh rate. My perception was that it
> > mostly runs smoothly but stutters every few frames or so, so I wrote
> code to
> > print the elapsed time between every two frames, rather than just the
> > average framerate. The printout seemed to confirm this, so I gradually
> > removed more and more of my scenegraph, trying to determine where the
> > bottleneck lies. The weird thing is that I end up with a completely empty
> > scenegraph (just rendering a blue screen) and execution time STILL seems
> to
> > stutter. So, I strongly suspect that there is something fundamentally
> wrong
> > with the way I am measuring. I realise that FPS is a bad performance
> metric,
> > but right now I just want to get to the point where I am updating every
> > frame on my hardware and I am not particularly concerned about
> performance
> > on any other hardware. The remaining code looks like this:
> >
> > int main() {
> > ref_ptr viewer=new
> osgViewer::CompositeViewer();
> > ref_ptr view1 = new osgViewer::View;
> > viewer->addView(view1);
> > float timeNow,timePrev=0;
> > while (!viewer->done())
> > {
> > viewer->frame();
> > timeNow=osg::Timer::instance()->time_s();
> > std::cout << timeNow-timePrev << " ";
> > timePrev=timeNow;
> > }
> > return(0);
> > }
> >
> > and the resulting printout to the console looks like this:
> >
> > 0.123003 0.00298501 0.000751987 0.016045 0.083418 0.038128 0.013075
> 

Re: [osg-users] ot20-Openthreads.dll access violation

2016-10-18 Thread Sebastian Messerschmidt



Hi Uma,

Hi Sebastain,

  Sorry  I am unable to load the model, because it is too big for 
attachment(only 10 MB are allowed).
...
Can't you upload it somewhere else? Also compressing with 7Zip Ultra can 
shrink most files a lot.


What about a stats-screenshot? Some info on the file-type/format?
If you want us to be able to help you, we need some more information.

Cheers
Sebastian


Thank you!

Cheers,
Uma

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





___
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] Qt version for OSG3.4.0

2016-10-18 Thread Uma Devi Selvaraj
Hi all,

Thanks for the reply :) 

... 

Thank you!

Cheers,
Uma

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





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


Re: [osg-users] ot20-Openthreads.dll access violation

2016-10-18 Thread Robert Osfield
On 18 October 2016 at 09:36, Uma Devi Selvaraj  wrote:
> Hi Robert,
>
>  The size of the model I used is 49675 K. And it is taking more than one 
> hour to render in debug mode and in release mode it is taking 5 mins.

I second Sebastian's suggestions. I can't help feel that you are
mixing up various times to do things - loading and rendering.

Also what does 49675 K refer to?  Number of vertices?  Number of
primitives?  Size on disk with/without textures.

You really need to be more specific if you want help, it really
shouldn’t be down other members of the community to drag all this
stuff out from you.  If you don't have the expertise to do what you
are doing then perhaps you should consider some training or spending
more time on reading books online resources.

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


Re: [osg-users] ot20-Openthreads.dll access violation

2016-10-18 Thread Uma Devi Selvaraj
Hi Sebastain,

  Sorry  I am unable to load the model, because it is too big for 
attachment(only 10 MB are allowed).   
... 

Thank you!

Cheers,
Uma

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





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


Re: [osg-users] ot20-Openthreads.dll access violation

2016-10-18 Thread Uma Devi Selvaraj
Hi all,
 
Regarding openthreads access violation issue,today I tried to build osg 
without(BUILD_OPENTHREADS_WITH_QT) cmake options. And I tired to use those exe 
and dll files to run my example code. I am able to render 3D model Successfully 
in both debug and release mode, the problem is it is taking too mush of time to 
render. Is there any to way to render the model quickly.
 And I just want to know use of BUILD_OPENTHREADS_WITH_QT option.? Will it 
create any issue if I build OSG without this option.? 

... 

Thank you!

Cheers,
Uma

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





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


Re: [osg-users] ot20-Openthreads.dll access violation

2016-10-18 Thread Robert Osfield
Hi Uma,

Changing the OpenThreads backend will not change the performance you
see, it's just changing who sets up the threading.

With performance testing it only makes sense to do it with a release
build as debug build increases the CPU overhead massively and totally
distorts the framerates and crucially the relative balance for what
takes longest in the frame.  The later is important to optimization
work as you want to spend you time most effectively by fixing the
biggest bottlenecks,

As for how to make things faster, you don't provide any information
whatsoever about what your models are, the size of them, the hardware
you are working on, what the relative costs of the different
traversals.  There isn't anything we can do to advise you on such an
open ended question.

For instance, a question for you, I have a piece of string, could you
please tell me how long it?  Can you answer?

Robert.

On 18 October 2016 at 09:09, Uma Devi Selvaraj  wrote:
> Hi all,
>
> Regarding openthreads access violation issue,today I tried to build 
> osg without(BUILD_OPENTHREADS_WITH_QT) cmake options. And I tired to use 
> those exe and dll files to run my example code. I am able to render 3D model 
> Successfully in both debug and release mode, the problem is it is taking too 
> mush of time to render. Is there any to way to render the model quickly.
>  And I just want to know use of BUILD_OPENTHREADS_WITH_QT option.? Will it 
> create any issue if I build OSG without this option.?
>
> ...
>
> Thank you!
>
> Cheers,
> Uma
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=69050#69050
>
>
>
>
>
> ___
> 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] ot20-Openthreads.dll access violation

2016-10-18 Thread Sebastian Messerschmidt



Am 10/18/2016 um 10:36 AM schrieb Uma Devi Selvaraj:

Hi Robert,

 The size of the model I used is 49675 K. And it is taking more than one 
hour to render in debug mode and in release mode it is taking 5 mins.
Do you mean loading? Can you provide the model for testing? Or at least 
give some additional information (file format, external nodes, number of 
nodes/ screenshot of the complete stats)


Cheers
Sebastian


...

Thank you!

Cheers,
Uma

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





___
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] Qt version for OSG3.4.0

2016-10-18 Thread Lyubov Akimova
Hi,

4.8.6 working fine too.

Thank you!

Cheers,
Lyubov

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





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


Re: [osg-users] ot20-Openthreads.dll access violation

2016-10-18 Thread Uma Devi Selvaraj
Hi Robert,

 The size of the model I used is 49675 K. And it is taking more than one 
hour to render in debug mode and in release mode it is taking 5 mins.

... 

Thank you!

Cheers,
Uma

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





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


Re: [osg-users] ot20-Openthreads.dll access violation

2016-10-18 Thread Uma Devi Selvaraj
Hi Sebastain,
 
 Thank you so much for the reply. Yeah I have tried in osgviewer and it 
took 10-15 seconds. I have a doubt , does converting .obj or any other models 
to .osg will result in any loss of information.?

... 

Thank you!

Cheers,
Uma

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





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


[osg-users] OSG-3.4 crashes under Android

2016-10-18 Thread michael kapelko
Hi.
I have problem running minimal OSG application under Android.
Here's the full source code for Android Studio 2.2 with prebuilt x86 and
armeabi-v7a OSG libraries:
https://bitbucket.org/kornerr/android-openscenegraph/src
The OSGApp with initialization and rendering:
https://bitbucket.org/kornerr/android-openscenegraph/src/tip/app/src/main/cpp/src/OSGApp.cpp?at=default=file-view-default

I've added logs to locate the exact line of code that crashes.
Here's the log:

I/OSGLog: init
I/OSGLog: got init
D/EGLview: Renderer.onDrawFrame
I/OSGLog: begin step
I/OSGLog: 01. frame
E/eglCodecCommon: glUtilsParamSize: unknow param 0x8073
E/eglCodecCommon: glUtilsParamSize: unknow param 0x88ff
I/OSGLog: 1. renderingTraversals
I/OSGLog: 01. GC.runOperations
I/OSGLog: 01. Renderer.operator()
I/OSGLog: 01. Renderer.cull_draw
I/OSGLog: 01.SceneView.cull
I/OSGLog: 01.SceneView.cullStage
I/OSGLog: 01.CullStack.pushProjectionMatrix
I/OSGLog: _projectionStack.size: 0
I/OSGLog: matrix: 0x2a1b5bb8
I/OSGLog: 02.CullStack.pushProjectionMatrix
I/OSGLog: 02.SceneView.cullStage
I/OSGLog: 02.SceneView.cull
I/OSGLog: 02. Renderer.cull_draw
I/OSGLog: 02. Renderer.operator()
I/OSGLog: 02. GC.runOperations
I/OSGLog: 2. renderingTraversals
I/OSGLog: 02. frame
I/OSGLog: finish step
D/EGLview: Renderer.onDrawFrame
I/OSGLog: begin step
I/OSGLog: 01. frame
I/OSGLog: 1. renderingTraversals
I/OSGLog: 01. GC.runOperations
I/OSGLog: 01. Renderer.operator()
I/OSGLog: 01. Renderer.cull_draw
I/OSGLog: 01.SceneView.cull
I/OSGLog: 01.SceneView.cullStage
I/OSGLog: 01.CullStack.pushProjectionMatrix
I/OSGLog: _projectionStack.size: 0
I/OSGLog: matrix: 0x2a1b4f70
A/libc: @@@ ABORTING: INVALID HEAP ADDRESS IN dlfree addr=0x5218a4a4
A/libc: Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1), thread 655
(Thread-72)
Application terminated.

The application crashes at
https://github.com/openscenegraph/OpenSceneGraph/blob/master/src/osg/CullStack.cpp#L159
when frame() is executed the SECOND time, the first frame() execution is
fine.

I observe standard purple screen for a second, then the application crashes.

I'm stuck. Any idea?
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


[osg-users] Plugins errors for unsupported files

2016-10-18 Thread Riccardo Corsi
Hi Robert and all,

I'm currently using the ffmpeg plugin to load some movies - it works just
fine but my application started generating a lot of errors on console like
this:
> FFmpegImageStream::open : av_open_input_file() failed : AVERROR_NOENT
every time an image has to be loaded.

You can reproduce the issue with the modified osgMovie example in attach,
which also loads the textured cow model.

Digging a bit I've seen that's because the file reading mechanism tries to
read from all the already loaded plugins, reagardless of their extension(s)
support.
See here:
https://github.com/openscenegraph/OpenSceneGraph/blob/master/src/osgDB/
Registry.cpp#L1176

I thought that the extension supported by each plugin was checked before
trying to use it.
Besides the annoying errors on the console, wouldn't it be more efficient?

Thanks,
Ricky
/* OpenSceneGraph example, osgmovie.
*
*  Permission is hereby granted, free of charge, to any person obtaining a copy
*  of this software and associated documentation files (the "Software"), to deal
*  in the Software without restriction, including without limitation the rights
*  to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
*  copies of the Software, and to permit persons to whom the Software is
*  furnished to do so, subject to the following conditions:
*
*  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
*  IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
*  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
*  AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
*  LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
*  OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
*  THE SOFTWARE.
*/

#include 
#include 

#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 

#include 

class MovieEventHandler : public osgGA::GUIEventHandler
{
public:

MovieEventHandler():_trackMouse(false) {}

void setMouseTracking(bool track) { _trackMouse = track; }
bool getMouseTracking() const { return _trackMouse; }

void set(osg::Node* node);

virtual bool handle(const osgGA::GUIEventAdapter& ea,osgGA::GUIActionAdapter& aa, osg::Object*, osg::NodeVisitor* nv);

virtual void getUsage(osg::ApplicationUsage& usage) const;

typedef std::vector< osg::observer_ptr > ImageStreamList;

protected:

virtual ~MovieEventHandler() {}

class FindImageStreamsVisitor : public osg::NodeVisitor
{
public:
FindImageStreamsVisitor(ImageStreamList& imageStreamList):
_imageStreamList(imageStreamList) {}

virtual void apply(osg::Geode& geode)
{
apply(geode.getStateSet());

for(unsigned int i=0;igetStateSet());
}

traverse(geode);
}

virtual void apply(osg::Node& node)
{
apply(node.getStateSet());
traverse(node);
}

inline void apply(osg::StateSet* stateset)
{
if (!stateset) return;

osg::StateAttribute* attr = stateset->getTextureAttribute(0,osg::StateAttribute::TEXTURE);
if (attr)
{
osg::Texture2D* texture2D = dynamic_cast(attr);
if (texture2D) apply(dynamic_cast(texture2D->getImage()));

osg::TextureRectangle* textureRec = dynamic_cast(attr);
if (textureRec) apply(dynamic_cast(textureRec->getImage()));
}
}

inline void apply(osg::ImageStream* imagestream)
{
if (imagestream)
{
_imageStreamList.push_back(imagestream);
}
}

ImageStreamList& _imageStreamList;

protected:

FindImageStreamsVisitor& operator = (const FindImageStreamsVisitor&) { return *this; }

};


bool_trackMouse;
ImageStreamList _imageStreamList;
unsigned int_seekIncr;

};



void MovieEventHandler::set(osg::Node* node)
{
_imageStreamList.clear();
if (node)
{
FindImageStreamsVisitor fisv(_imageStreamList);
node->accept(fisv);
}
}


bool MovieEventHandler::handle(const osgGA::GUIEventAdapter& ea,osgGA::GUIActionAdapter& aa, osg::Object*, osg::NodeVisitor* nv)
{
switch(ea.getEventType())
{
case(osgGA::GUIEventAdapter::MOVE):
case(osgGA::GUIEventAdapter::PUSH):
case(osgGA::GUIEventAdapter::RELEASE):
{
if (_trackMouse)
{
osgViewer::View* view = dynamic_cast();
osgUtil::LineSegmentIntersector::Intersections intersections;
 

Re: [osg-users] Plugins errors for unsupported files

2016-10-18 Thread Robert Osfield
Hi Ricky,

The OSG uses the Chain Of Responsibility Design Pattern for the
plugins - so it's the plugins themselves to decide what formats they
can load.  This enables them to handle multiple formats if they can
support it.  From the description it sounds like the ffmpeg isn't
doing a good enough at deciding what it can or cannot load.

Robert.

On 18 October 2016 at 18:18, Riccardo Corsi  wrote:
> Hi Robert and all,
>
> I'm currently using the ffmpeg plugin to load some movies - it works just
> fine but my application started generating a lot of errors on console like
> this:
>> FFmpegImageStream::open : av_open_input_file() failed : AVERROR_NOENT
> every time an image has to be loaded.
>
> You can reproduce the issue with the modified osgMovie example in attach,
> which also loads the textured cow model.
>
> Digging a bit I've seen that's because the file reading mechanism tries to
> read from all the already loaded plugins, reagardless of their extension(s)
> support.
> See here:
> https://github.com/openscenegraph/OpenSceneGraph/blob/master/src/osgDB/Registry.cpp#L1176
>
> I thought that the extension supported by each plugin was checked before
> trying to use it.
> Besides the annoying errors on the console, wouldn't it be more efficient?
>
> Thanks,
> Ricky
>
> ___
> 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