[osg-users] [osgPlugins] Plugin vrml
Hello, I compiled OpenSceneGraph-3.0.1 with the vrml plugin with Visual Studio 2010. I compiled openvrml-0.18.9 with boost_1_47. When I try to load a vrml model (osgviewer.exe object.wrl), I have this error : FindFileInPath() : trying C:\Osg_Source\OpenSceneGraph\bin\osgPlugins-3.0.1\osgdb_vrml.dll ... FindFileInPath() : USING C:\Osg_Source\OpenSceneGraph\bin\osgPlugins-3.0.1\osgdb_vrml.dll DynamicLibrary::failed loading osgPlugins-3.0.1/osgdb_vrml.dll Warning: Could not find plugin to read objects from file C:\Osg_Source\OpenSceneGraph\bin\object.wrl. Previously,I compiled OpenSceneGraph-3.0.1 with the vrml plugin with Visual Studio 2008. I compiled openvrml-0.17.12 with boost_1_38. The loading of vrml files worked fine. Does someone compile OpenSceneGraph-3.0.1 with the vrml plugin with visual studio 2010?With which version of OpenVRML and boost? Thank you! Cheers, lucie -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=52291#52291 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fedora 18 with nVidia driver: OSG crashes session
Hi Robert, No luck: Both osgviewer and my (debug build) app bring down the session even running under gdb. Running my app in its non-GUI mode that brings up a stand-alone OSG window doesn't kill the session. Instead I get: Code: Error: Not able to create requested visual. GraphicsWindow has not been created successfully. Error: Not able to create requested visual. GraphicsWindow has not been created successfully. Viewer::realize() - failed to set up any windows I don't know if that is helpful. We probably need to wait for someone else to chime in on whether OSG on F18+nVidia is working for them. BTW the current nvidia driver is 304.64-2.fc18. I think later drivers may be available in an rpmfusion testing repository in case we want to try that route. Cheers, Stuart[/code] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=52292#52292 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Shadow Volumes integration
Hi, me and my coleague have developed number of Shadow Volume shadow algorithms and we would like to contribute them one day to OSG. To mention the reason for Shadow Volumes: They are often used in CAD, etc. as they work in screen space, thus they do not suffer with aliasing/resolution problems of Shadow Map-based algorithms. Surely, you pay the quality by the speed. But sometimes, you simply can not tolerate shadow artifacts and performance of shadow volumes on today graphics cards is basically excellent (in my eyes). My questions (probably on Robert) to best fit with OSG design: - My implementation covers number of methods (7-10 planned, 2 in developement, 4 finished) starting from simple cpu implementations and finishing by geometry shader and OpenCL implementations (silhouette based approaches). Thus I have family of classes like Occluder, OccluderGroup, ShadowDataBuilder, CpuSilhouetteDataBuilder, OpenCLSilhouetteOccluder (12 at the moment, and more on the way). I was considering to append them to osgShadow library, but I am worrying about some name clashes as, for instance, Occluder or ShadowDataBuilder are too general names and developers of Shadow Maps might (1) want to use them or (2) they might cause some confusion as there is already, for instance, OccluderGeometry class. Would you prefer to: (a) do not worry about clashes and simply use Occluder name as it is still not in use in osgShadow (the same with all other classes). (b) to create namespace osgShadowVolume and make ecosystem of classes of shadow maps and shadow volumes distinct - they really does not have much in common and probably only share just two abstract base classes: osgShadow::ShadowedScene and osgShadow::ShadowTechnique. Having two separate namespaces may make even doc more understandable because when looking for a particular class, I will look into the appropriate namespace and not to the mix of both shadow approaches. (c) prepend Occluder by a prefix SV, e.g. SVOccluder, SVOccluderGroup (d) prepend Occluder by ShadowVolume prefix, e.g. ShadowVolumeOccluder, ShadowVolumeVertexExtrusionDataBuilder, ShadowVolumeGeometryShader2DManifoldSilhouetteOccluder. I am just not sure if some names would not lost readability - 4 words in class name seems acceptable to me but adding two more seems too much. And surely, I would need to think how to make the longest names a little bit shorter - the last class still does not exist, but its full name would not be acceptable. (e) postpone the decision I am refactoring my code now so any suggestions welcomed. John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fedora 18 with nVidia driver: OSG crashes session
Hi Stuart, The GraphicsWindow warnings shout out that GLX is not set up correctly. This really doesn't look like an OSG specific issue so I'd recommend checking Fedora support forums for bug reports/advice how to fix things. Good luck, Robert. On 31 January 2013 09:45, Stuart Mentzer osgfo...@tevs.eu wrote: Hi Robert, No luck: Both osgviewer and my (debug build) app bring down the session even running under gdb. Running my app in its non-GUI mode that brings up a stand-alone OSG window doesn't kill the session. Instead I get: Code: Error: Not able to create requested visual. GraphicsWindow has not been created successfully. Error: Not able to create requested visual. GraphicsWindow has not been created successfully. Viewer::realize() - failed to set up any windows I don't know if that is helpful. We probably need to wait for someone else to chime in on whether OSG on F18+nVidia is working for them. BTW the current nvidia driver is 304.64-2.fc18. I think later drivers may be available in an rpmfusion testing repository in case we want to try that route. Cheers, Stuart[/code] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=52292#52292 ___ 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] [osgPlugins] Plugin vrml
On Thu, Jan 31, 2013 at 9:56 AM, lucie lemonnier lucielemonn...@hotmail.frwrote: Hello, I compiled OpenSceneGraph-3.0.1 with the vrml plugin with Visual Studio 2010. I compiled openvrml-0.18.9 with boost_1_47. When I try to load a vrml model (osgviewer.exe object.wrl), I have this error : FindFileInPath() : trying C:\Osg_Source\OpenSceneGraph\bin\osgPlugins-3.0.1\osgdb_vrml.dll ... FindFileInPath() : USING C:\Osg_Source\OpenSceneGraph\bin\osgPlugins-3.0.1\osgdb_vrml.dll DynamicLibrary::failed loading osgPlugins-3.0.1/osgdb_vrml.dll Warning: Could not find plugin to read objects from file C:\Osg_Source\OpenSceneGraph\bin\object.wrl. Make sure that the OpenVRML DLLs are in the path too if you didn't use static OpenVRML. The loading usually fails like that if it cannot find some DLL that some dependency of the plugin (or a dependency of a dependency ...) needs. That could be OpenVRML, Boost DLLs, etc. Jan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [osgPlugins] : Cannot compile DDS plugin GL_HALF_FLOAT not defined in this scope
Hi, I just tried to recompile on a RedHat Enterprise 5.3 with gcc 4.7.2 the OSG trunk. The compilation fails on ReaderWriterDDS.cpp on a error : 'GL_HALF_FLOAT' not declared in this scope. I use Mesa 6.5.1, it's the last release recognized by yum on RedHat (I know it's quite old... :-( ). In include/osg/Texture, GL_HALF_FLOAT is defined only if GL_ARB_half_float_pixel is not defined. The problem is that glext.h does define GL_ARB_half_float_pixel, GL_HALF_FLOAT_ARB and GL_HALF_FLOAT_NV but not the GL_HALF_FLOAT. Adding to include/osg/Texture at line 400 : #ifndef GL_ARB_half_float_vertex #define GL_HALF_FLOAT0x140B #endif corrects the problem on this type of configuration. Does this mod induce any problems on other platforms ? What's your opinion ? Cheers, Christian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] : Cannot compile DDS plugin GL_HALF_FLOAT not defined in this scope
Hi Christian, I have had a look through the OSG code base and there is mix of GL_HALF_FLOAT, GL_HALF_FLOAT_NV and GL_HALF_FLOAT_ARB thanks to various submissions at different times. This obviously isn't ideal so I've replaced all the L_HALF_FLOAT_NV and GL_HALF_FLOAT_ARB usage with GL_HALF_FLOAT and changed the #define in include/osg/Texture to simply: #ifndef GL_HALF_FLOAT #define GL_HALF_FLOAT0x140B #endif Could you do an svn update and let me know how you get on. Thanks, Robert. On 31 January 2013 16:10, Christian Schulte christian.schu...@onera.fr wrote: Hi, I just tried to recompile on a RedHat Enterprise 5.3 with gcc 4.7.2 the OSG trunk. The compilation fails on ReaderWriterDDS.cpp on a error : 'GL_HALF_FLOAT' not declared in this scope. I use Mesa 6.5.1, it's the last release recognized by yum on RedHat (I know it's quite old... :-( ). In include/osg/Texture, GL_HALF_FLOAT is defined only if GL_ARB_half_float_pixel is not defined. The problem is that glext.h does define GL_ARB_half_float_pixel, GL_HALF_FLOAT_ARB and GL_HALF_FLOAT_NV but not the GL_HALF_FLOAT. Adding to include/osg/Texture at line 400 : #ifndef GL_ARB_half_float_vertex #define GL_HALF_FLOAT0x140B #endif corrects the problem on this type of configuration. Does this mod induce any problems on other platforms ? What's your opinion ? Cheers, Christian ___ 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] [osgPlugins] Plugin vrml
Hi, I have all the dependancies dll that I need in my path. I think that a openvrml.dll has a bug because I tested the sdl-viewer.exe in the openvrml visual studio project and it crashes. Does someone compile OpenVrml with Visual Studio 2010 without problem?With which version of OpenVrml? Thank you! Cheers, lucie -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=52303#52303 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] How to acquire the screen coordinates of a 3D object?
Hi all, I want to know how to acquire the screen coordinates of a 3D object? posi is a Vec3 containing the coordinates information in WCS. Then I tried: osgViewer::Viewer viewer; osg::Camera* cam = viewer.getCamera(); osg::Matrix viewMatrix = cam-getViewMatrix(); posi = posi*viewMatrix; osg::Matrix projectionMatrix = cam-getProjectionMatrix(); posi = posi*projectionMatrix; Staring here, the codes do not work anymore: osg::Matrix windowMatrix = cam-getViewport()-computeWindowMatrix(); posi = posi*windowMatrix; Here the posi is supposed to be the right screen coordinates but it just does not work. Then how can I do with this? Sorry for this simple post but I don't know very well about OpenGL and OSG, and this question already occupied me two days. So thanks in advance for anyone who gives me a reply! ... Thank you! Cheers, Fan ohh newbie to OSG.. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=52304#52304 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to acquire the screen coordinates of a 3D object?
If you're new to the OSG, it is really helpful to look at the examples and also search the OSG forums for the problems you're looking for. Many of the questions most new folks ask, have already been addressed and answered in the forum. Hopefully the link below will help you... http://forum.openscenegraph.org/viewtopic.php?t=9172highlight= Shayne -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=52305#52305 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] Plugin vrml
On Thu, Jan 31, 2013 at 5:53 PM, lucie lemonnier lucielemonn...@hotmail.frwrote: Hi, I have all the dependancies dll that I need in my path. I think that a openvrml.dll has a bug because I tested the sdl-viewer.exe in the openvrml visual studio project and it crashes. Does someone compile OpenVrml with Visual Studio 2010 without problem?With which version of OpenVrml? I did use it with MSVC++ 2008 without problem. Haven't tried 2010, but I doubt it is a compiler problem. Where does it crash if you run it in a debugger? Also try a different/more basic VRML file, it could be choking on some VRML code that worked before in the older version of OpenVRML/Boost. However, I think that OpenVRML bugs would be better addressed in the OpenVRML mailing list than here. Jan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] Plugin vrml
I compiled openvrml-0.17.12 with visual studio 2008 without problem. When I try to compile openvrml-0.17.12 with visual studio 2010, I have this error in compilation several times : typename cannot be used outside a template declaration Does that tell you something? I will try to get some responses on OpenVRML mailing list. Thank you! lucie -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=52307#52307 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fedora 18 with nVidia driver: OSG crashes session
Hi Robert, You were right: the problem was broader than OSG. The fix was to modify /etc/X11/xorg.conf so that these 2 lines were in the Files section: Code: Section Files ModulePath /usr/lib64/nvidia/xorg ModulePath /usr/lib64/xorg/modules EndSection This comes from http://forums.fedoraforum.org/showthread.php?p=1626150 I hope this helps some other F18 users (until this bug is fixed). Cheers, Stuart -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=52308#52308 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadow Volumes integration
Hi John,
One suggestion, you could use nested namespaces, and then abbreviate
locally so it's easier to read. For example:
namespace osgShadow
{
namespace ShadowVolume
{
class Occluder { ... }
}
}
// then in some .cpp file where you need to use it:
namespace osgsv = osgShadow::ShadowVolume;
void someFunction()
{
osg::ref_ptrosgsv::Occluder occluder = new osgsv::Occluder;
}
That way we don't need a new separate top-level namespace, it shows
it's clearly a shadow technique so it's in osgShadow, yet it's separate
from the other osgShadow code so you prevent name clashes. And using the
abbreviated name locally helps with code that would become really
verbose and hard to read, while not being ambiguous like using
namespace ... in the case some classes have the same name eventually.
Just a suggestion, I don't know if Robert will like this style, he may
prefer one of your other suggestions but this is another alternative to
add to the mix.
J-S
On 31/01/2013 5:21 AM, PCJohn wrote:
Hi,
me and my coleague have developed number of Shadow Volume shadow algorithms
and we would like to contribute them one day to OSG.
To mention the reason for Shadow Volumes: They are often used in CAD, etc. as
they work in screen space, thus they do not suffer with aliasing/resolution
problems of Shadow Map-based algorithms. Surely, you pay the quality by the
speed. But sometimes, you simply can not tolerate shadow artifacts and
performance of shadow volumes on today graphics cards is basically excellent
(in my eyes).
My questions (probably on Robert) to best fit with OSG design:
- My implementation covers number of methods (7-10 planned, 2 in developement,
4 finished) starting from simple cpu implementations and finishing by geometry
shader and OpenCL implementations (silhouette based approaches). Thus I have
family of classes like Occluder, OccluderGroup, ShadowDataBuilder,
CpuSilhouetteDataBuilder, OpenCLSilhouetteOccluder (12 at the moment, and
more on the way). I was considering to append them to osgShadow library, but I
am worrying about some name clashes as, for instance, Occluder or
ShadowDataBuilder are too general names and developers of Shadow Maps might
(1) want to use them or (2) they might cause some confusion as there is
already, for instance, OccluderGeometry class.
Would you prefer to:
(a) do not worry about clashes and simply use Occluder name as it is still not
in use in osgShadow (the same with all other classes).
(b) to create namespace osgShadowVolume and make ecosystem of classes of
shadow maps and shadow volumes distinct - they really does not have much in
common and probably only share just two abstract base classes:
osgShadow::ShadowedScene and osgShadow::ShadowTechnique. Having two separate
namespaces may make even doc more understandable because when looking for a
particular class, I will look into the appropriate namespace and not to the
mix of both shadow approaches.
(c) prepend Occluder by a prefix SV, e.g. SVOccluder, SVOccluderGroup
(d) prepend Occluder by ShadowVolume prefix, e.g. ShadowVolumeOccluder,
ShadowVolumeVertexExtrusionDataBuilder,
ShadowVolumeGeometryShader2DManifoldSilhouetteOccluder. I am just not sure if
some names would not lost readability - 4 words in class name seems acceptable
to me but adding two more seems too much. And surely, I would need to think
how to make the longest names a little bit shorter - the last class still does
not exist, but its full name would not be acceptable.
(e) postpone the decision
I am refactoring my code now so any suggestions welcomed.
John
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
__
Jean-Sebastien Guay jean_...@videotron.ca
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fedora 18 with nVidia driver: OSG crashes session
Hi Stuart, On 31/01/13 20:45, Stuart Mentzer wrote: Hi Robert, No luck: Both osgviewer and my (debug build) app bring down the session even running under gdb. Running my app in its non-GUI mode that brings up a stand-alone OSG window doesn't kill the session. Instead I get: Code: Error: Not able to create requested visual. GraphicsWindow has not been created successfully. Error: Not able to create requested visual. GraphicsWindow has not been created successfully. Viewer::realize() - failed to set up any windows I agree with Robert, this doesn't look OSG-specific. Have you tried running 'glxinfo' and 'glxgears' to check if OpenGL support is available? Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] How to play Video on Android
Hi Jordi Torres, I build ffmpeg1.0 with OSG3.0.1 for Android (for armv7-a) device. When build example I am getting the errors like undefined reference to `av_log_set_callback. I Added USE_OSGPLUGIN(ffmpeg) to .h file and added ldflag as -losgdb_ffmpeg to Android.mk file. Here are the full error log Code: Install: libQCAR.so = libs/armeabi/libQCAR.so Compile++ arm: TrikonaQCAREdu = Tracker.cpp In file included from jni/osgModel.hpp:80:0, from jni/Tracker.cpp:3: /home/ttpl/Android/android-ndk-r8b/platforms/android-5/arch-arm/usr/include/jni.h:592:13: note: the mangling of 'va_list' has changed in GCC 4.4 Compile++ arm: TrikonaQCAREdu = osgModel.cpp In file included from jni/osgModel.hpp:80:0, from jni/osgModel.cpp:1: /home/ttpl/Android/android-ndk-r8b/platforms/android-5/arch-arm/usr/include/jni.h:592:13: note: the mangling of 'va_list' has changed in GCC 4.4 Compile++ arm: TrikonaQCAREdu = SampleUtils.cpp SharedLibrary : libTrikonaQCAREdu.so /home/ttpl/Android/OpenSceneGraph-3.0.1_GL1/osginstall/obj/local/armeabi/libosgdb_ffmpeg.a(ReaderWriterFFmpeg.o): In function `ReaderWriterFFmpeg': /home/ttpl/Android/OSG/ffmpeg_Plugin/OpenSceneGraph-3.0.1/src/osgPlugins/ffmpeg/ReaderWriterFFmpeg.cpp:107: undefined reference to `av_log_set_callback' /home/ttpl/Android/OSG/ffmpeg_Plugin/OpenSceneGraph-3.0.1/src/osgPlugins/ffmpeg/ReaderWriterFFmpeg.cpp:111: undefined reference to `av_lockmgr_register' /home/ttpl/Android/OSG/ffmpeg_Plugin/OpenSceneGraph-3.0.1/src/osgPlugins/ffmpeg/ReaderWriterFFmpeg.cpp:114: undefined reference to `av_register_all' /home/ttpl/Android/OSG/ffmpeg_Plugin/OpenSceneGraph-3.0.1/src/osgPlugins/ffmpeg/ReaderWriterFFmpeg.cpp:116: undefined reference to `avformat_network_init' /home/ttpl/Android/OpenSceneGraph-3.0.1_GL1/osginstall/obj/local/armeabi/libosgdb_ffmpeg.a(FFmpegParameters.o): In function `~FFmpegParameters': /home/ttpl/Android/OSG/ffmpeg_Plugin/OpenSceneGraph-3.0.1/src/osgPlugins/ffmpeg/FFmpegParameters.cpp:40: undefined reference to `av_dict_free' /home/ttpl/Android/OpenSceneGraph-3.0.1_GL1/osginstall/obj/local/armeabi/libosgdb_ffmpeg.a(FFmpegParameters.o): In function `FFmpegParameters': /home/ttpl/Android/OSG/ffmpeg_Plugin/OpenSceneGraph-3.0.1/src/osgPlugins/ffmpeg/FFmpegParameters.cpp:35: undefined reference to `av_dict_set' /home/ttpl/Android/OpenSceneGraph-3.0.1_GL1/osginstall/obj/local/armeabi/libosgdb_ffmpeg.a(FFmpegParameters.o): In function `osgFFmpeg::FFmpegParameters::parse(std::basic_stringchar, std::char_traitschar, std::allocatorchar const, std::basic_stringchar, std::char_traitschar, std::allocatorchar const)': /home/ttpl/Android/OSG/ffmpeg_Plugin/OpenSceneGraph-3.0.1/src/osgPlugins/ffmpeg/FFmpegParameters.cpp:62: undefined reference to `av_dict_set' /home/ttpl/Android/OSG/ffmpeg_Plugin/OpenSceneGraph-3.0.1/src/osgPlugins/ffmpeg/FFmpegParameters.cpp:55: undefined reference to `av_find_input_format' /home/ttpl/Android/OSG/ffmpeg_Plugin/OpenSceneGraph-3.0.1/src/osgPlugins/ffmpeg/FFmpegParameters.cpp:60: undefined reference to `av_dict_set' /home/ttpl/Android/OpenSceneGraph-3.0.1_GL1/osginstall/obj/local/armeabi/libosgdb_ffmpeg.a(FFmpegDecoderAudio.o): In function `osgFFmpeg::FFmpegDecoderAudio::open(AVStream*)': /home/ttpl/Android/OSG/ffmpeg_Plugin/OpenSceneGraph-3.0.1/src/osgPlugins/ffmpeg/FFmpegDecoderAudio.cpp:82: undefined reference to `avcodec_find_decoder' /home/ttpl/Android/OSG/ffmpeg_Plugin/OpenSceneGraph-3.0.1/src/osgPlugins/ffmpeg/FFmpegDecoderAudio.cpp:92: undefined reference to `avcodec_open' /home/ttpl/Android/OpenSceneGraph-3.0.1_GL1/osginstall/obj/local/armeabi/libosgdb_ffmpeg.a(FFmpegDecoderAudio.o): In function `decode_audio': /home/ttpl/Android/OSG/ffmpeg_Plugin/OpenSceneGraph-3.0.1/src/osgPlugins/ffmpeg/FFmpegDecoderAudio.cpp:24: undefined reference to `av_init_packet' /home/ttpl/Android/OSG/ffmpeg_Plugin/OpenSceneGraph-3.0.1/src/osgPlugins/ffmpeg/FFmpegDecoderAudio.cpp:28: undefined reference to `avcodec_decode_audio3' /home/ttpl/Android/OpenSceneGraph-3.0.1_GL1/osginstall/obj/local/armeabi/libosgdb_ffmpeg.a(FFmpegDecoderAudio.o): In function `osgFFmpeg::FFmpegPacket::clear()': /home/ttpl/Android/OSG/ffmpeg_Plugin/OpenSceneGraph-3.0.1/src/osgPlugins/ffmpeg/FFmpegPacket.hpp:45: undefined reference to `av_free_packet' /home/ttpl/Android/OpenSceneGraph-3.0.1_GL1/osginstall/obj/local/armeabi/libosgdb_ffmpeg.a(FFmpegDecoderAudio.o): In function `osgFFmpeg::FFmpegDecoderAudio::decodeFrame(void*, unsigned int)': /home/ttpl/Android/OSG/ffmpeg_Plugin/OpenSceneGraph-3.0.1/src/osgPlugins/ffmpeg/FFmpegDecoderAudio.cpp:356: undefined reference to `avcodec_flush_buffers' /home/ttpl/Android/OpenSceneGraph-3.0.1_GL1/osginstall/obj/local/armeabi/libosgdb_ffmpeg.a(FFmpegDecoderAudio.o): In function `osgFFmpeg::FFmpegPacket::clear()': /home/ttpl/Android/OSG/ffmpeg_Plugin/OpenSceneGraph-3.0.1/src/osgPlugins/ffmpeg/FFmpegPacket.hpp:45: undefined reference to `av_free_packet'
Re: [osg-users] [osgPlugins] : Cannot compile DDS plugin GL_HALF_FLOAT not defined in this scope
Hi Robert, my nightly build worked fine on RedHat 5.3(64bits) but also on CentOS 6.3(64bits), WinXP(32bits)¨and Win7(64bits). Thanks again for your quick answer and solution. By the way did you think about how to correct the math.h problem (regarding the round function, see discussion [osg-users] [osgPlugins] DDS Texture vanish with LINEAR_MIPMAP_LINEAR) ? In our environment I have recompiled all OSG 3.0.1 and trunk replacing math.h by cmath in include/osg/Math and didn't have any problems until now. Cheers, Christian Le 31/01/2013 17:28, Robert Osfield a écrit : Hi Christian, I have had a look through the OSG code base and there is mix of GL_HALF_FLOAT, GL_HALF_FLOAT_NV and GL_HALF_FLOAT_ARB thanks to various submissions at different times. This obviously isn't ideal so I've replaced all the L_HALF_FLOAT_NV and GL_HALF_FLOAT_ARB usage with GL_HALF_FLOAT and changed the #define in include/osg/Texture to simply: #ifndef GL_HALF_FLOAT #define GL_HALF_FLOAT0x140B #endif Could you do an svn update and let me know how you get on. Thanks, Robert. On 31 January 2013 16:10, Christian Schulte christian.schu...@onera.fr wrote: Hi, I just tried to recompile on a RedHat Enterprise 5.3 with gcc 4.7.2 the OSG trunk. The compilation fails on ReaderWriterDDS.cpp on a error : 'GL_HALF_FLOAT' not declared in this scope. I use Mesa 6.5.1, it's the last release recognized by yum on RedHat (I know it's quite old... :-( ). In include/osg/Texture, GL_HALF_FLOAT is defined only if GL_ARB_half_float_pixel is not defined. The problem is that glext.h does define GL_ARB_half_float_pixel, GL_HALF_FLOAT_ARB and GL_HALF_FLOAT_NV but not the GL_HALF_FLOAT. Adding to include/osg/Texture at line 400 : #ifndef GL_ARB_half_float_vertex #define GL_HALF_FLOAT0x140B #endif corrects the problem on this type of configuration. Does this mod induce any problems on other platforms ? What's your opinion ? Cheers, Christian ___ 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
