(http://gta.nongnu.org). This allows to read and write floating point
image data. Unlike other formats, GTA also allows very good compression
ratios for floating point data. The compression method can be selected
with the COMPRESSION option of the plugin.
"
VS2010 is not marked as MSVC100 but MSVC10. And CMake defines
MSVC_VERSION instead of MSVC_VER to indicate the version number. The
modification can find fbx sdk for VS2010 automatically now.
"
found that the include path has changed. By default, collada-dom now installs
its header files under /usr/local/include/collada-dom or/usr/include/collada-
dom. The attached FindCollada.cmake has been updated to look for these
locations in addition to the previous candidate locations."
I updated it to the correct addendum of 'freetype244' yesterday, but supposedly that was not forwarded to you by the forum-to-mail-gateway.
Find attached the corrected CMake module. "
12208 and 12231.
The windowing system specific headers under
include/osgViewer/api/<system> are again installed under
include/osgViewer/api/<system>
Works in recent ubuntu with cmake-2.8.4 and msvc2010 with cmake-2.8.2"
2nd - Script to use a 3rd party directory with basic libraries: libjpeg,libpng,libtiff,giflib,freetype,curl,gdal.
3rd - Change in the GLES library loading for Android. That should make GLES2 work properly.
4rth- Included two defines RGB8_OES and RGBA8_OES as a substitute in GLES for RGB8 and RGBA8
5th - OpenGL and GLSL version identification changed to recognize GLES versions properly
"
of atomic implementatition, making it possible to force the use of Mutex for OpenThreads::Atomic,
and as a consequence for use of Mutex for Referenced::ref/unref() counting.
"There is a redundant cmake code at the end of osgViewer cmake script. The install command is issued in SETUP_LIBRARY macro."
"I spotted this when i tried a make install on the android port :) I saw some weird copy commands of osgViewer headers.
I managed to get all osg headers copied to cmake_install_prefix/include upon make install, but i can't (yet) get the libraries to be copied to cmake_install_prefix/lib (see attached files)"
I also modified the CMake and pkgconfig files to append the _POSTFIX extenstion based on the CMAKE_BUILD_TYPE.
Additionally I fixed packaging/ld.so.conf.d/openscenegraph.conf.in to add a '/' betweeen the arguments since the CMAKE_INSTALL_PREFIX can't end with a '/'.
"
This feature has been introduced to cmake in 2.8.3, on older versions it should be ignored silently. I tested on Visual Studio 2008 with cmake 2.8.3 and 2.8.4.
See the screenshots for comparison [img]osg_solution.png[/img]
This needs few changes:
activate on global cmakelist.txt:
[code]set_property(GLOBAL PROPERTY USE_FOLDERS On)[/code]
set appropriate folder names for project type in osgMacroUtils.cmake:
[code]SET_TARGET_PROPERTIES(${CORELIB_NAME} PROPERTIES FOLDER "OSG Core")[/code]
similar for examples, applications"
"- In order to build against GLES1 we execute:
$ mkdir build_android_gles1
$ cd build_android_gles1
$ cmake .. -DOSG_BUILD_PLATFORM_ANDROID=ON -DDYNAMIC_OPENTHREADS=OFF
-DDYNAMIC_OPENSCENEGRAPH=OFF -DANDROID_NDK=<path_to_android_ndk>/
-DOSG_GLES1_AVAILABLE=ON -DOSG_GL1_AVAILABLE=OFF
-DOSG_GL2_AVAILABLE=OFF -DOSG_GL_DISPLAYLISTS_AVAILABLE=OFF -DJ=2
-DOSG_CPP_EXCEPTIONS_AVAILABLE=OFF
$ make
If all is correct you will have and static OSG inside:
build_android_gles1/bin/ndk/local/armeabi.
- GLES2 is not tested/proved, but I think it could be possible build
it with the correct cmake flags.
- The flag -DJ=2 is used to pass to the ndk-build the number of
processors to speed up the building.
- make install is not yet supported."
SETUP_EXE, in order to have a unique entry point to build the
libraries. With this changes the android integration will be less
painful (currently is a big IF(ANDROID) for each CMakeLists.txt) and
more maintainable in the future. I hope next submissions will be for
supporting android from my colleague Jorge.
"
I have attached a patch, against the trunk from 13:30 today, which consists of the following:
1. CMakeModules/FindOpenEXR.cmake: Look for libIlmThread and libIex as well. 2. src/osgPlugins/CMakeList.txt: Only include the exr subdirectory if both the OpenEXR and zip libraries were found. 3. src/osgPlugins/exr/CMakeLists.txt: Add ZIP_LIBRARY to TARGET_EXTERNAL_LIBRARIES."
I modified the OsgCPackConfig.cmake.in and OsgCPack.cmake files to expose access to select the package generator mechanism through cmake CPACK_GENERATOR option. The user can specify the type of package generator (i.e. rpms. deb, NSIS, tar, zip, etc) that they would like to use from the CPack supported packages/installation methods.
I also changed the CPACK_PACKAGE_FILE_NAME to use OSG_PACKAGE_FILE_NAME which contains the name of each component so all of the component packages can be generated without renaming the files.
This should make it even easier to create distribution packages for the various linux, windows and mac distribution methods supported by CPack."
changes from the DirectInput devices and add events to the event
queue. I've tested with the keyboard and joystick supports. Because of
only having a very old 6-button gamepad, I can't do more experiments.
Hope this will bring more ideas to those who face similar problems,
especially simulation game designers. :)
I didn't map all DirectInput key values to GUIEventAdapter key
symbols. Users may add more in the buildKeyMap() function freely. The
mouse handling operations are also ignored, but will be easily
improved in the same way of creating keyboard and joystick devices.
Please add a line:
FIND_PACKAGE(DirectInput)
in the CMakeLists of root directory. And in the examples/CMakeLists.txt:
IF(DIRECTINPUT_FOUND)
ADD_SUBDIRECTORY(osgdirectinput)
ENDIF(DIRECTINPUT_FOUND)
DirectX SDK 2009 is used here, but an older version like DX8 should
also work in my opinion.
"
But I also found rev. 11354 (from Wang Rui) added a change in OsgMacroUtils which adresses a similar issue: Wang told the "../../bin" prefix wasn't working. However I think the fix isn't correct because it checks the MSVC version instead of the CMake version. Here is my fix, against latest trunk (root CMakeLists.txt, and CMakeModules/OsgMacroUtils.cmake).
Tests I made:
| Unix Makefiles | MSVC 9 | MSVC 10 x64
---------------------------------------------------
CMake 2.4 | | OK | N/A
CMake 2.6.4 | | OK | N/A
CMake 2.8.0 | | OK | broken support?
CMake 2.8.2 | | OK | OK
"
changed extensions from .c to .cpp and got compiling as C files as part of the osg core library.
Updated and cleaned up the rest of the OSG to use the new internal GLU.
"changed the CmakeFiles for OpenThreads and the
osg-frameworks, so they are versioned by OPENSCENEGRAPH_SOVERSION. "
And from a later email:
"Attached you'll find a fixed version of ModulInstall.cmake. Hopefully it
works for old CMake-versions. I removed the offending line, and the
compile went fine on my end."
I added support to find libxml2 in the 3rdparty package if available.
Now this file can find all libraries from the 32/64bit VS2008sp1 dependency package except collada. I will add that later.
"
I don't understand the changes to ReaderWriterFBX.cpp - (i) strings.h isn't a standard header, (ii) the ISO-conformant form is _strnicmp (with the underscore). Does the existing code not compile for you? If not we'll have to do some #ifdef nastiness."
latest OSG source code with Visual Studio 2010 express, without
setting too many options and without facing unexpected errors. But at
present, the compilation process will fail because the INSTALL project
'cannot find' generated DLLs while copying files. I have looked into
the build directory and found that the places of generated file
folders were just different from previous VS versions. In this case,
the old hack in OsgMacroUtils.cmake may become invalid:
MACRO(HANDLE_MSVC_DLL)
#this is a hack... the build place is set to lib/<debug or
release> by LIBARARY_OUTPUT_PATH equal to OUTPUT_LIBDIR
#the .lib will be crated in ../ so going straight in lib by
the IMPORT_PREFIX property
#because we want dll placed in OUTPUT_BINDIR ie the bin folder
sibling of lib, we can use ../../bin to go there,
...
ELSE(NOT MSVC_IDE)
SET_TARGET_PROPERTIES(${LIB_NAME} PROPERTIES PREFIX
"../../bin/${LIB_PREFIX}${LIB_SOVERSION}-" IMPORT_PREFIX "../")
ENDIF(NOT MSVC_IDE)
ENDMACRO(HANDLE_MSVC_DLL)
Here the prefix "../../bin" may need to be fixed. I just modified it to:
IF(MSVC_VERSION LESS 1600)
SET_TARGET_PROPERTIES(${LIB_NAME} PROPERTIES PREFIX
"../../bin/${LIB_PREFIX}${LIB_SOVERSION}-" IMPORT_PREFIX "../")
ENDIF()
It should keep compatible with old MSVC versions. There are similar
fixes in the SETUP_PLUGIN and SETUP_EXE macros. I haven't tested them
on more platforms.
"
Mathieu Marache, he added the last missing piece to this puzzle.
I think it is safe to commit these changes to trunk, as the traditional
way via dylibs should work as before.
Here's some more info how to get frameworks:
With these modifications it is possible to compile frameworks on OS X,
when you set the Cmake-option OSG_COMPILE_FRAMEWORKS to true. If you
want to embed the frameworks in your app-bundle make sure to set
OSG_COMPILE_FRAMEWORKS_INSTALL_NAME_DIR accordingly.
You'll have to build the install-target of the generated xcode-projects
as this sets the install_name_dirs of the frameworks and plugins."
Windows. If the 3rdparty directory isn't available it will use the
directory names subversion uses such as 3rdParty_win32binaries_vs71
3rdParty_win32binaries_vs80sp1 3rdParty_win32binaries_vs90sp1. That
helps when as we are building both vs71 and vs80, and probably vs90 in
the future at the same time in addition to not having to rename the
directory once it is downloaded. It also adds the _i suffix to match
some of the libraries.
"
currently only Debug appends "d" so the Release and MinSizeWithDebInfo
(and MinSizeRel) all produce the same filenames. This set of changes
lets each build type have a cmake defined string appended, defaulting
to Release none, Debug d, RelWithDebInfo rd, MinSizeRel s. But a user
still can have Release, RelWithDebInfo, and MinSizeRel to produce the
same filenames. It does so by setting the preprocessor define
OSG_LIBRARY_POSTFIX in src/osgDB/CMakeLists.txt to one of the
previously defined cmake variables CMAKE_DEBUG_POSTFIX
CMAKE_RELEASE_POSTFIX CMAKE_RELWITHDEBINFO_POSTFIX
CMAKE_MINSIZEREL_POSTFIX. This method cuts down on the #ifdef _DEBUG
#else preprocessor directives in Registry.cpp as the extension is
always passed in OSG_LIBRARY_POSTFIX. That and __MINGW32__ didn't
have the _DEBUG check which looks like a bug."
- OsgMacroUtils.cmake, SETUP_LINK_LIBRARIES macro : allow linking with debug/release external libraries
- osgQt/CMakeLists.txt : fix the linking to Qt librairies + linking to debug Qt librairies if found
- examples/ qt examples : linking to debug Qt librairies if found"
synchronization, improve capture device support.
here how to use it to display a capture device:
osg::Options* options = new osg::Options;
options->setPluginStringData("captureWantedWidth", "800");
options->setPluginStringData("captureWantedHeight", "600");
options->setPluginStringData("captureWantedFps", "30");
options->setPluginStringData("captureVideoDevice", "USB Video Device" );
options->setPluginStringData("captureSoundDevice", "");
then
osgDB::readImageFile("capture.directshow", options)
you can use a graphedit application to list devices available in
directshow.
for classic avi file you just need to do a
osgDB::readImageFile("file.avi.directshow");
You will need of course to install the codec needed by directshow to
read the avi files.
I recommand this tool http://avicodec.duby.info/, that check which
video/sound codec is needed to play an avi file.
You can test it with the osgmovie example.
"
The collada dom Makefiles actually build a framework called Collada14Dom.framework (debug: Collada14Dom-d.framework). The current CMake rules, however, only look for collada14dom. Normally, the difference in case wouldn't matter but the rule fails on case sensitive HPFS partitions.
"
FREETYPE_INCLUDE_DIR_freetype2.
The error case was that during first cmake run (unspecified
ACTUAL_3RDPARTY_DIR) FindFreeType set these to xxx-NOTFOUND. After
specifying ACTUAL_3RDPARTY_DIR, Find3rdPartyDependencies warn't able
to change these (without FORCE).
I also added freetype237 to the library search list since it is what's
in my binary dependencies for vc90"
-I changed the SET of COLLADA_BOOST_INCLUDE_DIR to use findpath, so users may override this setting if they choose not to build against to precompiled boost libraries delivered with the Collada DOM.
-Changed daeRMaterials.cpp to prevent a compiler warning about a potentially uninitialized variable."
name of the top folder in each package to OpenSceneGraph-x.y.z
Noone else has had an opinion on whether compiler and it's version
should be part of the package filename on their platform/setup so I'll
leave it as is. That is - No action is taken for compilers other than
msvc but one can easily add this information to the cmake cache
regardless of platform.
"
streamlined for tgz and has most of the features that Robert, J-S and
Sukender requested in december. I have an idea of how to discover the
vc80 sp1 or not but haven't had time to implement. The script is
completely reworked and now doesn't include cmakes' bundled
CPack.cmake script at all. In summary:
* filenames are
<package>-<osgversion>-<platform>-<arch>[-compiler]-<configuration>.tar.gz,
ex. libopenscenegraph-2.7.9-Linux-i386-Release.tar.gz,
libopenthreads-dev-2.7.9-win32-x86-vc80sp1-Debug.tar.gz
* targets (projects in msvs) are generated for each specified
component, a target that packages everything that is installed
(openscenegraph-all) and there's a target for running all other
packaging targets (Package ALL on msvs, package_ALL in unix
makefiles).
* It is possible to set the compiler in ccmake (cmake-gui, whatever you use)
* the top folder in packages is the same for all packages (OpenSceneGraph-x.y)
* the packaging support is limited with cmake-2.6.0 and not as
dynamic. With cmake-2.6.1 and later building the gdal plugin (for
example) will create a package_libopenscenegraph-gdal target. With
cmake-2.6.0 only the ones that are always built (libopenscenegraph,
libopenscenegraph-dev, openscenegraph, libopenthreads,
libopenthreads-dev
* i found a better way to decide whether cpack is available to guard
the BUiLD_OSG_PACKAGES option"
Updated all doxyfiles under doc/Doxyfiles. They are now all processed
by cmake but make targets are only generated for
OpenSceneGraphReferenceDocs and OpenThreadsReferenceDocs. The others
can be run with doxygen directly in <builddir>/doc.
Fixed a copy-paste in openthreads sproc and pthreads CMakeLists
Added the osg logo to the html footers
Added possibility to get generation of chm files.
CMakeLists (toplevel):
Added install of osg and ot reference docs. This also generates
packaging targets of openscenegraph-doc and openthreads-doc if you
have packaging enabled
Removed the unused USING_OP_OT_TRIPLE_SET since there was no way of
enabling it anyway
Removed BUILD_REF_DOCS. IMO it was redundant - BUILD_DOCUMENTATION
does the same thing and we get that anyway from including
Documentation.cmake.
OsgCPack.cmake:
Removed generation of PACKAGE_SRC for msvc
Added special handling for -doc packaging targets - they don't require
system, architecture or compiler"
Better package naming. example
openscenegraph-core-2.7.7-Linux-i386.tar.gz on my ubuntu laptop and
openscenegraph-core.2.7.7-win32-x86-vc80.tar.gz on winxp.
CMakers will not get options for selecting compression format. TGZ
goes for all platforms (on win32 I use 7zip)
The wrappers is now given the COMPONENT name
libopenscenegraph-wrappers. Feel free to change the name.
On windows with visual studio the OsgCPack script make some efforts to
discover the compiler used but support is a bit poor so I've given
CMake acces to OSG_CPACK_COMPILER to provide some mean to name the
compiler.
stop
The platform part is taken from CMAKE_SYSTEM_NAME and for windows I
change this to win32 or win64 based on CMAKE_CL_64. This might not be
necessary if the arch part has that information. This information is
taken from CMAKE_SYSTEM_PROCESSOR. I only have 32bit here so if some
of you could uncomment line 15,16 in OsgCPack.cmake and report what
cmake report it would be nice. I'm especially interested anything but
win32 and linux32"
