Package Details: openscenegraph-openmw-git 1:3.6.5.r16171.68c5c573d-2

Git Clone URL: (read-only, click to copy)
Package Base: openscenegraph-openmw-git
Description: Fork of OpenSceneGraph , with openmw-specific changes
Upstream URL:
Licenses: custom:OSGPL
Conflicts: openscenegraph
Provides: openscenegraph
Submitter: mupf
Maintainer: Lone_Wolf
Last Packager: Lone_Wolf
Votes: 2
Popularity: 0.92
First Submitted: 2017-09-21 22:14 (UTC)
Last Updated: 2023-10-27 14:21 (UTC)

Required by (42)

Sources (1)

Latest Comments

1 2 3 Next › Last »

Lone_Wolf commented on 2023-10-27 14:26 (UTC)

I synchronised build settings with those set in

Hopefully this will improve performance.

korreckj328 commented on 2023-04-25 20:29 (UTC)

This PKGBUILD works on aarch64.

Lone_Wolf commented on 2023-01-18 15:30 (UTC)

Tested buildtype Release- O3 optimization and found no downside, using it now.

collada-dom is now a hard dependency as I haven't found a way to make it optional without causing issues at runtime (missing libraries ).

As far as I can tell there's no way to add/remove something to openscenegraph dynamically at runtime. The only way to allow people to choose whether to have dae would be 2 separate packages : one with dae and one without .

Lone_Wolf commented on 2023-01-03 20:13 (UTC)

Doublechecked and it turns out I did make changes to the PKGBUILD, CMAKE_BUILD_TYPE RelWithDebInfo causes the issues with openmw trunk build.

About CMAKE_BUILD_TYPE=Release : unfortunately that uses -O3 .

On archlinux default optimization setting is -O2 and we don't want cmake to override that. has more info.

Lone_Wolf commented on 2023-01-03 17:14 (UTC)

This package is currently broken.

When I build against an older binary from 22-11-2022 openmw trunk has no issues with it.

A binary built from the exact same PKGBUILD today does lead to build failure for openmw . There haven't been any commits to osg default branch as far as I know, so the cause must be in some dependency, probably one from official repos.

unelsson commented on 2023-01-02 02:01 (UTC)

CMAKE_DISABLE_FIND_PACKAGE_FFmpeg=1 is important because . I haven't tested other CMAKE_DISABLE_FIND_PACKAGE -options.

Build type Release instead of None. Otherwise the performance is abysmal without the optimization flags. -D CMAKE_BUILD_TYPE=Release

There are other possible flags too, such as BUILD_OSG_APPLICATIONS, BUILD_OSG_EXAMPLES, which may be useful as off.

These are maybe not related to PKGBUILD, but optional changes for CMakeLists.txt. These should work with legacy (OLD) too: cmake_policy(SET CMP0072 NEW) add_link_options("-lGL")

unelsson commented on 2022-12-31 14:24 (UTC)

With the settings I mentioned earlier, the performance is abysmal with the latest OpenMW master branch. I wonder if CMP0072 is to blame or if it's something wrong with OpenMW.

unelsson commented on 2022-12-31 13:35 (UTC)

Most users also won't need BUILD_OSG_PLUGIN_DAE=1, as it's only for the Collada support. Is there a way to set it as optional?

unelsson commented on 2022-12-31 13:04 (UTC)

Btw, it's important to keep the option: PKGBUILD option "-D BUILD_OSG_PLUGINS_BY_DEFAULT=0". This hasn't been an absolute requirement earlier, but the new ffmpeg versions have removed some older functionality, e.g. av_free_packet, which would result in compilation failure with recent Manjaro builds.

As for cmake warnings, there are two policies that can be suppressed with CMakeLists.txt settings: cmake_policy(SET CMP0072 OLD) cmake_policy(SET CMP0106 OLD)

0072 is related to OpenGL versions, and setting it to NEW seems to result in a linking error. There is a cmake-error related to setting 0106 to NEW. Not setting these to anything specific will still probably compile, but with warnings.

unelsson commented on 2022-12-31 12:11 (UTC) (edited on 2022-12-31 12:11 (UTC) by unelsson)

COLLADA_BOOST_FILESYSTEM_LIBRARY set to NOTFOUND hints that the boost libraries weren't found. It's likely then that Collada depends on packages "boost" and/or "boost-libs", which makes sense as boost libraries are required by the OSG Collada plugin. You probably don't need both though: "boost" is development headers and "boost-libs" is runtime libraries.