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® 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