Re: [osg-users] Segfault when using addChild on Group object

[Jannik Heller]

Hi,

turns out that my error was caused by mismatched OSG headers / libs. I had a 
LD_LIBRARY_PATH in my .bashrc that pointed to a different OSG installation than 
the one in /usr. Could you double check what libraries your executable is 
linked against. To do so run:

Code:

ldd ./executable



Example:libosg.so.130 => /usr/lib/x86_64-linux-gnu/libosg.so.130 
(0x7ff47bdd9000)

These libraries should match the include path (-I) to the OSG headers. Don't 
mix headers/libs of a different version.

Cheers
Jannik

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





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Segfault when using addChild on Group object

[Jannik Heller]

Hi,

I confirm that your example crashes. I actually reduced the code even further 
and still got a crash:


Code:

#include 
#include 

#include 

int main()
{
  osg::ref_ptr foo = new osg::Group;
  foo->addChild(new osg::Group);

  std::cout << "foo has " << foo->getNumChildren() << " children" << std::endl;
}




Seems to be a memory corruption going on... I'm sure there's just a really 
silly mistake in the code but I can't spot it for the life of me.

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





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

[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





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Segfault when using addChild on Group object

[Andre Sanchez]

Hi,

I'm trying to use OpenSceneGraph on my machine running.

When I run the following code, I always get a segfault on the line with 
addChild:


Code:

#include 
#include 
#include 
#include 

int main(int argc, char** argv) {

  osg::ref_ptr a = new osg::Node();
  osg::ref_ptr b = new osg::Group();

  b->addChild(a.get());

  osgViewer::Viewer viewer;
  viewer.setSceneData(b);

  viewer.run();

  return 0;
}




Any ideas why this would happen? I'm on Ubuntu 14.04.4, and using the 
libopenscenegraph-dev package from apt-get.

Thanks,
Andre

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





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] How is this foliage artifact called and how to fix it?

[Christian Buchner]

Placing the foliage into a later render bin (e.g. the transparent bin, #10)
than most other objects would help.
Christian


2016-04-22 18:08 GMT+02:00 Chris Hanson :

> I believe your texture filtering mode is generating intermediate alpha
> values, which then blend a portion of the distant background in before the
> other "face" of the tree is drawn behind.
>
> Switching to GL_NEAREST will probably avert this, but will look ugly in
> other ways.
> ​
> Alpha to coverage might help you here:
> http://www.humus.name/?page=3D=61
>
> ___
> 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] How is this foliage artifact called and how to fix it?

[Chris Hanson]

I believe your texture filtering mode is generating intermediate alpha
values, which then blend a portion of the distant background in before the
other "face" of the tree is drawn behind.

Switching to GL_NEAREST will probably avert this, but will look ugly in
other ways.
​
Alpha to coverage might help you here: http://www.humus.name/?page=3D=61
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

[Chris Hanson]

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

On Fri, Apr 22, 2016 at 9:50 AM, Shayne Tueller 
wrote:

> 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
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
Chris 'Xenon' Hanson, omo sanza lettere. xe...@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  facebook.com/alphapixel (775)
623-PIXL [7495]
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

[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





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

[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





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Custom GraphicsContext Segmentation Fault when using Multithreading

[Philipp Meyer]

Hi,

I tried to orientate on "PixelBufferX11" when creating the EGLGraphicsContext, 
and I noticed that PixelBufferX11 calls the "init()" method in the constructor 
as well as in the "realizeImplementation" method, if necessary. So my call to 
"realizeImpl" in the constructor is pretty much just resembling that structure.

It indeed seems like there is no graphics context when the graphics thread 
starts, however, I fail to understand why this only happens when in 
multithreading mode. I studied the PixelBufferX11 source code but couldnt find 
anything that would explain the error in my implementation. Unfortunately I 
cannot test the original GraphicsContext on my realtime machine because it cant 
run it, however, it works fine on my ubuntu desktop machine that I use for 
programming.

Thank you!

Cheers,
Philipp

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





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

[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





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/








___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Custom GraphicsContext Segmentation Fault when using Multithreading

[Robert Osfield]

On 22 April 2016 at 09:46, Sebastian Messerschmidt <
sebastian.messerschm...@gmx.de> wrote:

> Hi Robert,
>
> He edited the original post.
>
> I've attached it for you.
>

Thanks Sebastian.  I went to the forum page but it didn't appear.  Do you
need to be logged in to see attachments?

I've had a quick look over the implementation, the only oddity I spotted
was call realizeImplementation() from the constructor.  This is redundant
as the viewer will call GraphicsContext::realize() automatically for you
when viewer.realize() is called.None of the other GraphicsContext
implementations call realize in the constructor so see not reason why it
should be required in this instance.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] [osgPlugins] gstreamer plugin failing to build in osg 3.4.0

[Ben Woods]

Hi,

I am attempting to build OpenSceneGraph 3.4.0 on FreeBSD 10.2 (with clang 3.4.1 
and cmake 3.5.2).

The osgdb_gstreamer is failing during the build with the following error (full 
build log also attached):


> [ 94%] Linking CXX shared module 
> ../../../lib/osgPlugins-3.4.0/osgdb_gstreamer.so
> cd /wrkdirs/usr/ports/graphics/osg/work/.build/src/osgPlugins/gstreamer && 
> /usr/local/bin/cmake -E cmake_link_script 
> CMakeFiles/osgdb_gstreamer.dir/link.txt --verbose=1
> /usr/bin/c++  -fPIC -O2 -pipe -fstack-protector -fno-strict-aliasing -Wall 
> -Wparentheses -Wno-long-long -Wno-import  -Wreturn-type -Wmissing-braces 
> -Wunknown-pragmas -Wunused -Wno-overloaded-virtual -Wno-variadic-macros -O2 
> -pipe -fstack-protector -fno-strict-aliasing  -fstack-protector -shared  -o 
> ../../../lib/osgPlugins-3.4.0/osgdb_gstreamer.so 
> CMakeFiles/osgdb_gstreamer.dir/GStreamerImageStream.o 
> CMakeFiles/osgdb_gstreamer.dir/ReaderWriterGStreamer.o 
> ../../../lib/libosgDB.so.3.4.0 ../../../lib/libosgUtil.so.3.4.0 
> -lgstreamer-1.0 -lgobject-2.0 -lglib-2.0 -lintl -lgstapp-1.0 -lgstbase-1.0 
> -lgstreamer-1.0 -lgobject-2.0 -lglib-2.0 -lintl -lgstpbutils-1.0 
> -lgstreamer-1.0 -lgobject-2.0 -lglib-2.0 -lintl /usr/local/lib/libglib-2.0.so 
> /usr/local/lib/libgobject-2.0.so ../../../lib/libosg.so.3.4.0 
> ../../../lib/libOpenThreads.so.3.3.0 -pthread -lm -lz /usr/local/lib/libGL.so 
> -lgstapp-1.0 -lgstbase-1.0 -lgstpbutils-1.0 /usr/local/lib/libglib-2.0.so 
> /usr/local/lib/libgobject-2.0.so -
 Wl,-rpath,/wrkdirs/usr/ports/graphics/osg/work/.build/lib:/usr/local/lib: 
> /usr/bin/ld: cannot find -lgstreamer-1.0
> c++: error: linker command failed with exit code 1 (use -v to see invocation)
> *** Error code 1


Any ideas how to fix this? It appears to be because the gstreamer libraries are 
not linked into this build with -L/usr/local/lib, however I can confirm they 
are installed in that directory under the gstreamer-1.0 sub-directory.

Thank you in advance,
Ben

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




Attachments: 
http://forum.openscenegraph.org//files/osg_340log_112.txt


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] [osgPlugins] osgjs failing to build in osg 3.5.1

[Ben Woods]

Hi,

I am trying to build openscenegraph 3.5.1 on FreeBSD (with clang 3.4.1 and 
cmake 3.5.2), but I am getting the following error:


> [ 92%] Building CXX object 
> src/osgPlugins/osgjs/CMakeFiles/osgdb_osgjs.dir/Base64.o
> cd /wrkdirs/usr/ports/graphics/osg-devel/work/.build/src/osgPlugins/osgjs && 
> /usr/bin/c++   -Dosgdb_osgjs_EXPORTS 
> -I/wrkdirs/usr/ports/graphics/osg-devel/work/OpenSceneGraph-3.5.1/include 
> -I/usr/local/include 
> -I/wrkdirs/usr/ports/graphics/osg-devel/work/.build/include -O2 -pipe 
> -fstack-protector -fno-strict-aliasing -Wall -Wparentheses -Wno-long-long 
> -Wno-import -Wreturn-type -Wmissing-braces -Wunknown-pragmas -Wunused 
> -Wno-overloaded-virtual -O2 -pipe -fstack-protector -fno-strict-aliasing 
> -fPIC -o CMakeFiles/osgdb_osgjs.dir/Base64.o -c 
> /wrkdirs/usr/ports/graphics/osg-devel/work/OpenSceneGraph-3.5.1/src/osgPlugins/osgjs/Base64.cpp
> c++ -O2 -pipe -fstack-protector -fno-strict-aliasing-fstack-protector 
> /wrkdirs/usr/ports/graphics/osg-devel/work/OpenSceneGraph-3.5.1/src/osgPlugins/osgjs/WriteVisitor.cpp
>   -o 
> /wrkdirs/usr/ports/graphics/osg-devel/work/OpenSceneGraph-3.5.1/src/osgPlugins/osgjs/WriteVisitor
> In file included from 
> /wrkdirs/usr/ports/graphics/osg-devel/work/OpenSceneGraph-3.5.1/src/osgPlugins/osgjs/WriteVisitor.cpp:1:
> /wrkdirs/usr/ports/graphics/osg-devel/work/OpenSceneGraph-3.5.1/src/osgPlugins/osgjs/WriteVisitor:5:10:
>  fatal error: 'osg/Image' file not found
> #include <­osg/Image>
>  ^
> 1 error generated.
> *** Error code 1



Any ideas what the problem could be?

Thanks in advance,
Ben

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





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Custom GraphicsContext Segmentation Fault when using Multithreading

[Sebastian Messerschmidt]

Hi Robert,

He edited the original post.

I've attached it for you.

Cheers
Sebastian

Hi Phillipp,

The source didn't make it through the osg-users mailing list so can't 
comment about the implementation side.


From the error description in the first post it's clear that the 
graphics context is not current when the graphics thread starts 
running.  osgViewer specifically calls makeCurrent() to ensure that 
the context is current, if this fails then you'd see issues like you 
are seeing.  Whether this is the issue or not I can not say.


I could see being able to create an OSG application without X11 would 
be useful.  Any chance that you could open source the implementation 
and submit for inclusion with the core osgViewer?  This route would 
help others help refine the implementation.  The first step would 
follow would be to make an small example program with all the required 
classes in it then get this working, and then once it's refined enough 
move the GraphicsContext implementation into osgViewer to sit 
alongside the rest of the implementation.


Cheers,
Robert.


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


/*
 * EGLGraphicsWindow.cpp
 *
 *  Created on: Apr 12, 2016
 *  Author: ubuntu
 */

#include "EGLGraphicsContext.h"

#include 
using namespace std;

EGLGraphicsContext::EGLGraphicsContext(osg::GraphicsContext::Traits* traits) :
  osg::GraphicsContext(), _initialized(false), eglSurface(nullptr), 
eglContext(
nullptr) {
   _traits = traits;

   realizeImplementation();

   if (valid()) {
  setState(new osg::State);
  getState()->setGraphicsContext(this);

  if (_traits.valid() && _traits->sharedContext.valid()) {
 getState()->setContextID(
   _traits->sharedContext->getState()->getContextID());
 incrementContextIDUsageCount(getState()->getContextID());
  } else {
 getState()->setContextID(
   osg::GraphicsContext::createNewContextID());
  }

   }

}

EGLGraphicsContext::~EGLGraphicsContext() {
   // TODO Auto-generated destructor stub
}

/** Return whether a valid and usable GraphicsContext has been created.*/
bool EGLGraphicsContext::valid() const {
   return _initialized;
}

/** Realize the GraphicsContext implementation,
 * Pure virtual - must be implemented by concrete implementations of 
GraphicsContext. */
bool EGLGraphicsContext::realizeImplementation() {
   if (_initialized) {
  return true;
   }

   GetEglExtensionFunctionPointers();

   eglDevice = GetEglDevice();

   drmFd = GetDrmFd(eglDevice);

   SetMode(drmFd, , , );

   eglDpy = GetEglDisplay(eglDevice, drmFd);

   SetUpEgl(eglDpy, planeID, _traits->width, _traits->height, ,
 );

   //disable vsync
   if (eglSwapInterval(eglDpy, 0) == EGL_TRUE) {
  cout << "swap interval changed successfully." << endl;
   } else {
  cout << "error while changing swap interval" << endl;
   }

   _initialized = true;

   return true;
}

/** Return true if the graphics context has been realized, and is ready to use, 
implementation.
 * Pure virtual - must be implemented by concrete implementations of 
GraphicsContext. */
bool EGLGraphicsContext::isRealizedImplementation() const {
   return _initialized;
}

/** Close the graphics context implementation.
 * Pure virtual - must be implemented by concrete implementations of 
GraphicsContext. */
void EGLGraphicsContext::closeImplementation() {
   _initialized = false;
}

/** Make this graphics context current implementation.
 * Pure virtual - must be implemented by concrete implementations of 
GraphicsContext. */
bool EGLGraphicsContext::makeCurrentImplementation() {
//   cout << "egl context make current" << endl;
//   cout << "is initialized?: " << _initialized << endl;
   return eglMakeCurrent(eglDpy, eglSurface, eglSurface, eglContext)
 == EGL_TRUE;
}

/** Make this graphics context current with specified read context 
implementation.
 * Pure virtual - must be implemented by concrete implementations of 
GraphicsContext. */
bool EGLGraphicsContext::makeContextCurrentImplementation(
  GraphicsContext* readContext) {
   return makeCurrentImplementation();
}

/** Release the graphics context implementation.*/
bool EGLGraphicsContext::releaseContextImplementation() {
//   cout << "egl context release" << endl;
   return eglMakeCurrent(eglDpy, EGL_NO_SURFACE, EGL_NO_SURFACE,
   EGL_NO_CONTEXT) == EGL_TRUE;
}

/** Pure virtual, Bind the graphics context to associated texture 
implementation.
 * Pure virtual - must be implemented by concrete implementations of 
GraphicsContext. */
void EGLGraphicsContext::bindPBufferToTextureImplementation(GLenum buffer) {
   cout << "bindPBuffer not impl for egl context!!" << endl;
}

/** Swap the front and back buffers implementation.
 * Pure virtual - must be implemented by concrete implementations of 

Re: [osg-users] Custom GraphicsContext Segmentation Fault when using Multithreading

[Robert Osfield]

Hi Phillipp,

The source didn't make it through the osg-users mailing list so can't
comment about the implementation side.

>From the error description in the first post it's clear that the graphics
context is not current when the graphics thread starts running.  osgViewer
specifically calls makeCurrent() to ensure that the context is current, if
this fails then you'd see issues like you are seeing.  Whether this is the
issue or not I can not say.

I could see being able to create an OSG application without X11 would be
useful.  Any chance that you could open source the implementation and
submit for inclusion with the core osgViewer?  This route would help others
help refine the implementation.  The first step would follow would be to
make an small example program with all the required classes in it then get
this working, and then once it's refined enough move the GraphicsContext
implementation into osgViewer to sit alongside the rest of the
implementation.

Cheers,
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

[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.


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

[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.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Custom GraphicsContext Segmentation Fault when using Multithreading

[Philipp Meyer]

Hi,

I added the source code for the custom graphicsContext. Sorry for the delay.

Thank you!

Cheers,
Philipp

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





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org