Hello Georg,

Georg Stevenson wrote:
> Problems:
> Linking issue: Although every OpenSG library is linked i get the 
> following error:
> Error    57    error LNK2001: unresolved external symbol "private: 
> static class OSG::RefCountPtr<class OSG::Thread,struct 
> OSG::MemObjRefCountPolicy> EventManager::eventRecvThread" 
> (?eventrecvthr...@eventmanager@@0v?$refcount...@vthread@OSG@@umemobjrefcountpol...@2@@OSG@@A)
>     

hm, linker errors on windows are always mysterious to me. Unfortunately 
I have no other idea than what I mentioned in the other mail already.

> Actually it looks like it has something to do with the threading stuff. 
> compiler settings for both inVRs SystemCore and OpenSG is Multi-Threaded 
> DLL (/MD)
> =============================
> 
> #include <OpenSG/OSGImageBackground.h> cannot be found, is there any 
> replacement for it ?

is changing the implementation to use a TextureBackground instead an 
option for you?

> =============================
> MultiDisplayWindowBase.getServers()  takes now only an index as 
> argument, variant that gives the whole vector is not available any more, 
> is it possible to add a new server string ? 
> as it is done in the old (1.8) Clustering Tutorial.
> Or... how else can i add a new rendering server?

we've tried to reduce the number of different functions that all do more 
or less the same a little. There is now only a variant that gives you a 
pointer to the field (before you could get a pointer or a reference and 
it probably was not fully consistent). So, to modify the servers field use:

mdw->editMFServers()->push_back("server_name");

> =============================
> GraphOpSeq / SharePtrGraphOp cannot be deleted any more (destructors are 
> protected, i suppose due to refcounting/garbage collection issues), can 
> i force them somehow to be deleted if i know they won't be needed?
> same for creating (new),
> how can they be handled ?

they should be created by calling the static create() member function 
and stored in a GraphOpRefPtr/GraphOpSeqRefPtr. To get rid of them let 
the pointer go out of scope or set it explicitly to NULL.
If you absolutely have to have them held by a raw pointer [1], use 
OSG::addRef(), OSG::subRef() to modify the ref count; if it drops to 
zero or less the object is destroyed.

> =============================
> Traversal of SceneGraph:
> In 1.8 the following worked perfectly:
> OSG::traverse(modelTransNode, 
> osgTypedMethodFunctor1ObjPtrCPtrRef<Action::ResultE, OpenSGModel,
>             NodePtr> (this, &OpenSGModel::traversalEnter));
>            
> As i've seen the signature of traverse stays the same, but i didn't find 
> how the TraverseEnterFunctor is passed in OpenSG 2.0 :)

we removed our own functors in favour of boost::function<>; the 
OSG::traverse function now takes a boost::function<> object as argument 
and you usually create those with boost::bind, for the above it would 
look like this:

OSG::traverse(
     modelTransNode,
     boost::bind(&OpenSGModel::traversalEnter, this, _1));

> ============================
> OSG::Thread::getCurrentChangeList()->clearAll();     -> clearAll doesn't 
> exist any more, just clear() in OpenSG 2.0?

yes, it does clear all entries in the change list.

> ============================
> Are there equivalents to OpenSG/OSGDrawAction.h or 
> OpenSG/OSGDynamicVolume.h in OpenSG 2.0  ?

no, they are both gone. Bounding volumes are always BoxVolume now.

> ============================
> Geometry related stuff:
> 
> When i replace older stuff with newer ones (according to both 
> Basics-tutorials),
> like:
> GeoPTypesPtr type = GeoPTypesUI8::create();
> with
> OSG::GeoUInt8PropertyRecPtr type = OSG::GeoUInt8Property::create();
> 
> is somehow just get GeoUInt8PropertyRecPtr is not defined , although 
> code completion finds them. Maybe it's Visual Studio related, but i the 
> include directories are set correctly as far as i've seen.

do you include OSGTypedGeoIntegralProperty.h ?

> Would really appreciate help on those problems :) , maybe later someone 
> with deep knowledge about both versions could document the changes?

porting large applications/systems is probably the best way to discover 
all the subtle/not so subtle differences - in that sense you are on the 
way to become the most qualified person to write/start such a document ;)

        Cheers,
                Carsten

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Reply via email to