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
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users