OSG on steroids

General discussion regarding the OpenMW project.
For technical support, please use the Support subforum.
User avatar
scrawl
Posts: 2152
Joined: 18 Feb 2012, 11:51

OSG on steroids

Post by scrawl »

So, I came up with a two line change to OSG that results in a decent speed up for us (about 10% in my test). I don't know if the proposed patch will be merged upstream, it could be problematic from a backwards compatibility standpoint. Either way, the change should be totally safe for OpenMW (famous last words) so feel free to use my OSG fork here and enjoy some extra frames. (Edit: updated link)

In this fork I've also changed the default for OSG_USE_FLOAT_MATRIX to ON so you do not have to mess with cmake settings to get the most optimal performance.

Note you can install different builds of OSG locally, without conflicting with the system wide install. I do it like this:

Code: Select all

# while building OSG
cmake .. -DCMAKE_INSTALL_PREFIX=./install

# while building OpenMW
rm CMakeCache.txt
cmake .. -DCMAKE_PREFIX_PATH=<path/to/install> -DCMAKE_LIBRARY_PATH=<path/to/install>/lib64/ -DCMAKE_INCLUDE_PATH=<path/to/install/>include

# to make sure that OSG finds its plugins, add <path/to/install>/lib64/ to LD_LIBRARY_PATH
Last edited by scrawl on 10 Mar 2016, 19:14, edited 2 times in total.
User avatar
raevol
Posts: 3093
Joined: 07 Aug 2011, 01:12
Location: Caldera

Re: OSG on steroids

Post by raevol »

I hope they merge it! Is it something we will see rolled into releases or dailies if they don't?
User avatar
scrawl
Posts: 2152
Joined: 18 Feb 2012, 11:51

Re: OSG on steroids

Post by scrawl »

It was just rejected, so I guess we have a real fork on our hands now. Bring on the pitchforks!

On the bright side, now I can work on more fun optimizations like this one where I don't have to worry about breaking existing OSG applications.
Is it something we will see rolled into releases or dailies
0.37 will stay as is for now (way too late to make more changes). For future releases and daily builds: I wouldn't mind, but it's up to the respective packager.
User avatar
psi29a
Posts: 5356
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: OSG on steroids

Post by psi29a »

For k1ll's generic builds it could be interesting, but it'll be a hard push for Debian/Ubuntu. ;)
User avatar
scrawl
Posts: 2152
Joined: 18 Feb 2012, 11:51

Re: OSG on steroids

Post by scrawl »

Added one more small optimization (single precision quaternions), moved to the master branch, and added a README!

https://github.com/scrawl/osg/
User avatar
raevol
Posts: 3093
Joined: 07 Aug 2011, 01:12
Location: Caldera

Re: OSG on steroids

Post by raevol »

scrawl wrote:It was just rejected
Whaaaaat. :( What's the story here? Is there any way we could get the extra frames but preserve backwards compatibility? It seems like maintaining a fork is going to be a huge headache...
User avatar
sjek
Posts: 442
Joined: 22 Nov 2014, 10:51

Re: OSG on steroids

Post by sjek »

What's the story here?
well it's no use on their angle if somebody at videocard, nasa or some other research (maybe those, dunno, opengl specialised industry engine) starts ratching their head if the program doesn't suprisingly compile or work :mrgreen:
User avatar
Ace (SWE)
Posts: 887
Joined: 15 Aug 2011, 14:56

Re: OSG on steroids

Post by Ace (SWE) »

I guess I'll be switching my Windows builds over to Scrawls fork after the current release period is over, no use running core OSG if there's an optimized version available after all.
User avatar
jvoisin
Posts: 303
Joined: 11 Aug 2011, 18:47
Contact:

Re: OSG on steroids

Post by jvoisin »

Scrawl, are you sure that you want to maintain your own fork of OSG? It seems like a lot of work.
User avatar
scrawl
Posts: 2152
Joined: 18 Feb 2012, 11:51

Re: OSG on steroids

Post by scrawl »

It seems like maintaining a fork is going to be a huge headache...
It seems like a lot of work.
Not really. The patches so far are just a couple of lines each, easy to maintain and easy to transplant between branches if needed. I might go for more wide-ranging changes if there are big gains associated with that but the general plan is to diverge as little as possible, and try to get patches in upstream where possible.

On topic: Found out that most of the time in osg::computeLocalToWorld and osg::computeWorldToLocal (used a lot in our skinning and particle system code) is spent in dynamic_cast's.
dynamic_cast.png
My patch uses the Node::asCamera() instead of a dynamic cast. Doesn't really improve the design issue but much faster:
ascamera.png
Post Reply