Hi Robert,
There isn't any easy way around this as there isn't a 1:1 mapping
between all file extensions and loaders can load files. The
extensions that a 3rd party library like ffmpeg supports isn't even
fixed w.r.t what version of the OSG is compiled against it. For
instance we might make an
OK, I see the design flaw I was missing. You have to load a plugin
library in order to see what extensions it handles, and plugins are only
loaded when needed. But "needed" can only be known if you have loaded
the plugin already. That's why there are so many hard coded extensions
in the
On 24 September 2016 at 16:37, Robert Spearman
wrote:
>
> I did get the plugin to be used by preloading the plugin library - had been
> using the wrong parameter.
>
> But my question is, why do I have to manually load a plugin? Why isn't this
> automatic if the
I did get the plugin to be used by preloading the plugin library - had
been using the wrong parameter.
But my question is, why do I have to manually load a plugin? Why isn't
this automatic if the extension to plugin mapping is already in the
registry?
Thanks,
Rob
Hi Rob,
osgmovie requires you to explictly preload the plugin if you don't use
the .ffmpeg suffix try:
osgmovie -e ffmpeg mymovie.qqq
This will load the plugin with the extension/name ffmpeg.
Robert.
On 23 September 2016 at 23:30, Rob Spearman wrote:
>
>
HI Rob,
The OSG uses a chain of responsibility pattern for the plugins and
will first attempt to load file by calling all of the currently loaded
plugins first, then if it fails then look for the plugin named the
same as the file extension, in your case .ogr.
There are also some built in aliases
I am trying to understand why osgDB::readImageFile( "abc.ogv" ) does not
get routed to the ffmpeg plugin. I get no image loaded and I see that
the readImage method of the plugin is not even called.
If I call osgDB::readImageFile( "abc.ogv.ffmpeg" ) it works, but that is
not going to be an
7 matches
Mail list logo