wiki:FAQ

Frequently Asked Questions

These are questions that have been asked multiple times. Please check here before asking on the list.

If you have a problem on how to do a certain (hopefully simple) thing and need a code snippet, check out the HDI list instead.

  1. General
    1. How does OpenSG compare with Open Scenegraph?
    2. Where can I find the mailing list archive?
  2. Build and Install
    1. How can I build and install OpenSG from source under GNU/Linux?
    2. How can I build and install OpenSG from source under Microsoft Windows?
    3. How can I build and install OpenSG from source under MacOS X?
    4. Should I use the CVS/Dailybuilds or the stable releases?
  3. Basics
    1. Is there any design document for all of this?
    2. What's this NodePtr n=Node::create() about? Why can't I just use new?
    3. How can I free the memory if I don't need an object anymore?
    4. Do I really need this begin/endEditCP stuff?
    5. I'm lazy. Can I omit the fieldmasks when I use begin/endEditCP?
    6. How can I cast a pointer? dynamic_cast doesn't work.
    7. Checking a Ptr against NULL doesn't work. What's wrong?
    8. OpenSG seems to not release all memory on osgExit()?
    9. OpenSG seems to leak some memory continuously?
  4. Geometry
  5. StateHandling and Chunks
    1. What's a StateChunk?
  6. Materials
    1. What's a MaterialGroup? How does it interfere with Materials attached to the Geometry?
  7. Graph Traversal
    1. I need to examine / change the SceneGraph. How can I traverse it efficiently?
  8. Clustering
    1. Should I use streamsock or multicast?
    2. I want to use multicast, but my app doesn't work, what's wrong?
    3. Can I run a cluster with different operating systems?
    4. What's the difference between OpenSG's and VRJuggler's method of distributing data?
  9. Windows specific
    1. On VS2005, I get this runtime error: 'R6034 An application has made an attempt to load the C runtime library without using a manifest.'
    2. It's sometimes difficult to see the values of some classes in the debugger (vectors/colors). What can be done?

General

How does OpenSG compare with Open Scenegraph?

See Comparison.

Where can I find the mailing list archive?

The SourceForge archives are fairly out of date. Use the http://www.mail-archive.com archive which is much more up-to-date. Not up to the minute, but close.

Build and Install

See: Building

How can I build and install OpenSG from source under GNU/Linux?

How can I build and install OpenSG from source under Microsoft Windows?

How can I build and install OpenSG from source under MacOS X?

Should I use the CVS/Dailybuilds or the stable releases?

For 1.6/1.8, our opinion is that the Dailybuilds are pretty stable and useful. They are being used in 'shipping quality' software. There has been a lot of improvement from 1.6 to the current 1.8 dev (CVS) so you might want to at least try that. The CVS is of course more prone to occational glitches and is probably only needed if you need to modify the source or try a very recent fix.

The 2.0 dev version (SVN trunk) is quite volatile still (as of 2006-10-22) and is lacking some of the 1.8 functionality (we are changing some basics and are working with a subset of 1.8). All features will of course be ported. You are of course very welcome to try it and provide feedback.

Basics

Is there any design document for all of this?

Indeed: http://www.opensg.org/downloads/OpenSG-1.0-Design.html. Not updated, but it explains much of the basics pretty well, assuming you know a bit or two about OpenGL scene graphs.

What's this NodePtr n=Node::create() about? Why can't I just use new?

OpenSG uses a technique we call adjacent replication for thread-safe data (if you want to know what that is and how it works, check out 'A multi-thread safe foundation for scene graphs and its extension to clusters' at EGPGV 2002). To do that we had to create our own pointer types which hide the complexitites behind it. new doesn't know anything about any of this, therefore we need to have our own methods to create new object instances, hence ::create().

How can I free the memory if I don't need an object anymore?

In general you don't have to. If you use the RefPtr variants (e.g. NodeRefPtr) OpenSG takes care of this by itself. If an object is not used anymore, OpenSG will delete it for you. In some rare cases you may use subRefCP(); to decrement the reference counter but you should really know what you're doing here.

Do I really need this begin/endEditCP stuff?

Yes. If you omit it, things are likely to be undefined, especially if you use multiple threads or clustering. This will change in OpenSG 2.0.

I'm lazy. Can I omit the fieldmasks when I use begin/endEditCP?

It depends. If you don't use the fieldmasks, all the fields of the FieldContainer are marked as changed, which can lead to a serious performance penalty. However, if you just want to try out something or you don't care about performance (initialization for example) it's ok.

How can I cast a pointer? dynamic_cast doesn't work.

Every pointer has a static method called dcast for casting. For example

#!cpp

OSG::GeometryPtr g=OSG::GeometryPtr::dcast(node->getCore());

Checking a Ptr against NULL doesn't work. What's wrong?

Use OSG::NullFC or just use the Ptr as a boolean. To use the same example as above:

#!cpp

OSG::GeometryPtr g=OSG::GeometryPtr::dcast(node->getCore());

if(g!=OSG::NullFC){

    //cast successful, do something useful...

}

// or, in the latest versions (>=1.8), the even simpler:

if(g) {

   // ditto

}

OpenSG seems to not release all memory on osgExit()?

True. There are some places where this happens, because:

  • Tracking down all this is not easy, esp in 1.8.
  • We focus more on runtime memory leaks (see next item).
  • The OS reclaims all memory on app exit anyway.
  • The leakage is not big, but will trigger some purifiers, etc.

However, see ticket #167 for 2.0.

OpenSG seems to leak some memory continuously?

It might be a bug, but it is more probable to be the design of OpenSG's data.

F.ex, the following code does leak a bit, but not much:

#!cpp

for (int i=0; i<10; i++)

{

   NodeRefPtr tmp (SceneFileHandler::the().read("myobject.wrl"));

}

If it starts to leak huge amounts, it's a bug. If it's only a few hundred bytes, it's known and ok, so read on.

OpenSG contains datastructures that grow over time:

  • The changelists that keep track of modifications
  • A std::vector<FieldContainerPtr?> in the FieldContainerFactory that is used as a map from container id to the actual thing.

The memory consumption of the changelist can be reduced by clearing it

regularly or if you are running single thread/non-cluster apps only by

leaving them read-only.

The vector in the FieldContainerFactory can not be made smaller and

although it could be replaced by some other datastructure that maps ids

to containers, that would lead to a performance hit for clusters as

these make heavy use of it. Now, FCPtrs are quite small, so it would take

a lot of containers (i.e. more than during 'normal' use) for this vector's

size to matter. (geometry and textures usually take up much more space)

Nevertheless, if you are creating/deleting many objects during your

application's runtime, you might want to look into some caching or recycling

scheme for your fieldcontainers.

Geometry

StateHandling and Chunks

What's a StateChunk?

It's a holder for some subset of the OpenGL-state, that, when inserted in a ChunkMaterial (which holds StateChunks) and is in turn attached to a MaterialDrawable (i.e. Geometry) or MaterialGroup, affects the way the geometry is rendered

There are a number of statechunks; LightChunks, DepthChunks, TextureChunks, etc. Most of these have fields that match the direct OpenGL-commands (i.e. glDepthRange() is controlled by DepthChunk's near and far fields).

Those who know OpenGL will find themselves very familiar with the chunks' names. Worth noting is that glEnable() functionality is sometimes implemented by allowing a field to have the value GL_NONE, which disables it's functionality.

Materials

What's a MaterialGroup? How does it interfere with Materials attached to the Geometry?

A MaterialGroup is a node code which sets the current material, just as if the material had been set in all geometries below it. It can be simpler & more efficient to manage materials that way, if you want to draw a lot of geometry nodes with the same material.

Note: In 1.8 and later, the top-most material has priority. Earlier versions had the opposite behaviour.

Graph Traversal

I need to examine / change the SceneGraph. How can I traverse it efficiently?

Clustering

Should I use streamsock or multicast?

Depends. Multicast scales better in general (data is only on the wire once), but it can be problematic to set up. Streamsocket is easier to set up (if you have a network at all, streamsocket will work), but for larger clusters it can be less efficient.

The break-even point depends on many details, but (IMHO) for most applications streamsocket should perform fine with up to 8 nodes.

I want to use multicast, but my app doesn't work, what's wrong?

  • First try to set the OSG_LOG_LEVEL environment variable to "debug" and analyze the output. Are messages being sent by the client? Are they received by the servers?
  • Does your network support multicast? A lot of managed switches have to be configured to support multicast, by default they will just drop the packets. The default ttl in OpenSG is 2. So if you have more then 2 switches between the hosts you have to adjust the ttl (time to live). Need to add how
  • Do you have more then one network card? If the default network card is not the one you want to use with multicast, you have to set the correct interface in the ClusterWindow and the ClusterServer. Need to add how
  • Are all the hosts reachable by their name? Try to ping with the hostname from all hosts to all hosts.
  • Use tcpdump to check if packages are sent over the correct interface.

Can I run a cluster with different operating systems?

Yes you can, even different processor architectures, if need be. The network stream is well-defined and works fine between different systems.

However, you have to run the exact same version of the code on both ends, as the stream is a direct copy of the internal data structures, so differences between the code of the systems will proably lead to a crash.

What's the difference between OpenSG's and VRJuggler's method of distributing data?

In OpenSG, the only thing that is sent are the effects on the scenegraph. There is only application running on the master node that processes user input and simulation. Whatever it does to the scenegraph is synchronized, and only that.

VRJuggler uses input distribution to do cluster sync. There are pros and cons to both approaches:

Input Distribution a la VRJuggler:

  • + Minimal network usage
  • + Works with pretty much unchanged application
  • - Application needs to be deterministic and dependent only on input, otherwise needs manual code changes for synchronization
  • - All nodes need to be able to run full application, which can get expensive for larger applications
  • - If external resources (likes files are databases) are accessed, they will be accessed by each cluster node separately

Scenegraph Distribution a la OpenSG:

  • + Only one application logic running: only one machine needs to strong enough to run it
  • + Can use dumb/small/cheaper rendering slaves, all application code on master
  • - More network bandwidth: need to transfer all scenegraph changes

Windows specific

On VS2005, I get this runtime error: 'R6034 An application has made an attempt to load the C runtime library without using a manifest.'

You need to reference the 'OSGXXX.dll.manifest' files in your project. See 'Additional manifest files' in the 'Manifest tool' in project settings.

(This mostly seem to occur when developing an ActiveX control.)

It's sometimes difficult to see the values of some classes in the debugger (vectors/colors). What can be done?

The file autoexp.dat usually resides in C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Packages\Debugger and is quite nifty, as it allows you to specify what the debugger should show as value for a class.

For instance, the following would be useful for OpenSG:

OSG::VectorInterface<*>=x=<_values[0]> y=<_values[1]> z=<_values[2]> w=<_values[3]>

OSG::PointInterface<*>=x=<_values[0]> y=<_values[1]> z=<_values[2]> w=<_values[3]>

OSG::Color3<*>=r=<_rgb[0]> g=<_rgb[1]> b=<_rgb[2]>

OSG::Color4<*>=r=<_rgba[0]> g=<_rgba[1]> b=<_rgba[2]> a=<_rgba[3]>



OSG::FCPtr<*>=_storeP,x

OSG::SField<*>=<_value>

OSG::MField<*>=first=<_Myfirst> last=<_Mylast> end=<_Myend> type=<_fieldType>

OSG::Geometry=pos=<_sfPositions._value> types=<_sfTypes._value> lengths=<_sfLengths.value>

And there are probably more places where this technique could help.

Last modified 7 years ago Last modified on 01/17/10 01:11:44