[osg-users] Why isn't OpenSceneGraph used in games?

[Michael DeForge]

Can anyone explain to me why OpenSceneGraph isn't used in the games industry? There seems to be a large stigma surrounding OSG's performance, but is there really a problem here or not? OSG's own website claims "high performance". Is it really?

I've heard reports that people have had to keep their scene graphs shallow otherwise the lookups become too expensive. Makes sense, but is that enough to disqualify it for use in games?

My problem is that we have to render very large expanses of terrain in urban and rural environments. Think GTA, but for simulation research purposes, not entertainment.

I know OSG is used a lot in the simulation industry but I don't understand why when there's better tech out there.

I'm not trying to incite a flame war, I just want a straight honest answer. We're considering many different frameworks and engines right now and OSG seems like an iceberg that I'm trying to steer us away from.

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=66906#66906

[Chris Hanson]

AAA Games tend to not use ANY off the shelf engine technology, because they
like to be able to hack up and optimize everything down to the lowest level.

A scene graph such as OSG (or any other scene graph, really) tends to be
setup to work well for a large number of general cases, which means it may
not be totally optimal for one particular case.

Many games aren't totally free-roaming "sandbox" environments and as such,
can make optimizations to culling and LOD that a general purpose scene
graph does not support. I worked on a vis-sim project where the viewpoint
was literally "on rails". It could only move along certain paths. They
struggled a little bit with culling in their general-purpose scene graphs
(like OSG, but others too) that do full general purpose culling on every
frame. It just wasn't necessary.

Short answer: Scene Graphs of all kinds, including OSG, are often too
general for the violently performance-competitive realm of AAA game
development. Titles like those usually get customized tweaks put into the
actual GRAPHIC DRIVER in order to maximize performance. Long before they
got to that point, they would have wanted to strip down and redesign the
entire scene graph to remove ANYTHING they didn't need and optimize the
rest to one single goal and architecture.

OSG _does_ get used in a variety of independent and lower-tier games where
development time and cost and efficiency may have a higher importance than
absolute raw blistering performance.
​
For your project, OSG should be excellent. Look at Virtual Planet Builder
and possibly osgEarth for large free-roaming environments. osgEarth could
save you a decade of man-years of development of high-efficiency large
terrain area roaming algorithms and code, and it utilizes OSG in the most
high-performance ways available.


If you want consulting assistance on your project, that's what I do to put
bread on the table every week. ;)

[Trajce Nikolov NICK]

I will jump in with an add as well (please don't be mad at me, it is still
about OSG :-) )

Have a look at http://openig.compro.net

It is a very thin and simple Image Generator on top of OSG, opensource as
well, and it does have some features implemented that are common in the
game dev ( I am not a game dev expert though ). Things like Forward+
lighting, env/normal mapping, real physics based sensor support, 3D ocean,
3D clouds, true ephemeris model (some of these rely on commercial toolkits,
used in game dev as well). It also have support for bullet physics
(opensource too), support for large pageable terrain visual databases, even
the whole planet with osgearth. The great thing about this is that OSG is
making it easy to implement such projects in very short term cost effective
by the huge foundation of code and the large community, without the need of
big amount of cash as the others from the game dev will ask you for, like
Havok, Crytek .. It is opensource (oh well, Unreal is opensource too right
:-) )

So, although OSG is general purpose scenegraph, it is widely used in very
high-end simulation programs (I have seen it it Airbus, Williams Formula 1
and many other simulation companies). But, it is possible to narrow it into
more optimized direction and implement very hacky tricks known from the
game dev. Also, you can find here on this list gurus that can do that in
very professional way.

Just a few words

Cheers,
Nick

Post by Chris Hanson
AAA Games tend to not use ANY off the shelf engine technology, because
they like to be able to hack up and optimize everything down to the lowest
level.
A scene graph such as OSG (or any other scene graph, really) tends to be
setup to work well for a large number of general cases, which means it may
not be totally optimal for one particular case.
Many games aren't totally free-roaming "sandbox" environments and as such,
can make optimizations to culling and LOD that a general purpose scene
graph does not support. I worked on a vis-sim project where the viewpoint
was literally "on rails". It could only move along certain paths. They
struggled a little bit with culling in their general-purpose scene graphs
(like OSG, but others too) that do full general purpose culling on every
frame. It just wasn't necessary.
Short answer: Scene Graphs of all kinds, including OSG, are often too
general for the violently performance-competitive realm of AAA game
development. Titles like those usually get customized tweaks put into the
actual GRAPHIC DRIVER in order to maximize performance. Long before they
got to that point, they would have wanted to strip down and redesign the
entire scene graph to remove ANYTHING they didn't need and optimize the
rest to one single goal and architecture.
OSG _does_ get used in a variety of independent and lower-tier games where
development time and cost and efficiency may have a higher importance than
absolute raw blistering performance.
​
For your project, OSG should be excellent. Look at Virtual Planet Builder
and possibly osgEarth for large free-roaming environments. osgEarth could
save you a decade of man-years of development of high-efficiency large
terrain area roaming algorithms and code, and it utilizes OSG in the most
high-performance ways available.
If you want consulting assistance on your project, that's what I do to put
bread on the table every week. ;)
_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[Chris Hanson]

On Thu, Apr 21, 2016 at 11:10 AM, Trajce Nikolov NICK <

Post by Trajce Nikolov NICK
I will jump in with an add as well (please don't be mad at me, it is still
about OSG :-) )
Have a look at http://openig.compro.net

I'll second everything Nick says. We're getting going with OpenIG ourselves
and like osgEarth, it's a fantastic toolkit for this sort of thing. I
actually plan to use osgEarth AND OpenIG together in the future if possible.

Maybe if you describe more of what you're actually trying to do with your
project, we can make better recommendations about what toolkits to use.
--
Chris 'Xenon' Hanson, omo sanza lettere. ***@AlphaPixel.com
http://www.alphapixel.com/
Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 •
GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
Legal/IP • Code Forensics • Digital Imaging • GIS • GPS •
osgEarth • Terrain • Telemetry • Cryptography • LIDAR • Embedded • Mobile •
iPhone/iPad/iOS • Android
@alphapixel <https://twitter.com/alphapixel> facebook.com/alphapixel (775)
623-PIXL [7495]

[Terry Welsh]

Hi Michael,
After building 1.5 games using OSG, I'm surprised there aren't more.
OSG is probably built to be general-purpose first and high-performance
second. So this might scare away someone building an extremely
high-fidelity game. But for anything less OSG is fine. Also, being
free and having an extremely active community counts for a lot in my
book.

When I meet other devs they're usually surprised (sometimes shocked
and amazed) that I'm not using Unity or some other popular game
engine. So the main reason OSG isn't popular for games may be that
there is a huge swath of younger developers that don't know C++ or are
daunted at the idea of building a game with it.

From my first game, nothing about OSG registered as a big performance
problem unless you count osgParticle. I wrote my own OpenGL particle
systems, partly for better performance but also because I wanted some
features not available in osgParticle. The other big performance
issues came from shaders (purely a problem with OpenGL and graphics
hardware) and computing stuff that was off-screen (purely a game logic
problem).

Concerning your particular problem of rendering large areas of rural
and urban terrain, many of us on this list have done that at high
performance with OSG. OSG contains good tools for spatial organization
of your data and LOD. If you use all of it and avoid novice mistakes
(like putting transparency in your low-LOD models), you can get
seriously high performance. Of course, a game engine tuned for that
specific type of game should do more for you automatically and lead
you toward good decisions.
--
Terry Welsh
http://www.reallyslick.com

Message: 9
Date: Thu, 21 Apr 2016 16:07:12 +0200
Subject: Re: [osg-users] Why isn't OpenSceneGraph used in games?
Content-Type: text/plain; charset=UTF-8
Can anyone explain to me why OpenSceneGraph isn't used in the games industry? There seems to be a large stigma surrounding OSG's performance, but is there really a problem here or not? OSG's own website claims "high performance". Is it really?
I've heard reports that people have had to keep their scene graphs shallow otherwise the lookups become too expensive. Makes sense, but is that enough to disqualify it for use in games?
My problem is that we have to render very large expanses of terrain in urban and rural environments. Think GTA, but for simulation research purposes, not entertainment.
I know OSG is used a lot in the simulation industry but I don't understand why when there's better tech out there.
I'm not trying to incite a flame war, I just want a straight honest answer. We're considering many different frameworks and engines right now and OSG seems like an iceberg that I'm trying to steer us away from.

[Jannik Heller]

Hi,

Good point, but I think there's more to it than just performance. There are games using off-the-shelf scene graphs, for example Bethesda RPG games (Elder Scrolls, Fallout) are built on Gamebryo, which is a general purpose scene graph much like the OSG. (Note Gamebryo is a bit more than just a scenegraph, it also has game engine functionality e.g. physics, but that's besides the point).

https://en.wikipedia.org/wiki/Category:Gamebryo_engine_games

I think we can categorise most AAA devs into two groups:
1. People that want to roll everything on their own (and have the resources to do so)
and 2. People that want to build on a complete game engine (asset pipeline, physics engine, etc. think Unity, Unreal, Gamebryo).

OSG is kind of in a niche since it doesn't fit either group.

I also think there may be a stigma against free/open sources engines. (Maybe related to licensing and/or paid support).

Third, there is the fact that Direct3D has had a dominant position in the games industry for years, and OSG in built on OpenGL only.

Cheers,
Jannik

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=66912#66912

[Christian Buchner]

AAA Games tend to not use OpenGL much these days. At one pointOpenGL
development wasn't able to catch up to DirectX feature wise (simply too
much buerocracy in the decision making pipeline) - that's when OpenGL lost
developers to DirectX.

Also OpenGL driver quality on Windows was often way behind DirectX
implementations (I am looking at you, Intel)

Christian

[Chris Hanson]

On Thu, Apr 21, 2016 at 2:11 PM, Christian Buchner <

Post by Christian Buchner
AAA Games tend to not use OpenGL much these days. At one pointOpenGL
development wasn't able to catch up to DirectX feature wise (simply too
much buerocracy in the decision making pipeline) - that's when OpenGL lost
developers to DirectX.
Also OpenGL driver quality on Windows was often way behind DirectX
implementations (I am looking at you, Intel)

All very valid points. However, I will say that making titles that port to
Android and iOS (and maybe Linux, if anyone cares about your game on Linux)
makes OpenGL much more appealing these days.
--
Chris 'Xenon' Hanson, omo sanza lettere. ***@AlphaPixel.com
http://www.alphapixel.com/
Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 •
GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
Legal/IP • Code Forensics • Digital Imaging • GIS • GPS •
osgEarth • Terrain • Telemetry • Cryptography • LIDAR • Embedded • Mobile •
iPhone/iPad/iOS • Android
@alphapixel <https://twitter.com/alphapixel> facebook.com/alphapixel (775)
623-PIXL [7495]

[Robert Osfield]

Personally I don't feel it's games are critical to the success of scene
graph like the OpenSceneGraph.

Short lived game titles have very different focus that graphics application
that have a long shelf life. A game will be developed then have year of
big sales, then perhaps might be followed up with iterations of the game,
but each iteration may well have completely different hardware/driver
target as a focus.

For long lived graphics applications you need to maintain your software for
a decade, perhaps even two. Middleware and low level API's that such
applications depend upon have to live for similar periods of time if not
longer. OpenGL has worked pretty well as a long lived low API, we've been
able to incrementally add and evolve features based upon new iterations of
OpenGL. The OSG has evolved with OpenGL in this period.

Performance wise the OSG doesn't carry much overhead, if you are struggling
with performance it's almost always down to the scene graph that construct
not the library that is traversing that scene graph. If performance sucks
in your application look to the optimizing the scene graph composition.

Being a general purpose scene graph does mean that the art part routes into
the OSG are also more general purpose than you'd get for a professional
game engine suite. The later will be tailored for a particular art path
route, often with modelling tools specifically written for a particular
game engine. It's this art path route that is what will affect the
massively affect the performance and productivity for game developers
working in the specific domain that game engine targets. Out with that
sweet spot such game engine and modelling tool combo's will fail miserably.

There are parts of the OSG that don't perform well - the CPU path in
osgParticle for instance is well out of date. For modern applications I
wouldn't use it save for the precipitation effects which are shader based
and perform really well. For backwards compatibility sake it's still
useful to have the old osgParticle around.

Longer term Microsoft will loose even relevance, along with it Direct3D is
likely to wither away. Vulkan looks well poised to work even better across
all platforms than OpenGL has, that will depend upon driver quality and
middle-ware just as OpenGL has. Fingers crossed Intel etc. properly pull
their fingers out on this one. As Vulkan is lower level that OpenGL there
is potential for middle-ware becoming more important for application
developers to help abstract away from the complex low level management or
memory, threading and state.

Right now OpenGL is still relevant to many application developers, and with
it the OSG is still relevant to many graphics developers, they might have
as much to splash around as AAA game developers but they span a huge market
range. Had the OSG focused on games I suspect it would have just got
swamped by the rest of games market developers and lost relevance for the
rest of graphics developers around the world. The world still needs scene
graphs, as a standalone scene graph is still one of the best.

Robert.

[Alistair Baxter]

There’s a couple of major reasons OSG isn’t used in games much.



Probably the most important one is that it isn’t a complete game engine. Unreal, Cryengine, Unity (and also the likes of Gamemaker and Marmalade) all have favourable licensing conditions, and they can be used to start knocking out gameplay straight out of the gate. Potentially a lot of extra work would be needed to add the level of functionality needed for a 3D world action game which is available out of the box from the major engine manufacturers.



Secondly, it doesn’t come with game-specific tools, like an editor framework. And perhaps more importantly, core osg focuses on runtime importers rather than an offline asset conditioning pipeline from content creation packages, which is the favoured method of game asset production.



Thirdly, there has been some debate about the notion of using general-purpose scene graphs in game engines at all. Games tend to have controlled numbers of set types of object to render. You would need to set up a graph to reflect that, but if you’ve got the structure, why not apply your logic and render from that directly? Also, games will tend to use separate physics representations of geometry within a physics simulation that is used for raycasting and collition testing, rather than doing it with the graphics data, as osg provides. There was a high-profile article I read once entreating game developers to forsake unnecessary scene graphs, but I can’t seem to find it now for a citation.



And lastly, it is OpenGL-specific, and pluggable low-level rendering is common in major game engines. But in these days of OpenGL-ES ubiquity on mobile and tablets (and in Sony’s console ecosystem?), and Microsoft actively helping the ANGLE project and encouraging UWP developers to use it (https://github.com/MSOpenTech/angle/wiki ), that’s far less of a problem than it was 5 or 10 years ago.



But OSG is free, open source, portable and performant if you take the time to organise your graph efficiently.

[Alistair Baxter]

I found the article I was referring to. It has disappeared from its original source, but thankfully the Internet Archive has preserved a copy.



It made considerable waves in game engine programming back in 2006:



Tom Forsyth's "Scene Graphs Just Say No"

https://web.archive.org/web/20060821003215/http://home.comcast.net/~tom_forsyth/blog.wiki.html<https://web.archive.org/web/20060821003215/http:/home.comcast.net/~tom_forsyth/blog.wiki.html>





Which led to a significant discussion here:

http://www.gamedev.net/topic/464464-anti-scenegraphism-a-tale-of-tom-forsyths-scene-graphs-just-say-no/

[Thomas Hogarth]

I've made a few games in OSG and in Unity.

In my experience OSG blows Unity out of the water then it comes to render performance. Also with unity and game engines in general you have to learn a lot of quirks. Like learning that in unity turning objects on and off is actually really expensive (well if you're doing it to dozens of them per frame)

I think tools like Unity come into their own for prototyping and allowing non technical people to try out assets in a real world test environment. The issues I've had using osg for games is the assets designers often struggle to understand the dos and don't and you find you have to write them little standalone test apps.

Personally if I was making a simple little game I'd use unity. If I was planning some galactic scale simulation I'd use osg as a foundation.

The other big difference and one I think a lot of games developers don;t like is it's a lot of work to set up additional renders. Say I just want to quickly render a model as an icon. In a scene graph I need to set up a new camera, attach it to the graph, render a frame, deactivate the camera etc. In a game engine I can often just say redner this model with this camera to a texture right now.

Anyway that's my two cents.

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=66926#66926

[Shayne Tueller]

This is probably off topic but since OpenIG was brought up, I had a question about it...

Does OpenIG support CIGI? If it doesn't, adding it would go a long way in making it more mainstream in the IG community. It would sure make it easier for a host that is using CIGI to switch over...

Shayne

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=66927#66927

[Chris Hanson]

Not that I know of, but Nick can probably report on if there is a roadmap
that includes that.

Post by Shayne Tueller
This is probably off topic but since OpenIG was brought up, I had a question about it...
Does OpenIG support CIGI? If it doesn't, adding it would go a long way in
making it more mainstream in the IG community. It would sure make it easier
for a host that is using CIGI to switch over...
Shayne
------------------
http://forum.openscenegraph.org/viewtopic.php?p=66927#66927
_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

--
Chris 'Xenon' Hanson, omo sanza lettere. ***@AlphaPixel.com
http://www.alphapixel.com/
Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 •
GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
Legal/IP • Code Forensics • Digital Imaging • GIS • GPS •
osgEarth • Terrain • Telemetry • Cryptography • LIDAR • Embedded • Mobile •
iPhone/iPad/iOS • Android
@alphapixel <https://twitter.com/alphapixel> facebook.com/alphapixel (775)
623-PIXL [7495]

[Michael DeForge]

robertosfield, thanks for stopping by and weighing in. I agree, the scene graph itself is likely the performance bottleneck. We're going to do some additional profiling in the coming weeks. I have lots of ideas.

Thank you to all others as well. That "Just Say No to Scene Graphs" article is great, I've seen that before :) .

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=66933#66933