Home
Getting Started
Help
Community
Development...
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.
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.
